[Bug 227270] cmake could not write new RPATH to akonadiserver

Brad King brad.king at kitware.com
Thu Feb 18 21:20:40 GMT 2010


https://bugs.kde.org/show_bug.cgi?id=227270


Brad King <brad.king at kitware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brad.king at kitware.com




--- Comment #3 from Brad King <brad king kitware com>  2010-02-18 22:20:17 ---
Remove the library from the build tree and then do

  make VERBOSE=1

to see the actual link line for it.  It should contain something like

 
-Wl,-rpath,/home/daniel/packs/KDE/kdesupport/build/lib:/home/daniel/packs/KDE/kdesupport/build/soprano/soprano:/usr/local/lib:

Verify that the trailing ':' appears in the actual link line.

At least one person has reported this issue with CMake before.  He was using a
patched linker (/usr/bin/ld) that refused to put any empty-string RPATH entry
into binaries.  Does your linker implement such a policy?

While this is good for security, CMake already ensures that the trailing ':'
does not end up in the install tree (which is why it refuses to install).  At
one time CMake did not add the trailing colon.  However, the RPATH field in ELF
binaries uses a string table entry that can be shared with other strings in the
binary (such as symbol names).  When CMake re-writes it on installation it
could mangle the other strings because it overwrites the whole string table
entry.  We added the trailing ':' to make collision with other strings unlikely
(symbols generally do not end in ':' and string literals are stored elsewhere).

By removing the trailing ':' the linker exposes the binary to the possibility
of mangled symbols after RPATH editing.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the Kdepim-bugs mailing list