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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
