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
