John Marino <gnugcc@xxxxxxxxx> writes: > I think at least one my issues is the wrong libgcc_s file is getting > linked. It appears the new gcc 4.6 is linking to the NetBSD's system > provided libgcc_s which is from version 4.1 Some symbols such as > _Unwind_GetIPInfo info aren't there. > > It may be that the package has an error in it and should be built > statically anyway, but this seems to be a general issue. If the > system libgcc_s is old, yet it's not allowed to replace it with a new > version, what's the best way to deal with that? Would updating the > spec definitions help the newly built gcc pick up the new libgcc_s? > > /usr/lib/libgcc_s.so (NetBSD 5.1) > /usr/pkg/lib/libgcc_s.so (pkgsrc version) > > Dealing with multiple versions of libgcc_s seems painful.... libgcc_s is completely backward compatible, so you could safely replace /usr/lib/libgcc_s.so with your newer version. That said, I think you are basically asking a packaging question, rather than a gcc question. At link time, gcc should find the one you just built. At runtime, the one that is used is up to the dynamic linker. One way you could control the dynamic linker would be to arrange for gcc to pass an appropriate -rpath option to the linker. Whether that is a good idea depends entirely on how your system should run. Ian
