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