This is the mail archive of the 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++

Mike Stump <> 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  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  Moreover, in the normal case of a doing a bootstrap, the
Go compiler will be linked against the 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; it will require the 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  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


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