Overriding startfiles and C library with libtool libraries

[Mo McKinlay]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

I'm working on a (reasonably) large project predominately based around
Linux. The source tree contains a kernel, C library, various libraries and
tools. The tree can be conditionally configured (for example, to disable
configuration of the C library, or kernel), and can be targetted either
natively, or for i*86-pc-linux-gnu. Most of the tree is built using
libtool and automake. The exception is the C library, which is based (at
the moment, at least) on glibc. My problem is this:

If I configure the C library, I want the other libraries and tools to link
against that, and not the system libraries. (In this case, I would be
cross-compiling from i686-pc-linux-gnu to i586-nv-lithium). Is there an
easy way to instruct libtool, in this circumstance, to:

- - Use an alternative crt{1,i,n}.o
- - Use an alternative ld.so

I stumbled for a while with instructing libtool to use an alternative
libc, before biting the bullet and creating dummy .la files for the glibc
libraries (which seems to work). Instructing libtool to compile using an
alternative set of start/endfiles seems a little tricker, though, as as
far as it's concerned, they're non-libtool objects, and so it can't create
a libtool library from them.

I'm also completely stumped as to how to use a different dynamic loader.
Obviously, I'd quite like the standard libtool behaviour of creating an
application in .libs and a wrapper script which DTRT, and a slightly
differently-linked application for installation (i.e., one which uses
$prefix/lib/ld.so.1 instead of ../../lib/c-build/elf/ld.so, for example).

Is there a (relatively) easy solution to this? Should I give up on getting
the alternative dynamic loader to work properly, as this will never really
happen?

Will pretending the libtool (via symlinks or whatever) that crt*.o are
libtool objects suffice?

Also, for a  little background, i586-nv-lithium is obviously an internal
target. Currently based very closely on Linux+glibc, but it does have the
odd difference (not least default paths for things), and is differentiated
to ease hassle later on (and to prevent standard system libraries getting
linked in where we don't want them to be). For most purposes, though, you
could think of me having a cross-compiler from i686-pc-linux-gnu to
i586-pc-linux-gnu.

Any help/hints appreciated,

Mo.

- -- 
Mo McKinlay
address@hidden
- -------------------------------------------------------------------------
GnuPG/PGP Key: pub  1024D/76A275F9 2000-07-22





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjtS5q0ACgkQRcGgB3aidfkcPQCgqQsLZPWQukbGwGMuJK56LbYh
klYAni71q7pUoMk82xPZpmD5nN6Yi/lo
=7vy2
-----END PGP SIGNATURE-----