Ian Lance Taylor [mailto:iant@xxxxxxxxxx] writes: > Kristofer Wempa <wempa@xxxxxxx> writes: > > > So, I've built GCC 4.5.1 on my SLES10 server and proceeded > to build my new > > tool chains. Things seemed to be going OK until one > program wouldn't run. It > > complained about needing libstdc++.so with GLIBCXX_3.4.9 or > some other version. > > I searched the libraries in my new tool chain and a number > of them refer to > > specific GLIBCXX versions that are all newer than the one > that my system > > libstdc++.so provides. The only way I can get these > programs and libraries to > > work is to modify my LD_LIBRARY_PATH to point to the GCC > 4.5.1 directory that > > contains the newer libstc++.so. I have 2 questions. First > of all, why is it > > that only some libraries have this requirement. > > GCC only imposes the requirement when it is necessary, which is to say > when a program uses some aspect of the library whose ABI has changed > since earlier versions. > > > Secondly, what is the correct > > way of handling this ? I'm assuming that we don't want to > mix different > > versions of this library. I'm guessing that I should do 1 > of the following: > > > > 1) Install the newer libstdc++.so in the system directory > and have all > > packages use this version > > That should work. > > > 2) Globally set the LD_LIBRARY_PATH for this entire tool > chain so that they > > all pick up the library from the GCC 4.5.1 directory. > > That should also work, although note that you have to set > LD_LIBRARY_PATH when you run programs compiled with this > toolchain, not > when you use this toolchain itself. > > Other options are to use the linker's --rpath option, to set the > LD_RUN_PATH environment variable, or to link statically against > libstdc++. > > Ian > I've found this to be a problem for a long time, initially when the ABI was in flux but even now. At any given time I have 2-3 versions of GCC installed separately from the "builtin" gcc that came with my system(s). These GCCs are built as native and cross compilers for a number of different host and target platforms. Since I have build hosts of varying ages, the "builtin" GCCs are often of different versions. Sometimes the builtin GCC is too old to be used for the program I want to build. We deploy programs built with GCC on machines running a Unix variant but they don't have gcc installed on them so the programs must carry the necessary compiler support libraries with them. Our deployed system may have programs built at different times with different GCCs so they cannot in general all use the same /usr/lib/libstdc++.so. The solution I've resorted to is to bundle libstdc++.so and libgcc_s.so with each package I build with GCC *AND* to use the -rpath option so that the program does not depend on the version of the compiler in /usr/lib or even if it's there at all. For some open source programs on our development platforms I've also had to use little wrapper scripts to set LD_LIBRARY_PATH appropriately prior to exec'ing binaries. Even GCC's own bootstrap gets bitten by this. I recently tried to build a native linux GCC 4.5.1 as a combined tree (with links to binutils sources in the gcc source tree) and with the gold linker enabled. Unlike ld, gold is a C++ program but it is not linked with -rpath. This causes the bootstrap build and install to complete but, when I try to run the compiler outside its own build framework, gold complains that /usr/lib/libstdc++.so is missing versioning symbols. Gold should really be picking up the libstdc++.so from the gcc installation tree, not /usr/lib. (To solve this particular issue I had to build binutils separately with the builtin GCC, and then bootstrap gcc itself without links to binutils.) Is it not possible to make libstdc++ and libgcc_s static, somewhat equivalent to the crtX.o objects linked prior to main, and still support the exception stuff across libraries? Regards -- Richard Sewards
