This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC-provided runtime libraries.


Timothy C Prince wrote:

-----Original Message----- From: Christian BÃhme <monodhs@gmx.de> To: gcc-help@gcc.gnu.org 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]