[csw-maintainers] GCC 4.6.2 C++ front issue
Peter FELECAN
pfelecan at opencsw.org
Sat Dec 3 09:23:52 CET 2011
"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
> 2011/12/2 Peter FELECAN <pfelecan at opencsw.org>:
>> The minimal program:
>>
>> int main() {}
>>
>> compiles, links (g++ -o c c.cc) but doesn't run; the following error
>> message is reported:
>>
>> ld.so.1: c: fatal: libstdc++.so.6: open failed: No such file or
>> directory
>>
>> and ldd reports:
>> libstdc++.so.6 => (file not found)
>> libm.so.2 => /lib/libm.so.2
>> libgcc_s.so.1 => (file not found)
>> libc.so.1 => /lib/libc.so.1
>>
>> If reporting this in Mantis or in private is preferred, I'll do it.
>
> Yes, please do. It's good for tracking progress.
I'll do.
> This behavior is known, it has always been like this. Before I
> relocated the shared libraries, it was more obvious what to do,
> because libstdc++ was in a nonstandard location (outside
> /opt/csw/lib), and you had to add -R/opt/csw/gcc4/lib. Right now, the
> library is in a standard location (/opt/csw/lib), but gcc won't add it
> to the runpath by default.
This was never an issue with gcc3 or gcc4 before.
> I'm not sure whether it's a good or a bad thing.
>
> There's a way to make gcc always add /opt/csw/lib to the runpath.
>
> One thing to do would be making sure that we can add a path that
> precedes /opt/csw/lib, otherwise it would be impossible to get out of
> problems such as the one with libnet.
>
> This was discussed some time ago on gcc-help. It's very easy to do it
> wrong. For example, if you compile with -m64, then you need to add
> -R/opt/csw/lib/64, and not -R/opt/csw/lib, and it has to be somehow
> expressed in the patch for the gcc sources.
This is managed by the specification file which support conditionals.
--
Peter
More information about the maintainers
mailing list