This is the mail archive of the
mailing list for the GCC project.
Re: PATCH RFA: Build system: Check for -static-libstdc++
Mike Stump <firstname.lastname@example.org> 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
In other words, yes, this is a special case, and the default should not