2011/12/2 Peter FELECAN <[email protected]>: > 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
