Re: Overriding startfiles and C library with libtool libraries

[Gary V . Vaughan]

Hi Mo,

It is my impression that any cross compilation environment must be able to 
link with non-native start and end files using a cross linker.  What you 
describe here doesn't seem especially different to that situation,

My reflex reaction is to say that this probably isn't supported by libtool, 
but then I have very little practical cross compilation know-how.  I do know 
that GCC 3.0 uses libtool, and that the GCC tree is capable of normal and 
canadian cross builds.  You might find an expert in these matters in the GCC 
forums...

Cheers,
        Gary.

On Monday 16 July 2001  2:05 pm, Mo McKinlay wrote:
> 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.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/