13 messages in org.kde.kde-buildsystemRe: problem with cmake 2.6RC6 and KDE 4
FromSent OnAttachments
Dirk Mueller14 Apr 2008 02:54 
Brad King14 Apr 2008 06:15 
Thiago Macieira14 Apr 2008 06:31 
Brad King14 Apr 2008 06:42 
Thiago Macieira14 Apr 2008 06:53 
Dirk Mueller14 Apr 2008 07:14 
Brad King14 Apr 2008 07:36 
Brad King14 Apr 2008 10:25 
Brad King14 Apr 2008 12:06 
Dirk Mueller25 Apr 2008 11:07 
Alexander Neundorf25 Apr 2008 11:27 
Brad King25 Apr 2008 12:17 
Dirk Mueller29 Apr 2008 06:52 
Subject:Re: problem with cmake 2.6RC6 and KDE 4
From:Brad King (brad@kitware.com)
Date:04/14/2008 06:15:39 AM
List:org.kde.kde-buildsystem

Dirk Mueller wrote:

I've switched to cmake 2.6 for dashbot (http://ktown.kde.org/~dirk/dashboard/). The problem I have now is this:

CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file CHRPATH could not write new RPATH "/opt/testing/lib" to the file "/var/tmp/kdelibs-796689-build/opt/testing/bin/kde4automoc": No valid ELF RPATH entry exists in the file;

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).

Alex originally added this feature using the "chrpath" tool. I updated it to use a builtin parser.

how can I get rid of that? this is KDE trunk, configured with:

cmake -DKDE4_BUILD_TESTS=ON -DCMAKE_INSTALL_PREFIX=/opt/testing
-DCMAKE_BUILD_TYPE=release

Add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to switch back to the relinking approach.

a slightly related and annoying note: for some projects (e.g. strigi) it writes an empty rpath into the binaries during installation instead of removing the rpath. that breaks certain checks and is dangerous, as some ld.so versions interpret empty as "current directory" which allows trivially to hijack applications by e.g. adding a hacked libc.so.6 to the start up directory.

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.

The builtin CHRPATH support in CMake, and AFAICT the chrpath tool itself, just locates the RPATH string entry in the binary and overwrites it with the new RPATH, possibly empty. It has only read support for the DYNAMIC section and its string table.

For now I'll change CMake to use relinking when the installed rpath is empty. Later we can look at adding support to remove the RPATH entry from an existing binary.

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)?

-Brad

_______________________________________________ Kde-buildsystem mailing list Kde-@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem