Happy to _try_ and help. :-) I don't know that you're reading the documentation wrong, and I may not have ready your original e-mail carefully enough, either... Are you saying that it does work if you set LD_LIBRARY_PATH? No, didn't mean to say that /usr/lib gets searched first, it's just always in the search path by default, from what I understand. That is, it will always search /usr/lib if it can't find the library somewhere else - like you have it listed below. I'm not sure why it didn't work, when you put the directory in ld.so.conf, unless ldconfig just can't handle libraries with the same name in two places like that. With something like this, though, I'm not sure it's a good idea to put that directory in ld.so.conf, anyway. Most everything else on your system is going to be have been compiled with the default compiler for the system (GCC 2.96?). Since C++ applications (and probably others) are going to be incompatible with the libraries for GCC 3.3, you don't want other applications picking those up instead of the ones in /usr/lib. The approach I would take if I were using a different compiler than the system compiler would be to have shell scripts that set LD_LIBRARY_PATH appropriately for the applications built with GCC 3.3 before running them. Basically, you'd end up with a wrapper shell script for applications built with GCC 3.3. Does that make sense? In addition, you might try embedding the path to your GCC 3.3 libraries into any libraries or executables that you build. Take a look at the -rpath option for the linker (specified as -Wl,-rpath,directory to the compiler). When you embed the path in the binary, the linker should look in that directory before directories listed in ld.so.conf, etc. (Note, however, that LD_LIBRARY_PATH will get searched _before_ embedded paths.) OK. I just went back and reread your original e-mail more carefully. This looks like a problem we were seeing (to which the two suggestions above are our solution). The problem appears to be that g++ linked your program with libstdc++, but not directly with libgcc_s.so.1. libstdc++ then depends on libgcc_s. It looks like your program knows how to find the version of libstdc++ that it needs (perhaps that path has been embedded in the binary). However, when it tries to load libstdc++, it finds that it needs libgcc_s. The problem is that libstdc++ does not have the path to libgcc_s embedded in it, and the linker does not use the path embedded in the program binary when looking for libraries needed for dependent libraries. For example, let's say that you have program A that uses library B which in turn uses library C, and B and C are in the same directory. You've embedded the path to B and C in your program A. However, B does not have the path to C embedded in it. When your program runs, it will know where to find library B (due to the embedded path) and attempt to load it. When it does so, it will see that it needs library C. However, it will not use the path embedded in A to find C, since A does not directly depend on C. And, since there is no path embedded in B, it will use the default search paths to try to find C. That's going to include any paths in LD_LIBRARY_PATH, ld.so.conf, /usr/lib, etc. However, if the directory containing B and C is not in that list somewhere, it's not going to find it. In your case, library B is libstdc++, and library C is libgcc_s.so.1, and it works out that there is a library of the same name in /usr/lib which is getting ld confused (which may be why it still couldn't find the right version when the right path was included in ld.so.conf) and which is not compatible with what libstdc++ said it needs. Does that make sense? In our case, we have a little wrapper application that sets up LD_LIBRARY_PATH, etc., properly for the application being run so that it picks up the right libraries. Changing ld.so.conf or globally modifying LD_LIBRARY_PATH is probably a bad idea, because you're likely to brake other (system) applications at the same time. I hope this helps a little.... I'm in Boise. No beer necessary. :-) Cheers, Lyle -----Original Message----- From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On Behalf Of skelter@xxxxxxxxxxx Sent: Thursday, December 04, 2003 1:45 PM To: gcc-help@xxxxxxxxxxx Subject: RE: Why does ld insist on /lib/libgcc_so.so1 Quoting lrtaylor@xxxxxxxxxx: > What if you set LD_LIBRARY_PATH to the location of the correct > libgcc_s.so.1? Why! Then it seems to run just fine? You say the loader hits /lib and /usr/lib first before going through the libraries described in /etc/ld.so.cache? Am I just reading the documentation incorrectly? The man page of ld.so (8 in my case) says the order is DT_RPATH,LD_LIBRARY_PATH,DT_RUNPATH,/etc/ld.so.cache,trusted /lib & /usr/lib I do not doubt that it works, or that you are correct. I am trying understand why it does not work the way I thought it should By the way, thank you for the help and what is your location and favorite beer? -s
