problem with cmake 2.6RC6 and KDE 4
Brad King
brad.king at kitware.com
Mon Apr 14 16:37:12 CEST 2008
Dirk Mueller wrote:
> On Monday 14 April 2008, Brad King wrote:
>
>> CMake 2.6 comes with an ELF binary parser. It is used to change the
>> RPATH or RUNPATH of an existing binary before installation. This is
>> much faster than relinking with a new RPATH as was done by CMake 2.4
>> (relinking is still used on non-ELF systems).
>
> That much I know. why it triest to put a rpath into a binary that doesn't have
> an rpath (why?) is the problem I'm stumbling over.. I'd love to debug it if
> I'd just know how.
I'm trying to reproduce this now.
>> Add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to switch back to the relinking
>> approach.
>
> added, will test.
This is just a temporary solution for your build tree until the bug is
fixed. Please don't add this to the CMakeLists.txt files.
>> Ugh, I didn't know that about ELF linkers. IMO that's pretty stupid
>> because users can always put '.' in the RPATH if they want that behavior.
>
> it is consistent with $PATH expansion though (e.g. trailing ':' also produces
> this effect).
The behavior is just as bad for $PATH too :)
>> Do you know any safe way to remove the RPATH entry without changing the
>> binary size? Is it safe to just swap the DT_RPATH or DT_RUNPATH entry
>> to the end of the dynamic section and replace it with DT_NULL (and
>> replace the rpath string with all 0 bytes)?
>
> that sounds like a possible solution. I don't know enough about ELF details to
> judge if that has any side effects.
I've found some documentation that indicates this is okay. Some linkers
even produce extra DT_NULL entries at the end of tables to leave room
for adding entries later. I'm working on this change.
-Brad
More information about the Kde-buildsystem
mailing list