"Maciej (Matchek) Bliziński" <[email protected]> writes: > 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.
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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
