David Faure wrote: >On Tuesday 04 December 2007, Thiago Macieira wrote: >> David Faure wrote: >> >objdump -p kdirmodeltest | grep PATH >> > RPATH >> > /d/kde/inst/kde4/lib:/d/kde/src/4/qt-copy/lib:/d/kde/inst/kde4/lib >> > >> >And now I can't remember: since RPATH has more priority over >> > LD_LIBRARY_PATH, how could those .shell wrapper scripts ever work at >> > all? >> >> RPATH does *not* have priority over LD_LIBRARY_PATH. RPATH overrides >> it. > >Well that's what I meant :)
:-) Those shell scripts were meant to work only under RUNPATH-enabled systems. If you don't enable it, they don't work. Like I said, blame your distribution. >> You need RUNPATH for that to work. And your grep shows you don't have >> it. Blame your distribution for not enabling a 9-year-old flag in your >> linker. > >You mean inside ld itself? Or in gcc's specs. That's how I turn it on by default on my system. It's easy to do in any installation and doesn't require recompilation of anything. >> I've been complaining to mine for almost a year now and appears >> they've finally decided to turn it on. >> See: http://qa.mandriva.com/show_bug.cgi?id=28465 > >Interesting. Doesn't say that they turned it on though, does it? No, but they're finally looking into it, after several months of nothing happening at all. >> We should turn the new dtags on by default. Just add the linker flag >> (to gcc) -Wl,--enable-new-dtags and be done with it. > >OK, now I tried (patch below). >It works! > >objdump -p kurltest | grep PATH > RPATH /d/kde/inst/kde4/lib:/d/kde/src/4/qt-copy/lib > RUNPATH /d/kde/inst/kde4/lib:/d/kde/src/4/qt-copy/lib >(and I see in your mandriva report that when RUNPATH is set, RPATH is > ignored). Cyclic overriding: RUNPATH overrides RPATH LD_LIBRARY_PATH overrides RUNPATH RPATH overrides LD_LIBRARY_PATH Just kidding... what you said is correct: when RUNPATH is set, RPATH is ignored. >But make test runs kurltest, not kurltest.shell, so this only solves > half the problem it turns out... My suggestion back when was to make the <installname> the shell script, leaving the actual binary somewhere else. Libtool left them in .libs/<installname>. >Are you saying I should commit this (after RC2)? Yes. >It's inside a "if linux and gcc" block already. I guess the only > question is if anyone could have an old system where this wouldn't be > supported, but if "9 years" is correct then I guess such linux systems > would have other trouble with compiling kde4 anyway, right? (like gcc > itself too old). Agreed. But this is again a modification of the global CMake flags. We should only be applying this to KDE builds. But, since we haven't done those changes either, your patch won't hurt now. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
