[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