[Aboriginal] Development tools in /usr/tools

Rob Landley rob at landley.net
Fri May 20 04:22:08 PDT 2011


On 05/19/2011 08:23 AM, David Seikel wrote:
> The problem with this current contract of mine is that I only work on
> it when the client pays in advance, and he's not always able to come up
> with money.  So sometimes I forget things and have to come up to speed
> again.
> 
> I remember there was talk of having development tools in /usr/tools.
> Having a bit of a poke around a recent build, I noticed that only the
> basic tools are there, the rest are installed in / where they usually
> want to live.  Plus tools is a symlink to a platform dependent name.

In gcc/binutils, the name "gcc" is a wrapper around the tools that do
the real work (cc1, as, ld) which live in the above strangely named
directory.  The "tools" symlink is so ccwrap can find it in a
target-independent way, basically as "../tools" from the bin directory
ccwrap is installed in.

> 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.

> 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.

Note that simple-root-filesystem.sh is doing a gross hack to collect
shared libraries out of the cross compiler:

# Do we need shared libraries?

if [ "$BUILD_STATIC" != all ]
then
  echo Copying compiler libraries...
  mkdir -p "$STAGE_DIR/lib" || dienow
  (path_search \
     "$("$ARCH-cc" --print-search-dirs | sed -n 's/^libraries: =*//p')" \
      "*.so*" 'cp -H "$DIR/$FILE" "$STAGE_DIR/lib/$FILE"' \
      || dienow) | dotprogress

  [ -z "$SKIP_STRIP" ] &&
    "${ARCH}-strip" --strip-unneeded "$STAGE_DIR"/lib/*.so
fi

And the end result is unfortunately subtly broken in ways I've never
quite gotten around to fixing because mostly when I use the simple root
filesystem, I'm building static binaries for it that don't install
shared libraries.  (The root-filesystem.sh step discards the shared
libraries out of simple-root-filesystem and replaces them with the ones
in the native compiler.)

# Remove shared libraries copied from cross compiler, and let /bin/sh point
# to bash out of native compiler instead of busybox shell.

rm -rf "$BUILD/root-filesystem-$ARCH/"{usr/lib,bin/sh} 2>/dev/null

That's ugly and should be improved upon.  (What if you have shared
libraries in an overlay?  Nobody's ever done it, but they COULD...)

Rob

 1305890528.0


More information about the Aboriginal mailing list