On 27-11-2006 20:00:44 +0100, Michael Haubenwallner wrote: > 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 then we have the same problem for apps that call ld themself like you write below. > 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. How can we reliably toss this one? Some packages supply their own libtool, GNU libtool is different from Darwin's libtool, etc... > > > 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. On a morning-after-coffee-thought, I think we need something during bootstrap to make sure we can also bootstrap using such "lean" profiles. > > > 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). yep, and even on Darwin this should work if I think of it now. Then why am I still passing -L$EPREFIX/lib etc. to GCC? I guess that also only makes sense during bootstrapping. > > 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). This advocates to set all rpaths only in the ld/binutils wrapper. > 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). In some cases this happens, yes. But having ld set all rpaths for prefix and the current compiler should IMO be enough. If a package needs more, then that should be done in the conventional way. (which should work in all cases, outside prefix too) -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
