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
13 messages in org.kde.kde-buildsystemRe: problem with cmake 2.6RC6 and KDE 4
