GCC-provided runtime libraries.

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

GCC multilib building failure

[Xiaolong Tang]

hello all,

I recently built my conceptgcc but failed when my built gcc tried to  
build multilib.
I post it here because the problem seems to be more related with the  
general gcc.

To my knowledge, one major different between this building and my  
last success one
is the GMP and MPFR package provision.

I am building it on iMac (intel core duo + os x 10.4.9).
The more detail information could be found in the following.

Would anyone like to help me out or just leave any suggestion for me?

Thanks very much!

-xiaolong

My building platform is as below:
-------------------------------------------

Using built-in specs.
Target: i386-apple-darwin8.9.1
Configured with: ../xiaolong/gcc/configure --program-transform- 
name='s/^g++$/conceptg++/' --prefix=/Users/txltamu/bin/conceptgcc -- 
enable-languages=c++ --with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.3.0 20070330 (experimental) (Indiana University  
ConceptGCC -- BoostCon Edition)


The message is as below:
-----------------------------------


# If this is the top-level multilib, build all the other
# multilibs.
/bin/sh ../../../../xiaolong/gcc/libgcc/../mkinstalldirs ../../.././ 
gcc/x86_64
mkdir ../../.././gcc/x86_64
for file in libgcc_s.10.4.dylib libgcc_s.10.5.dylib libgcc_s.1.dylib;  
do               \
   rm -f ../../.././gcc/x86_64/$file;            \
   ln -s ../$file ../../.././gcc/x86_64/;        \
done
rm -f ../../.././gcc/x86_64/libgcc_s_x86_64.1.dylib
ln -s libgcc_s.1.dylib \
         ../../.././gcc/x86_64/libgcc_s_x86_64.1.dylib
rm -f ../../.././gcc/x86_64/libgcc_s_ppc64.1.dylib
ln -s libgcc_s.1.dylib \
         ../../.././gcc/x86_64/libgcc_s_ppc64.1.dylib
/Users/txltamu/desktop/xiaolong/svn/commonsvn/conceptgcc/branches/ 
build/./gcc/xgcc -B/Users/txltamu/desktop/xiaolong/svn/commonsvn/ 
conceptgcc/branches/build/./gcc/ -B/Users/txltamu/bin/conceptgcc/i386- 
apple-darwin8.9.1/bin/ -B/Users/txltamu/bin/conceptgcc/i386-apple- 
darwin8.9.1/lib/ -isystem /Users/txltamu/bin/conceptgcc/i386-apple- 
darwin8.9.1/include -isystem /Users/txltamu/bin/conceptgcc/i386-apple- 
darwin8.9.1/sys-include -g -fkeep-inline-functions -m64 -O2  -O2 -g - 
O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes - 
Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC  
-pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   - 
I. -I. -I../../.././gcc -I../../../../xiaolong/gcc/libgcc - 
I../../../../xiaolong/gcc/libgcc/. -I../../../../xiaolong/gcc/ 
libgcc/../gcc -I../../../../xiaolong/gcc/libgcc/../include  -o  
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 - 
c ../../../../xiaolong/gcc/libgcc/../gcc/libgcc2.c \
   -fvisibility=hidden -DHIDE_EXPORTS
/usr/bin/as: assembler (/usr/libexec/gcc/darwin/x86_64/as or /usr/ 
local/libexec/gcc/darwin/x86_64/as) for architecture x86_64 not  
installed
Installed assemblers are:
/usr/libexec/gcc/darwin/ppc64/as for architecture ppc64
/usr/libexec/gcc/darwin/ppc/as for architecture ppc
/usr/libexec/gcc/darwin/i386/as for architecture i386
/usr/local/libexec/gcc/darwin/m68k/as for architecture m68k
/usr/local/libexec/gcc/darwin/hppa/as for architecture hppa
/usr/local/libexec/gcc/darwin/sparc/as for architecture sparc
/usr/local/libexec/gcc/darwin/m88k/as for architecture m88k
/usr/local/libexec/gcc/darwin/i860/as for architecture i860
In file included from /usr/include/sys/_types.h:26,
                  from /usr/include/_types.h:27,
                  from /usr/include/stdio.h:64,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
tsystem.h:90,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
libgcc2.c:33:
/usr/include/sys/cdefs.h:335:4: error: #error Unknown architecture
In file included from /usr/include/sys/_types.h:27,
                  from /usr/include/_types.h:27,
                  from /usr/include/stdio.h:64,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
tsystem.h:90,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
libgcc2.c:33:
/usr/include/machine/_types.h:30:2: error: #error architecture not  
supported
In file included from /usr/include/_types.h:27,
                  from /usr/include/stdio.h:64,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
tsystem.h:90,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
libgcc2.c:33:
/usr/include/sys/_types.h:96: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__darwin_blkcnt_t'
/usr/include/sys/_types.h:97: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__darwin_blksize_t'
/usr/include/sys/_types.h:98: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__darwin_dev_t'
/usr/include/sys/_types.h:101: error: expected '=', ',', ';', 'asm'  
or '__attribute__' before '__darwin_gid_t'
/usr/include/sys/_types.h:102: error: expected '=', ',', ';', 'asm'  
or '__attribute__' before '__darwin_id_t'
...

/usr/include/sys/_types.h:148: error: expected specifier-qualifier- 
list before '__darwin_size_t'
/usr/include/sys/_types.h:165: error: expected specifier-qualifier- 
list before '__darwin_sigset_t'
/usr/include/sys/_types.h:184: error: expected specifier-qualifier- 
list before '__darwin_sigset_t'
In file included from /usr/include/stdio.h:64,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
tsystem.h:90,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
libgcc2.c:33:
/usr/include/_types.h:32: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__darwin_wctype_t'
In file included from ../../../../xiaolong/gcc/libgcc/../gcc/ 
tsystem.h:90,
                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
libgcc2.c:33:
/usr/include/stdio.h:84: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before 'fpos_t'
/usr/include/stdio.h:145: error: expected specifier-qualifier-list  
before 'fpos_t'
/usr/include/stdio.h:255: error: expected declaration specifiers or  
'...' before 'fpos_t'
/usr/include/stdio.h: In function 'fprintf':
/usr/include/stdio.h:258: error: expected declaration specifiers  
before '__DARWIN_LDBL_COMPAT'
/usr/include/stdio.h:264: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__DARWIN_LDBL_COMPAT'
/usr/include/stdio.h:266: error: expected ';', ',' or ')' before '*'  
token
/usr/include/stdio.h:273: error: storage class specified for  
parameter 'sys_nerr'
/usr/include/stdio.h:274: error: storage class specified for  
parameter 'sys_errlist'
/usr/include/stdio.h:277: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__DARWIN_LDBL_COMPAT'
/usr/include/stdio.h:284: error: expected '=', ',', ';', 'asm' or  
'__attribute__' before '__DARWIN_LDBL_COMPAT'
....

--end

Re: GCC multilib building failure

[Xiaolong Tang]

Hi, I got the problem fixed by upgrading the developing tool for  
MAC.  (simply upgrading xcode...)
Then the assembler for x86_64 becomes ready.

However,  I got new errors reported during building libstdc++v3.  
(shown below)
I am googling for its resolution.
If anyone feeds me any advice, great appreciation!

-----------------------------------------------------------
appending configuration tag "CXX" to libtool
checking for exception model to use... configure: error: unable to  
detect exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
make: *** [all] Error 2
-------------------------------------

thanks
-xlong


On Jun 14, 2007, at 2:52 PM, Xiaolong Tang wrote:

> hello all,
>
> I recently built my conceptgcc but failed when my built gcc tried  
> to build multilib.
> I post it here because the problem seems to be more related with  
> the general gcc.
>
>
> The message is as below:
> -----------------------------------
>
>
> # If this is the top-level multilib, build all the other
> # multilibs.
> /usr/bin/as: assembler (/usr/libexec/gcc/darwin/x86_64/as or /usr/ 
> local/libexec/gcc/darwin/x86_64/as) for architecture x86_64 not  
> installed
> Installed assemblers are:
> /usr/libexec/gcc/darwin/ppc64/as for architecture ppc64
> /usr/libexec/gcc/darwin/ppc/as for architecture ppc
> /usr/libexec/gcc/darwin/i386/as for architecture i386
> /usr/local/libexec/gcc/darwin/m68k/as for architecture m68k
> /usr/local/libexec/gcc/darwin/hppa/as for architecture hppa
> /usr/local/libexec/gcc/darwin/sparc/as for architecture sparc
> /usr/local/libexec/gcc/darwin/m88k/as for architecture m88k
> /usr/local/libexec/gcc/darwin/i860/as for architecture i860
> In file included from /usr/include/sys/_types.h:26,
>                  from /usr/include/_types.h:27,
>                  from /usr/include/stdio.h:64,
>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
> tsystem.h:90,
>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
> libgcc2.c:33:
> /usr/include/sys/cdefs.h:335:4: error: #error Unknown architecture
> In file included from /usr/include/sys/_types.h:27,
>                  from /usr/include/_types.h:27,
>                  from /usr/include/stdio.h:64,
>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
> tsystem.h:90,
>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
> libgcc2.c:33:
> /usr/include/machine/_types.h:30:2: error: #error architecture not  
> supported
> In file included from /usr/include/_types.h:27,

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

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 multilib building failure

[Ko-Chih Wu]

Hi,

I saw your post on the mailing list, and I have the same problem that I
cannot build gcc 4.2.1 on my machine. The error message is as follows:

In file included from /usr/include/sys/_types.h:26,
                 from /usr/include/_types.h:27,
                 from /usr/include/stdio.h:64,
                 from ../../src/gcc/tsystem.h:90,
                 from ../../src/gcc/config/darwin-crt3.c:38:
/usr/include/sys/cdefs.h:335:4: error: #error Unknown architecture
...
/usr/include/stdio.h:258: error: parameter name omitted
../../src/gcc/config/darwin-crt3.c:535: error: expected '{' at end of input
make[5]: *** [x86_64/crt3.o] Error 1
make[4]: *** [extrax86_64] Error 2
make[3]: *** [stmp-multilib] Error 2
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2

My configuration:
../src/configure --prefix=/Users/eric/gcc-4.2.1/local --enable-languages=c
Didn't change anything basically.

I found this in Makefile:
host=i386-apple-darwin8.10.1
So it should not be using X86-64, am I right?

You mentioned that you updated Xcode, and it worked. Did you update Xcode to
3.x?

Regards,

Ko-Chih Wu


Xiaolong Tang-2 wrote:
> 
> Hi, I got the problem fixed by upgrading the developing tool for  
> MAC.  (simply upgrading xcode...)
> Then the assembler for x86_64 becomes ready.
> 
> However,  I got new errors reported during building libstdc++v3.  
> (shown below)
> I am googling for its resolution.
> If anyone feeds me any advice, great appreciation!
> 
> -----------------------------------------------------------
> appending configuration tag "CXX" to libtool
> checking for exception model to use... configure: error: unable to  
> detect exception model
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make: *** [all] Error 2
> -------------------------------------
> 
> thanks
> -xlong
> 
> 
> On Jun 14, 2007, at 2:52 PM, Xiaolong Tang wrote:
> 
>> hello all,
>>
>> I recently built my conceptgcc but failed when my built gcc tried  
>> to build multilib.
>> I post it here because the problem seems to be more related with  
>> the general gcc.
>>
>>
>> The message is as below:
>> -----------------------------------
>>
>>
>> # If this is the top-level multilib, build all the other
>> # multilibs.
>> /usr/bin/as: assembler (/usr/libexec/gcc/darwin/x86_64/as or /usr/ 
>> local/libexec/gcc/darwin/x86_64/as) for architecture x86_64 not  
>> installed
>> Installed assemblers are:
>> /usr/libexec/gcc/darwin/ppc64/as for architecture ppc64
>> /usr/libexec/gcc/darwin/ppc/as for architecture ppc
>> /usr/libexec/gcc/darwin/i386/as for architecture i386
>> /usr/local/libexec/gcc/darwin/m68k/as for architecture m68k
>> /usr/local/libexec/gcc/darwin/hppa/as for architecture hppa
>> /usr/local/libexec/gcc/darwin/sparc/as for architecture sparc
>> /usr/local/libexec/gcc/darwin/m88k/as for architecture m88k
>> /usr/local/libexec/gcc/darwin/i860/as for architecture i860
>> In file included from /usr/include/sys/_types.h:26,
>>                  from /usr/include/_types.h:27,
>>                  from /usr/include/stdio.h:64,
>>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
>> tsystem.h:90,
>>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
>> libgcc2.c:33:
>> /usr/include/sys/cdefs.h:335:4: error: #error Unknown architecture
>> In file included from /usr/include/sys/_types.h:27,
>>                  from /usr/include/_types.h:27,
>>                  from /usr/include/stdio.h:64,
>>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
>> tsystem.h:90,
>>                  from ../../../../xiaolong/gcc/libgcc/../gcc/ 
>> libgcc2.c:33:
>> /usr/include/machine/_types.h:30:2: error: #error architecture not  
>> supported
>> In file included from /usr/include/_types.h:27,
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/GCC-provided-runtime-libraries.-tf3922207.html#a13464586
Sent from the gcc - Help mailing list archive at Nabble.com.

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.

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

[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