PATCH RFA: Build system: Check for -static-libstdc++

Ian Lance Taylor iant@google.com
Wed Nov 3 18:56:00 GMT 2010


"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Wed, Nov 3, 2010 at 10:35 AM, Ian Lance Taylor <iant@google.com> wrote:
>>
>> This is different from the usual case of moving the compiler around.
>> The issue here is that the Go compiler itself is linked against
>> libstdc++.so.  Moreover, in the normal case of a doing a bootstrap, the
>> Go compiler will be linked against the libstdc++.so of the newly built
>> gcc.  That means that when somebody bootstraps a new version of gcc,
>> they will normally get a Go compiler which does not run with the
>> installed libstdc++.so; it will require the libstdc++.so which was just
>> created.  The only way to make that work reliably is to use a
>> -Wl,--rpath option when linking the Go compiler to point to the
>> installed location of libstdc++.so.  And that will fail if the compiler
>> is moved to a new location or to a new machine.
>>
>> I believe that the least confusing option is to link the Go compiler
>> with -static-libstdc++.  Just as I believe that when and if we convert
>> gcc itself to compile with C++, we should link gcc itself with
>> -static-libstdc++.
>>
>
> How can you avoid:
>
> [hjl@gnu-6 gcc]$ ldd cc1
> 	linux-vdso.so.1 =>  (0x00007ffff7ffe000)
> 	libcloog.so.0 => /usr/lib64/libcloog.so.0 (0x0000003f22a00000)
> 	libppl_c.so.2 => /usr/lib64/libppl_c.so.2 (0x0000003f22400000)
> 	libppl.so.7 => /usr/lib64/libppl.so.7 (0x0000003f22000000)
> 	libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x0000003f21c00000)
> 	libmpc.so.2 => /usr/lib64/libmpc.so.2 (0x00007ffff7dcd000)
> 	libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x00007ffff7b7e000)
> 	libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x0000003f2b400000)
> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007ffff797a000)
> 	libz.so.1 => /lib64/libz.so.1 (0x00007ffff7764000)
> 	libc.so.6 => /lib64/libc.so.6 (0x0000003f21400000)
> 	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003f2d000000)
> 	libm.so.6 => /lib64/libm.so.6 (0x0000003f21800000)
> 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003f2bc00000)
> 	/lib64/ld-linux-x86-64.so.2 (0x0000003f21000000)
> [hjl@gnu-6 gcc]$
>
> Please note:
>
> 1. GCC is still in C.
> 2. libstdc++.so.6 dependency comes from other DSOes.

That case is different.  The libstdc++.so there is not the one from the
bootstrapped compiler.  It is the system one, brought in from the
dependencies of the other shared libraries.  This causes no unusual
difficulty.

The difficulty comes when gcc itself is linked against the newly built
bootstrapped libstdc++.so, a libstdc++.so which in the general case is
newer than the system libstdc++.so.

Ian



More information about the Gcc-patches mailing list