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