[csw-maintainers] GCC 4.6.2 C++ front issue

[Maciej (Matchek) Bliziński]

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.

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.

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.

References:
FAQ item: http://gcc.gnu.org/faq.html#rpath
gcc-help thread: http://permalink.gmane.org/gmane.comp.gcc.help/39282
SFW thread: http://goo.gl/YUuyn

Maciej