on 03/07/2008 20:46 Andriy Gapon said the following: > Now an important finding - it seems that g++42 tries to use different > libstdc++, not its own. > I verified with nm that missing symbols are present in > /usr/local/lib/gcc-4.2.4/libstdc++.so.6, but g++42 doesn't see them. > I explicitly added the library to command line and then linking succeeded. > I am quite puzzled as to why g++42 would not see its own libstdc++ or > prefer other libstdc++ over its own. > Might this be because of -L/usr/lib in the command line?
Seems so - I added -v flag tp g++42 linking invocation and here's a snippet from output: /usr/local/libexec/gcc/x86_64-portbld-freebsd6.3/4.2.4/collect2 -V -dynamic-linker /libexec/ld-elf.so.1 -o .libs/gprocessor /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-4.2.4/gcc/x86_64-portbld-freebsd6.3/4.2.4/crtbegin.o -L/usr/local/lib -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib/gcc-4.2.4/gcc/x86_64-portbld-freebsd6.3/4.2.4 -L/usr/local/lib/gcc-4.2.4/gcc/x86_64-portbld-freebsd6.3/4.2.4/../../.. /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -rpath ... A s we can see -L/usr/lib comes before gcc-4.2.4 path and thus base libstdc+ is picked over the correct one. Since you can not reproduce this in clean environment I wonder where that -L/usr/lib comes from. -- Andriy Gapon _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
