* GCC multilib building failure
2007-06-14 19:01 GCC-provided runtime libraries Christian Böhme
@ 2007-06-15 2:46 ` Xiaolong Tang
2007-06-15 7:49 ` Xiaolong Tang
2007-06-15 9:50 ` GCC-provided runtime libraries Kai Ruottu
2007-06-15 12:16 ` Andrew Haley
2 siblings, 1 reply; 6+ messages in thread
From: Xiaolong Tang @ 2007-06-15 2:46 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC-provided runtime libraries.
2007-06-14 19:01 GCC-provided runtime libraries Christian Böhme
2007-06-15 2:46 ` GCC multilib building failure Xiaolong Tang
@ 2007-06-15 9:50 ` Kai Ruottu
2007-06-15 12:16 ` Andrew Haley
2 siblings, 0 replies; 6+ messages in thread
From: Kai Ruottu @ 2007-06-15 9:50 UTC (permalink / raw)
To: Christian Böhme; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC-provided runtime libraries.
2007-06-14 19:01 GCC-provided runtime libraries Christian Böhme
2007-06-15 2:46 ` GCC multilib building failure Xiaolong Tang
2007-06-15 9:50 ` GCC-provided runtime libraries Kai Ruottu
@ 2007-06-15 12:16 ` Andrew Haley
2 siblings, 0 replies; 6+ messages in thread
From: Andrew Haley @ 2007-06-15 12:16 UTC (permalink / raw)
To: Christian Böhme; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 6+ messages in thread