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++


On Wed, Nov 3, 2010 at 7:54 PM, Ian Lance Taylor <iant@google.com> wrote:
> "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.

Can we at least have the option to link the stage1 go1 binary (or whatever
it is called) dynamically against the just built libstdc++ please?  It would
be very annoying to have statically linked libstdc++ from a distributors
point of view.

Richard.

> Ian
>


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