Bug 227270

Summary: cmake could not write new RPATH to akonadiserver
Product: [Frameworks and Libraries] Akonadi Reporter: Daniel Betz <dnlbtz>
Component: serverAssignee: Volker Krause <vkrause>
Status: RESOLVED NOT A BUG    
Severity: normal CC: brad.king, kdepim-bugs, neundorf
Priority: NOR    
Version: 4.4   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Daniel Betz 2010-02-16 21:30:53 UTC
Version:            (using KDE 4.4.0)
Compiler:          gcc 4.4.3 
OS:                Linux
Installed from:    Compiled From Sources

make install in the current SVN trunk version of kdesupport failles to
change the rpath of akonadiserver and the installation process stops.



Part of the output of "make install":

-- Set runtime path of "/usr/local/lib/libakonadiprotocolinternals.so.1.3.50" to "/usr/local/lib:/usr/local/lib"
-- Installing: /usr/local/include/akonadi/private/akonadiprotocolinternals_export.h                             
-- Installing: /usr/local/include/akonadi/private/imapparser_p.h                                                
-- Installing: /usr/local/include/akonadi/private/imapset_p.h                                                   
-- Installing: /usr/local/include/akonadi/private/notificationmessage_p.h                                       
-- Installing: /usr/local/include/akonadi/private/protocol_p.h                                                  
-- Installing: /usr/local/include/akonadi/private/xdgbasedirs_p.h                                               
-- Installing: /usr/local/include/akonadi/private/capabilities_p.h                                              
-- Installing: /usr/local/lib/libakonadiprivate.so.1.3.50                                                       
-- Installing: /usr/local/lib/libakonadiprivate.so.1                                                            
-- Up-to-date: /usr/local/lib/libakonadiprivate.so                                                              
-- Set runtime path of "/usr/local/lib/libakonadiprivate.so.1.3.50" to "/usr/local/lib:/usr/local/lib"          
-- Installing: /usr/local/bin/akonadiserver                                                                     
CMake Error at akonadi/server/cmake_install.cmake:65 (FILE):                                                    
  file RPATH_CHANGE could not write new RPATH:                                                                  

    /usr/local/lib:/usr/local/lib

  to the file:

    /usr/local/bin/akonadiserver

  The current RPATH is:

    /home/daniel/packs/KDE/kdesupport/build/lib:/home/daniel/packs/KDE/kdesupport/build/soprano/soprano:/usr/local/lib

  which does not contain:

    /home/daniel/packs/KDE/kdesupport/build/lib:/home/daniel/packs/KDE/kdesupport/build/soprano/soprano:/usr/local/lib:

  as was expected.
Call Stack (most recent call first):
  akonadi/cmake_install.cmake:63 (INCLUDE)
  cmake_install.cmake:41 (INCLUDE)        


make: *** [install] Error 1




In file akonadi/server/cmake_install.cmake in the build directory:

    FILE(RPATH_CHANGE
         FILE "$ENV{DESTDIR}/usr/local/bin/akonadiserver"
         OLD_RPATH "/home/daniel/packs/KDE/kdesupport/build/lib:/home/daniel/packs/KDE/kdesupport/build/soprano/soprano:/usr/local/lib:"
         NEW_RPATH "/usr/local/lib:/usr/local/lib")


I fixed the problem by removing the colon at the end of line 67.
However, to check for both variants, with colon and without, would
be nice.
Comment 1 Alexander Neundorf 2010-02-16 22:45:16 UTC
Which cmake version are you using ?

Alex
Comment 2 Daniel Betz 2010-02-16 22:59:26 UTC
cmake version 2.8.0
Comment 3 Brad King 2010-02-18 22:20:17 UTC
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.
Comment 4 Daniel Betz 2010-02-19 01:09:04 UTC
Sorry, my fault. I played around with the linker command to fix another
issue with a boot library. That was related to:

https://bugs.kde.org/show_bug.cgi?id=227275
http://www.cmake.org/Bug/view.php?id=10304

In the first link you see that the colon is there. For sure I accidentally
removed the colon. To verify, I let cmake link some targets again and everywhere
the trailing colon was present and the RPATH_CHANGE during installation 
succeeded.