libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFT PATCH v4 0/8] Sysroot series


From: Charles Wilson
Subject: Re: [RFT PATCH v4 0/8] Sysroot series
Date: Sat, 07 Aug 2010 03:31:25 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

On 8/6/2010 2:04 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Aug 06, 2010 at 02:47:59PM CEST:
>> On 8/6/2010 1:19 AM, Ralf Wildenhues wrote:
>>> Wrt. lib and lib32, lib64, can we find out all files GCC needs by asking
>>> it several -print-* questions?  Plus maybe optimistically searching for
>>> libc and ld*.so?
>>
>> Well, if the test is skipped for $build=w32, maybe we can rely on ldd?
>> That is, use the system compiler to build a hello world all, use ldd to
>> figure out what libs it is linked to, and where they come from?
> 
> Sounds like a good idea, and not a big limitation.

Well, I tried this (manually):

get a list of libs by running ldd on cc1 (e.g. gcc
-print-prog-name=cc1). This gave me:

        linux-gate.so.1 =>  (0xffffe000)
        libcloog.so.0 => /usr/lib/libcloog.so.0 (0xb7873000)
        libppl_c.so.2 => /usr/lib/libppl_c.so.2 (0xb74fd000)
        libppl.so.7 => /usr/lib/libppl.so.7 (0xb7443000)
        libgmpxx.so.4 => /usr/lib/libgmpxx.so.4 (0xb743e000)
        libmpfr.so.1 => /usr/lib/libmpfr.so.1 (0xb73ee000)
        libgmp.so.10 => /usr/lib/libgmp.so.10 (0xb7383000)
        libc.so.6 => /lib/i686/libc.so.6 (0xb7231000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7140000)
        libm.so.6 => /lib/i686/libm.so.6 (0xb711a000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70fc000)
        /lib/ld-linux.so.2 (0xb78b1000)

Now, the first and last entries might be problematic to parse, but for
my initial test I just skipped them (it turns out not to matter...)

In my fake sysroot, I created
   /tmp/sysroot/usr/lib
   /tmp/sysroot/usr/include -> /usr/include

Inside /tmp/sysroot/usr/lib, I created the following:
        libcloog.so.0 -> /usr/lib/libcloog.so.0
        libc.so.6 -> /lib/i686/libc.so.6
        libgcc_s.so.1 -> /lib/libgcc_s.so.1
        libgmp.so.10 -> /usr/lib/libgmp.so.10
        libgmpxx.so.4 -> /usr/lib/libgmpxx.so.4
        libmpfr.so.1 -> /usr/lib/libmpfr.so.1
        libm.so.6 -> /lib/i686/libm.so.6
        libppl_c.so.2 -> /usr/lib/libppl_c.so.2
        libppl.so.7 -> /usr/lib/libppl.so.7
        libstdc++.so.6 -> /usr/lib/libstdc++.so.6

as well as

        libcloog.so -> libcloog.so.0
        libc.so -> libc.so.6
        libgcc_s.so -> libgcc_s.so.1
        libgmp.so -> libgmp.so.10
        libgmpxx.so -> libgmpxx.so.4
        libmpfr.so -> libmpfr.so.1
        libm.so -> libm.so.6
        libppl_c.so -> libppl_c.so.2
        libppl.so -> libppl.so.7
        libstdc++.so -> libstdc++.so.6

Then, using the three projects from the existing sysroot.at tests (I
just copied them straight out of an existing testsuite.dir/):

        lib1/  lib2/  prog/

I went in to lib1/ and did:

        ./configure CFLAGS='--sysroot=/tmp/sysroot'

Unfortunately, configure failed.  The reason is that while the native
gcc on my system supports the sysroot option (even though by default, it
does not use a sysroot), the linker doesn't support it:

...
checking whether the C compiler works... no
configure: error: in `/home/cwilson/tmp/gcc-foo/src/lib1':
configure: error: C compiler cannot create executables
See `config.log' for more details.

config.log:
configure:2917: checking whether the C compiler works
configure:2939: gcc --sysroot=/tmp/sysroot   conftest.c  >&5
/usr/bin/ld: this linker was not configured to use sysroots
collect2: ld returned 1 exit status

Err...ooops.

$ ld --sysroot=/bob
ld: this linker was not configured to use sysroots


Well. That sux.


`--sysroot=DIRECTORY'
     Use DIRECTORY as the location of the sysroot, overriding the
     configure-time default.  This option is only supported by linkers
     that were configured using `--with-sysroot'.

So...that's that.  At least on my linux box, you can't use the system
toolchain to fake a sysroot cross compile one.

I wonder what would happen if you built a (native) toolchain with
sysroot support, but with the default "sysroot" == "/"?  OTOH, if you're
gonna go thru the trouble of specially building an entire toolchain just
to ensure that the sysroot support in libtool gets tested, you might as
well do it using an actual *cross* compiler with sysroot support.

Quick poll: does anybody's (linux) system 'ld' support the --sysroot
option?  To find out, just run 'ld --sysroot=/bob'

Mandriva 2010.1: ld --version
GNU ld (Linux/GNU Binutils) 2.20.51.0.7.20100318
---> NO.


--
Chuck




reply via email to

[Prev in Thread] Current Thread [Next in Thread]