Re: rtld or lang/gcc cannot find libgcc_s.so.1

On 2012-02-21 20:42, Steve Kargl wrote:
...
> Yes, /lib comes before /usr/local/lib/gcc46.  I suppose
> that this is a heads up for gerald_at_. lang/gcc is used by
> the ports collections to build a large number of other
> ports, so others are likely to hit this issue.

The same applies to libstdc++.so.6, if you compile any C++ program with
e.g. g++46.  During the link stage, g++ sets the library path so that
/usr/local/lib/gcc46/libstdc++.so is linked against the program:

  ...
  COMPILER_PATH=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/bin/
  LIBRARY_PATH=/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../:/lib/:/usr/lib/
  COLLECT_GCC_OPTIONS='-o' 'cpptest' '-v' '-shared-libgcc' '-mtune=generic' '-march=i486'
   /usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/collect2 --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o cpptest /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtbegin.o -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3 -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../.. cpptest.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtend.o /usr/lib/crtn.o

However, at runtime, it links against the system libstdc++:

  $ ldd ./cpptest
  ./cpptest:
	  libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28098000)
	  libm.so.5 => /lib/libm.so.5 (0x28171000)
	  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2818d000)
	  libc.so.7 => /lib/libc.so.7 (0x28198000)

Some (simple) C++ programs handle this just fine, others die horribly...