tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
GCC, once more
Sorry, this got again a little bit lengthy. But I think it's not a
simple problem...
I am still in the process of figuring out, how to get lang/gcc46
properly working on Solaris 10. Although it can generate working
binaries, I am not happy with the rpath compiled into them. What I don't
understand, and where I need input: What are the different places that
influence this? Obviously, there have been some changes to pkgsrc
itself, as lang/gcc34's behavior has changed since the last time I had a
working environment.
This is the current situation:
===
pkgsrc distribution from early this year, lang/gcc34 as compiler
(LOCALBASE is /usr/pkgsrc/20101105, which is a symlink to
/software/pkgsrc/sunos5.10-x64/20101105)
$ gcc -dumpspecs
...
*link_libgcc:
%D -R /usr/pkgsrc/20101105/gcc34/lib
$ bmake show-var VARNAME=LDFLAGS
-L/software/pkgsrc/sunos5.10-x64/20101105/gcc34/bin/../lib/gcc/i386-pc-solaris2.10/3.4.6
-Wl,-R/software/pkgsrc/sunos5.10-x64/20101105/gcc34/bin/../lib/gcc/i386-pc-solaris2.10/3.4.6
-L/software/pkgsrc/sunos5.10-x64/20101105/gcc34/bin/../lib
-Wl,-R/software/pkgsrc/sunos5.10-x64/20101105/gcc34/bin/../lib
$ libtool --config | grep sys_lib_search_path_spec
sys_lib_search_path_spec="/software/pkgsrc/sunos5.10-x64/20101105/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6
/software/pkgsrc/sunos5.10-x64/20101105/gcc34/lib/gcc
/usr/pkgsrc/20101105/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6
/usr/ccs/bin /usr/ccs/lib
/software/pkgsrc/sunos5.10-x64/20101105/gcc34/lib
/usr/pkgsrc/20101105/gcc34/lib /lib /usr/lib"
$ dump -Lv `which xmllint` | grep RPATH
[11] RPATH
/usr/pkgsrc/20101105/lib:/usr/pkgsrc/20101105/gcc34/lib
$ dump -Lv `which xpdf` | grep RPATH
[20] RPATH
/usr/pkgsrc/20101105/gcc34/lib:/usr/pkgsrc/20101105/lib
===
Recent pkgsrc distribution, lang/gcc34 as compiler (LOCALBASE is
/pkgsrc/gcc34)
$ gcc -dumpspecs
...
*link_libgcc:
%D -R /pkgsrc/gcc34/gcc34/lib
$ bmake show-var VARNAME=LDFLAGS
-L/pkgsrc/gcc34/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6
-Wl,-R/pkgsrc/gcc34/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6
-L/pkgsrc/gcc34/gcc34/lib -Wl,-R/pkgsrc/gcc34/gcc34/lib
$ libtool --config | grep sys_lib_search_path_spec
sys_lib_search_path_spec="/pkgsrc/gcc34/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6
/usr/ccs/bin /usr/ccs/lib /pkgsrc/gcc34/gcc34/lib /lib /usr/lib"
$ dump -Lv `which xmllint` | grep RPATH
[11] RPATH
/pkgsrc/gcc34/lib:/pkgsrc/gcc34/gcc34/lib:/pkgsrc/gcc34/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6
===
Same pkgsrc distribution, lang/gcc46 as compiler (LOCALBASE is
/pkgsrc/gcc46-ld), with patches described in pkg/45256 (i.e. importing
lang/gcc34/patches/patch-cc and compiled with LD_RUN_PATH set to
$LOCALBASE/gcc46/lib)
$ gcc -dumpspecs
*link_libgcc:
%D -R /pkgsrc/gcc46-ld/gcc46/lib
$ bmake show-var VARNAME=LDFLAGS
-L/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1
-Wl,-R/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1
-L/pkgsrc/gcc46-ld/gcc46/lib -Wl,-R/pkgsrc/gcc46-ld/gcc46/lib
$ libtool --config | grep sys_lib_search_path_spec
sys_lib_search_path_spec="/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1
/pkgsrc/gcc46-ld/gcc46/lib /lib /usr/lib"
$ dump -Lv `which xmllint` | grep RPATH
[11] RPATH
/pkgsrc/gcc46-ld/lib:/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1:/pkgsrc/gcc46-ld/gcc46/lib
$ dump -Lv `which xpdf` | grep RPATH
[20] RPATH
/pkgsrc/gcc46-ld/gcc46/lib:/pkgsrc/gcc46-ld/lib:/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1:/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1/
===
The only directories necessary in the rpath are $LOCALBASE/lib and
$_GCC_PREFIX/lib, i.e. only the very first example has a minimal but
sufficient rpath. Directories like
/pkgsrc/gcc46-ld/gcc46/lib/gcc/i386-pc-solaris2.10/4.6.1 are
unnecessary, as they don't contain any shared libraries.
Why is LDFLAGS set in mk/compilers/gcc.mk? IMHO, it's the responsibility
of a) the compiler to provide correct linker flags for its internal
libraries (libgcc_s et al.), and b) of the user to provide flags for all
remaining paths as needed. There should be no further defaults. The
first responsibility is currently broken in GCC and (I assume) the
reason for lang/gcc34/patches/patch-cc.
And why, even with more directories in LDFLAGS and provided by libtool,
was the situation better a year ago with lang/gcc34?
--
Jörn Clausen
joern.clausen%uni-bielefeld.de@localhost
Hochschulrechenzentrum http://www.uni-bielefeld.de/hrz/
Universität Bielefeld
Home |
Main Index |
Thread Index |
Old Index