2011/12/11 Marc Glisse:
> On Sun, 11 Dec 2011, Maciej (Matchek) Bliziński wrote:
>
>> I've seen this topic discussed many times. The problem seems to come
>> up every time gcc is compiled with prefix != /usr/bin. The way to
>> reproduce it is simple:
>>
>> echo "int main() {}" > t.c; g++ -o t t.c ; ./t
>>
>> The result:
>>
>> ld.so.1: t: fatal: libstdc++.so.6: open failed: No such file or directory
>> Killed
>>
>> I just had a bug filed against my gcc packages[1]. I did some
>> research, and I found information about a number of approaches, which
>> aren't really consistent and none of them is explained or
>> self-explanatory.
>>
>> In some instances GCC sources were patched[2], in other the spec
>> information was dumped, modified and placed where it would be taken as
>> the default[3].
>>
>> What's the recommended way of doing it?
>
>
> Whether you patch the builtin specs or provide a specs file that overrides
> them doesn't really matter, it is roughly equivalent. What does matter and
> requires some thought is what you want to put in there. Make sure you handle
> -m32/-m64. Determine if you always want to do something or only when -lgcc_s
> is there. Chose between passing ld a -R flag or a -c flag. etc.
Right, that's partly why the best solution for a single-user system
(where any sane choice is reasonable and can be changed at will) is
different to the best solution for a firm-wide rollout for hundreds of
users across multiple continents (where consistency matters and it's
harder to change once hundreds of makefiles are relying on a certain
behavour) and different again to a packager distributing GCC to a wide
variety of users (where noone knows what everyone wants or how they'll
use it.)
I tend to install it with the default behaviour and leave it to users
to decide how to link, as that gives the most flexibility, but you
have to be prepared to repeatedly explain how to solve the runtime
problems.
