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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Nov 3, 2010 at 10:35 AM, Ian Lance Taylor <iant@google.com> wrote:
> Mike Stump <mikestump@comcast.net> writes:
>
>> On Nov 2, 2010, at 9:36 PM, Ian Lance Taylor wrote:
>>> The Go frontend wants to use it when linking, so that the Go frontend is
>>> independent of the installed libstdc++.so. ?This is particularly useful
>>> when bootstrapping, and is generally desirable as it permits moving the
>>> compiler around.
>>
>> I don't think this is the way forward. ?A platform selects shared or non-shared libraries for platform reasons. ?You ignore those reasons and seek to change them. ?If everyone did that, we'd be back in 1989 with software installations that are 20x or more of what they should be. ?So, my question, is what makes go so special that the default should not apply?
>>
>> People that move the compiler around, are already aware of the magic games they have to play with the shared libraries.
>
> 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.

-- 
H.J.