Timothy C Prince wrote:
-----Original Message----- From: Christian Böhme <monodhs@xxxxxx> To: gcc-help@xxxxxxxxxxx Date: Thu, 14 Jun 2007 16:41:43 +0200 Subject: GCC-provided runtime libraries. Hello all, I am currently trying to install the 4.2.0 version of GCC on a Linux system that has not seen much administration work over the past years. This system has an old and broken (apparently misadminstered) version of g++ installed that is not usable. It also happens that said system has some commercial production software on it which is not available in source form. Since I am not going to want to do a full bootstrap of the whole system, let alone experimenting with (in)compatibilities of versions of all sorts of runtime libraries (eg, libc, libstdc++) with said software, the logical approach would be to install the new compiler in a separate location that is to use the binutils, runtime linker and libc of the system. The problem here is that this new compiler with its updated/ improved/bug-less runtime libraries (such as libgcc_s.so, libstdc++.so, libgfortran.so) does not explicitly tell the linker to link against them (or set DT_RUNPATH in the resulting executables accordingly) but to use what is setup by the sysadmin (via /etc/ld.so.conf and friends). Consequently, I reverted back to configuring with static runtime libraries which even more surprisingly yielded the same result. It appears that g++ only passes a lone -lstdc++ to the linker but not the path where GCC supposedly installed its own sparkly new libraries (either shared or static). While it would certainly be _possible_ to set LD_RUN_PATH to the location of the libraries during link time, it nevertheless is tedious to do so for every invokation. It would, of course, require knowledge about their exact location in the filesysytem which is definitely not what every user should be expected to know. What I want is that executables compiled with the new compiler shall be linked against the new runtime libraries installed with that compiler while existing software is to use the existing runtime libraries. Is there a way to do that without hacking the GCC sources ? The system in question uses a SUSE Linux distribution. These are the config options: $ ../<gcc-src>/configure \ --with-gmp-include=<some-path>/include \ --with-gmp-lib=<some-path>/lib64 \ --with-mpfr-include=<some-path>/include \ --with-mpfr-lib=<some-path>/lib64 \ --disable-shared \ --enable-version-specific-runtime-libs \ --enable-threads=posix \ --enable-tls \ --enable-languages=c,c++,fortran \ --enable-__cxa_atexit \ --with-gxx-include-dir=<some-path>/include/C++ \ --with-long-double-128 \ --enable-decimal-float \ --with-arch=opteron \ --with-cpu=opteron \ --with-tune=opteron \ --disable-libssp \ --disable-libgomp \ --disable-checking \ --enable-bootstrap \ x86_64-generic-linux -----------------------------------------------
When you add the --prefix option to specify the install path,
That was omitted above since the exact install root is actually irrelevant to the problem at hand (it's outside the /usr dir and also not in /).
your newly built g++ should put the corresponding library directories
> at the top of its search path: It's not that the newly installed GCC does not know where its libraries are that it links against. It just fails to tell the (runtime) linker when it is invoked to produce the executable where to look for those GCC-specific libraries when the executables are to be run. That is what the DT_RUNPATH tag in the dynamic section of an ELF executable file is for when they were linked against libraries in non-standard locations.
You will have to put the corresponding library path in the front of
> LD_LIBRARY_PATH in order for the corresponding .so libraries to be used
at run time.
That's actually even more tedious than having the linker set LD_RUN_PATH only once during compilation. It would mean that every user of the executable would have to know the GCC-specific runtime library locations and set their env vars accordingly. Mind you, many people aren't even aware that there is such thing as a libgcc_s.so ... Cheers, Christian
