This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]