Re: GCC-provided runtime libraries.

Re: GCC-provided runtime libraries.

[Timothy C Prince]

-----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, your newly built g++ should put the corresponding library directories at the top of its search path:
/yourinstallpath/bin/g++ -print-search-dirs

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.

Tim Prince

Re: GCC-provided runtime libraries.

[Christian Böhme]

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

Re: GCC-provided runtime libraries.

[Nick Maclaren]

Andrew Haley <aph-gcc@littlepinkcloud.COM> wrote:
>
> The simplest and probably best idea is the most obvious one: replace
> your installed gcc with a script that invokes gcc with "-specs=FILE".
> You can then add any specs you want in FILE, such as invoking ld with
> -rpath.

I did that for years, on many Unices, and it works very well, except
for one problem.

Software with poxious forms of autoconfiguration will poke around your
system and select one or other compiler at whim - or, in many cases,
a dysfunctional combination of all of them.  Unfortunately, MOST
modern, complex software does at least some of that and you have to
reverse engineer its autoconfiguration to hack around the bugs.  That
can be anywhere from simple to almost impossible.

The only solution to that problem involves the authors of the software,
a dark alley and a blunt instrument.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

Re: GCC-provided runtime libraries.

[Andrew Haley]

Christian Böhme writes:
 > 
 > 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.

Yes.

 > 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 simplest and probably best idea is the most obvious one: replace
your installed gcc with a script that invokes gcc with "-specs=FILE".
You can then add any specs you want in FILE, such as invoking ld with
-rpath.

Andrew.

Re: GCC-provided runtime libraries.

[Kai Ruottu]

Christian Böhme kirjoitti:
> 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.
> 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).
The GNU linker knows the '-rpath-link <libpath>' and '-rpath <libpath>' 
options
to force the pointed shared libs being searched at 'linktime' when 
producing the
executable and at 'runtime' when running that executable. So the latter 
would be
what you will need...  You could use it in every compile/link command or 
put it
into the 'specs' file of the new gcc-4.2.0, into the same 'spec' where that
'--dynamic-linker /lib/ld-linux.so.2' is...

>   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).

 Surprisingly GCC DOESN'T as default install its $target/$gcc-version
specific link-time libraries into the expected $target/$gcc-version 
directory:

   $prefix/lib/gcc/$target/$gcc-version

where it searches these libraries first!  But puts them into the 'native 
search
place', '/usr/lib' or into some other totally unexpected place :-(  So 
people
like me have learned to NOT use the 'make install' and use their own local
install template scripts for putting things where they should go 
following the
GCC builder's opinions...  OR use the :

   --enable-version-specific-runtime-libs

GCC configure option (as you did!)  in order to put the produced libs 
into that '$prefix/lib/gcc/$target/$gcc-version'!  In any case the goal 
could be to use the $target/$gcc-version specific install directory for 
the stuff required at link-time,
it will be used automatically and first!  Just check with the 'g++ 
-print-search-dirs'.

For the run-time issue using the '-rpath <libdir>' marks every produced 
executable
to search the shared  libraries first from the '<libdir>' before going 
to the native
'/lib' and '/usr/lib', '/usr/local/lib' etc.   What this "alternative 
search  place" could be
is then totally dependent on your tastes...   But  '/opt/lib' could 
sound nice for me...

The '-rpath <libdir>' can be given on the GCC 'compile&link' command like:

   g++ -Wl,-rpath,<libdir> -O2 -o hello hello.cpp

using the '-Wl,<linker-options>' GCC option for giving extra options to 
the linker.

That there really is a new built-in/hard-wired RPATH stamped into the 
executable
can be seen via 'objdump' like:

  objdump -p  hello

GCC-provided runtime libraries.

[Christian Böhme]

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



Thanks & regards,
Christian