On Mon, 2006-11-27 at 19:25 +0100, Fabian Groffen wrote: > On 27-11-2006 19:17:16 +0100, Michael Haubenwallner wrote: > > Hi, > > > > tried a different way with exciting success: > > exciting is an UNDERstatement! > > > Attached sys-devel/binutils-2.16.1-r3.ebuild creates a wrapper script > > around the real linker, which always appends to ld-commandline: > > -rpath=$EPREFIX/lib:$EPREFIX/usr/lib > > Maybe we should also include the /usr/lib/CHOST/gcc/VER/ stuff in there?
Hmm, this should be done by the gcc-wrapper. IMO we don't should assume any gcc version in ld. But we should take care on that damn libtool - IIRC have seen it informs gcc to do "-nostdlib" sometimes, and then passing all of the libs itself. > > > So I can remove setting LD_RUN_PATH and LDFLAGS completely from > > sunos/profile.bashrc, going around any "whether need -Wl," and "LDFLAGS > > are not passed to linker" issues. > > COOL!! > > > Have remerged system+vim+svn, and all binaries really have good > > DT_RUNPATH encoded now :-) > > I guess this adds as "bonus" that "user" compilations now automagically > (when they use the prefix linker/compiler) use the prefix stuff too, > right? Ohw wait, no. Because GCC doesn't see the includes, or did we > patch it such that it looks in our prefix too? Yes, gcc knows our headerfiles, from both --with-local-prefix and --prefix too (remember the symlinked --prefix issue). > > > Thoughts ? > > Maybe it's less expensive (context switches, etc.) to implement this in > the gcc wrapper script Gentoo already uses? Then we could also set > -Lpath next to -rpath=path. Does not work: sometimes ld is used directly (ncurses fex). And no, we must not set -rpath by just accumulating -L args as they will contain $D, which we definitely don't want in DT_RUNPATH. This is what libtool sometimes is for, to remove $D from -L and pass to -rpath (which does not work on HP-UX and AIX, where the linker records -L args as -rpath under some cirumstances I did not understand yet). /haubi/ -- [EMAIL PROTECTED] mailing list
