[Aboriginal] Development tools in /usr/tools

[David Seikel]

On Fri, 20 May 2011 06:22:08 -0500 Rob Landley <rob at landley.net> wrote:

> On 05/19/2011 08:23 AM, David Seikel wrote:
> > I'm thinking it would be great for my project, and likely good for
> > others, if there was something like /usr/tools that was a mount
> > point for yet another disk image, like the one used for building
> > control images.  This disk image would have all the purely needed
> > for development stuff on it.  With suitable links if needed.  Then
> > it can be unmounted to get just the image with the resulting
> > embedded system on it.  At least that's the theory.  More or less.
> 
> The native-compiler tarball sort of works like that now.  Note that
> ccwrap doesn't care where it's installed, as long as all the other
> directories are relative to it.  So you should be able to extract it
> on any system in an arbitrary directory and run it from there.
> 
> The down side is if you don't install the shared libraries on the host
> you won't be able to run the resulting binaries (unless they're
> statically linked), because the shared library loader location is
> hardwired into each binary as an absolute path, that's a limitation of
> the ELF spec.  You can specify a different location for it to hardwire
> in (export CCWRAP_DYNAMIC_LINKER=/blah/ld-uClibc.so.0), but that's not
> much of an improvement.

I was not talking about the shared libraries.  If using such shared
libraries in the resulting system, then they must stay.

> > Are there plans to do such a thing?  I can likely do that myself, it
> > fits within the scope of my contract.
> 
> You need to define the problem a little more tightly.  What exactly
> are you trying to accomplish, and remember the shared libraries you're
> linking against need to be deployed on target for you to run the
> result.

I want to easily separate the tools used to build the result from the
result.  Shared libraries stay if shared libraries are part of the
result.  I have yet to decide if shared libraries or static linking
will be used in general in my project.  At this point, I like my
options on that matter to be open.

Things like include files, and the various development executables that
end up in /usr/bin are not needed for the resulting system, only needed
to build them.  Linker libraries should be included in this part.

To help, I'll mention the exact use case I have for my current
contract.  One of the government requirements for this device is that
ONLY the data needed to perform the legally sanctioned functions of the
device must ship on the resulting device.  "Data" in this case refers
to every single bit in all persistent storage media in the device.

The audit labs needs all source code, and the ability to recreate the
"data" from that source code, as well as a sample of the shipping
device.  So, I want to hand the audit labs the device as it will ship,
and a hard drive. The hard drive will include the source code, and the
development environment we use to build it. This development
environment is what I'm building now using Aboriginal Linux as the base.

The audit lab can plug the hard drive into the sample device, run my
build script, and come back hours later to see that it has replicated
itself, and created a disk image that matches the one in the device.
This plus copious documentation should make the lab very happy.  A very
happy audit lab will charge less, making my client very happy.

Sooo, I need to be able to separate the build environment from the
finished system, then mount it back in later.  To help shake out bugs
from this process, that's EXACTLY what I will use for the development
itself.  Being able to strip the finished system down to the bare
minimum is a goal as stated above.

Yes, I'm well aware that I have no source for the BIOS, or any other
standard firmware that may end up on whatever board we end up using.
The audit labs and government is fine with that, as our main board
hardware falls within the guidelines.  There IS a PIC chip based
daughter board.  We have source code for that, coz I wrote it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110521/edf2d263/attachment-0003.pgp>