Re: problem with cmake 2.6RC6 and KDE 4
On Friday 25 April 2008, Brad King wrote: This is the *exact* same problem as before. The error message is just more verbose. Now I need to know how to reproduce it. What source tree do I need to checkout? I get this from svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs Please also send me the CMakeCache.txt from the build tree, plus the cmake/automoc/cmake_install.cmake file, and /opt/kde-41/bin/kde4automoc, and the kde4automoc from the build tree. sure, will be in another personal email. you can also reach me via irc or jabber ([EMAIL PROTECTED]) to make me send you additional debug or point me where to look at things. Thank you for your help. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
On Monday 14 April 2008, Brad King wrote: Okay, it doesn't matter how to reproduce it. The fix is the same. I've updated to RC9, and got a new problem: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file RPATH_CHANGE could not write new RPATH: /opt/kde-41/lib to the file: /opt/kde-41/bin/kde4automoc No valid ELF RPATH entry exists in the file; Call Stack (most recent call first): cmake/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:45 (INCLUDE) that is a new bug we have due to our strange rpath related settings (Alex?)? I'm working around this install error with -DCMAKE_SKIP_RPATH=ON for now. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
On Friday 25 April 2008, Dirk Mueller wrote: On Monday 14 April 2008, Brad King wrote: Okay, it doesn't matter how to reproduce it. The fix is the same. I've updated to RC9, and got a new problem: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file RPATH_CHANGE could not write new RPATH: /opt/kde-41/lib to the file: /opt/kde-41/bin/kde4automoc No valid ELF RPATH entry exists in the file; Call Stack (most recent call first): cmake/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:45 (INCLUDE) that is a new bug we have due to our strange rpath related settings (Alex?)? Do we have strange rpath settings ? Don't change anything, it will be fixed in cmake. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
Dirk Mueller wrote: On Monday 14 April 2008, Brad King wrote: Okay, it doesn't matter how to reproduce it. The fix is the same. I've updated to RC9, and got a new problem: CMake Error at cmake/automoc/cmake_install.cmake:39 (FILE): file RPATH_CHANGE could not write new RPATH: /opt/kde-41/lib to the file: /opt/kde-41/bin/kde4automoc No valid ELF RPATH entry exists in the file; Call Stack (most recent call first): cmake/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:45 (INCLUDE) This is the *exact* same problem as before. The error message is just more verbose. Now I need to know how to reproduce it. What source tree do I need to checkout? Please also send me the CMakeCache.txt from the build tree, plus the cmake/automoc/cmake_install.cmake file, and /opt/kde-41/bin/kde4automoc, and the kde4automoc from the build tree. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
problem with cmake 2.6RC6 and KDE 4
Hi, 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; 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 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. Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
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-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
Brad King wrote: By the way, this is not the first I've heard of this error. Other people have run into it. Okay, but no one ever reported it to our bug tracker so I didn't know. Yeah, I didn't hear from the first person either. He had just upgraded to 2.6 and was going to clean up and build again. I don't even remember who it was. Someone on IRC. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
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. Add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to switch back to the relinking approach. added, will test. 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). 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. Sorry for not reporting it to the cmake bugreporter so far, I'm not sure if this is a kde specific system (as I know that we have quite some rpath related magic everywhere), thats why I didn't report it. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
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; I'm having trouble reproducing this. If CMake sees that the installed file should have an RPATH then it makes sure the build system puts a placeholder RPATH in the built binary. Then during installation the built file is copied to the destination and the placeholder RPATH is replaced. Somehow your installed file is ending up with no RPATH entry. Even if it already existed with no RPATH before installation it should have had a different file time than the to-be-installed file and therefore been replaced with a copy that had a placeholder. How did you get to the situation reporting the error? Was this a completely clean build and install tree, or was it an existing tree from CMake 2.4 that was upgraded? Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problem with cmake 2.6RC6 and KDE 4
Brad King wrote: 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; I'm having trouble reproducing this. [snip] How did you get to the situation reporting the error? Was this a completely clean build and install tree, or was it an existing tree from CMake 2.4 that was upgraded? Okay, it doesn't matter how to reproduce it. The fix is the same. I've committed changes to CMake HEAD in CVS to address this problem and the one about removing the RPATH entry. Before installing CMake now checks if there is an existing binary that has the wrong RPATH and removes it. That will make sure the new copy from the build tree gets installed and subsequently patched to update or remove the RPATH entry. These fixes will be in the 2.6 release. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem