RE: The gold linker and KDE
Please keep in mind that gold is ELF-only, so it cannot be used to link on Win32. Thus, linking KDE with gold must stay an option and shouldn't become the default (at least until other binary formats are implemented in gold) -Michael -Original Message- From: Andreas Hartmetz [mailto:[EMAIL PROTECTED] Sent: Monday, April 14, 2008 12:09 AM To: kde-buildsystem@kde.org Subject: The gold linker and KDE Hi all, I am one of the few KDEers who tried to link KDE4 using the upcoming linker in GNU binutils called gold. gold fails if it encounters an unimplemented option (I guess it should ignore some less important ones instead) and it seems to be less forgiving when given an incomplete list of required libraries. The upside is that in pure link time gold is reportedly 5 to 6 times faster than the old ld. We obviously want to use gold at some point, right? :) I worked around the unknown options problem by hacking the gold options parser. In kdebase I added libdl to nspluginviewer's libraries. After that kdesupport, kdelibs, kdepimlibs and kdebase compiled and linked. When running the resulting binaries, however, knotify4 crashed every time it tried to play a sound because, apparently, the loading of phonon's xine backend failed. pusling on #kde-devel suggested that the xine backend itself might not be linked properly. Can you guess what might go wrong here? Ideally somebody who knows linking and the build system very well would try to link KDE with gold and fix everything necessary to make it work... I think that the gold maintainer will also fix obvious bugs quickly when asked. Another strange behavior (for the uninitiated) is that setting the linker to gold using ccmake will not have any effect. Maybe this is because gcc/g++ will be used as the frontend to ld and you can't really tell it which linker to use? This matters becaues just copying gold over ld will break compilation of KDE3 and probably many other applications which seem to have sloppy dependency lists. Cheers, Andreas -- - Flint Paper's office is piled high with shot-up criminals and the walls are riddled with bullet holes and he's kissing a beautiful woman right on the mouth! - Wonder if the munsters are on yet? ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: The gold linker and KDE
On Monday 14 April 2008, Michael Druing wrote: Please keep in mind that gold is ELF-only, so it cannot be used to link on Win32. Thus, linking KDE with gold must stay an option and shouldn't become the default (at least until other binary formats are implemented in gold) I believe that linux distributions will switch to the gold linker or provide it optionally and those problems in underlying packages will be fixed then over time. Greetings, Dirk ___ 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
recent KDE buildsystem changes that affect OSX?
I've not had a chance to do any building of KDE stuff for a month or
so, and I'm trying to get caught up. I've installed the latest CMake
release candidate (2.6.0-rc8) and have started building, and it looks
like something deep in our macros has changed recently, I'm now unable
to build basically anything above kdelibs.
I get a whole ton of errors like this:
CMake Error at runtime/kcmshell/CMakeLists.txt:9 (install):
install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable
target kcmshell4.
First, on Mac OS X, bundle has 2 meanings, it's a general term for
directories of resources (ie Foo.app/Contents/blah
Foo.framework/{Headers,Resources,Version}) and also for a loadable
module library.
My suspicion is that this is the latter, not the former, but I wanted
to confirm.
Is this just a cmake 2.6 issue? Or has something changed in the way
some of the base kdelibs/etc. macros have changed since I last tried
to build?
--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Benjamin Reed schrieb:
I've not had a chance to do any building of KDE stuff for a month or
so, and I'm trying to get caught up. I've installed the latest CMake
release candidate (2.6.0-rc8) and have started building, and it looks
like something deep in our macros has changed recently, I'm now unable
to build basically anything above kdelibs.
I get a whole ton of errors like this:
CMake Error at runtime/kcmshell/CMakeLists.txt:9 (install):
install TARGETS given no BUNDLE DESTINATION for MACOSX_BUNDLE executable
target kcmshell4.
First, on Mac OS X, bundle has 2 meanings, it's a general term for
directories of resources (ie Foo.app/Contents/blah
Foo.framework/{Headers,Resources,Version}) and also for a loadable
module library.
My suspicion is that this is the latter, not the former, but I wanted
to confirm.
Is this just a cmake 2.6 issue? Or has something changed in the way
some of the base kdelibs/etc. macros have changed since I last tried
to build?
Looks like a 2.6 issue - it's much stricter than 2.4
Maybe you've to add something in FindKDE4Internal.cmake /
INSTALL_TARGETS_DEFAULT_ARGS
HTH
Christian
___
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
Re: Extra CACHE options
On Monday 14 April 2008 13:19:18 Brad King wrote:
Hi Folks,
I just noticed that these files in kdelibs/cmake/modules:
FindAkode.cmake
I see CACHE INTERNAL in FindAkode.cmake. Isn't that ok?
FindFreetype.cmake
Fix committed.
FindGettext.cmake
I see CACHE FILEPATH in FindGettext.cmake. Isn't that ok?
FindOpenEXR.cmake
FindOpenEXR.cmake
Fix committed.
FindPCRE.cmake
Fix committed.
contain lines like
set(PCRE_LIBRARIES ${PCRE_PCRE_LIBRARY} ${PCRE_PCREPOSIX_LIBRARY}
CACHE STRING The libraries needed to use PCRE)
These should not be cache options because they just summarize
information given by users. The problem created by this is that if one
of the libraries is not found then this variable stays broken even after
the user has specified the library location.
The lines should be just
set(PCRE_LIBRARIES ${PCRE_PCRE_LIBRARY} ${PCRE_PCREPOSIX_LIBRARY})
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Extra CACHE options
Allen Winter wrote: On Monday 14 April 2008 13:19:18 Brad King wrote: FindAkode.cmake I see CACHE INTERNAL in FindAkode.cmake. Isn't that ok? It will work, but there is no reason to be in the cache. The variable being set is just summarizing results for the project. FindGettext.cmake I see CACHE FILEPATH in FindGettext.cmake. Isn't that ok? No, because the FIND_LIBRARY call uses a different variable. The SET CACHE line is just copying the result from the first run and never changes it. Again, the variable is supposed to be reporting results cached by another variable. Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: The gold linker and KDE
On Monday 14 April 2008, Michael Druing wrote: Please keep in mind that gold is ELF-only, so it cannot be used to link on Win32. Thus, linking KDE with gold must stay an option and shouldn't become the Yes, of course. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
On Mon, Apr 14, 2008 at 4:11 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Ok, we really should get nightly builds for the more exotic platforms (OSX, FreeBSD, Solaris, Windows). Yeah. What do I need to do this? Dirk's build script stuff seems pretty opaque to me, and the KDE dashboard seems to no longer exist on cmake's site. Yes, this looks like a cmake 2.6 issue. Which means we could modify our stuff so it works, but the goal is that cmake 2.6 doesn't require modifications, so let's find out what exactly goes wrong. cmake 2.6 can also generate application bundles and library frameworks and install them. That's what the bundle destination is for. I don't have a mac around to test. Can you please create a small testcase to reproduce this ? Something like add_executable(hello MACOSX_BUNDLE main.cpp) install(TARGETS hello RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib) Yeah, even that small sample fails. I've got a test case with a version that fails and a version that passes, here: http://ranger.befunk.com/debug/cmake-bundle-destination-test.tar.gz Adding BUNDLE DESTINATION lib fixes it; but I would say that if BUNDLE DESTINATION is not set, cmake should fall back to whatever LIBRARY DESTINATION is set to. -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Benjamin Reed wrote: On Mon, Apr 14, 2008 at 4:11 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: add_executable(hello MACOSX_BUNDLE main.cpp) install(TARGETS hello RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib) Yeah, even that small sample fails. I guess no one has been using CMake from CVS on the mac. This has been broken since Aug 22 2007: http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/cmInstallCommand.cxx?root=CMaker1=1.26r2=1.27 I've got a test case with a version that fails and a version that passes, here: http://ranger.befunk.com/debug/cmake-bundle-destination-test.tar.gz Adding BUNDLE DESTINATION lib fixes it; but I would say that if BUNDLE DESTINATION is not set, cmake should fall back to whatever LIBRARY DESTINATION is set to. CMake 2.4 uses the RUNTIME DESTINATION for bundles and the LIBRARY DESTINATION for frameworks. Therefore these should be the fallbacks. I'll look at fixing it. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
CMake dependency scanning for .moc files
Hi, so today I found that there are actually problems with cmake 2.6 and dependency scanning. a) after changing an installed header the .moc files for headers that include the updated header are not re-generated which might cause problems when you do ABI changes (like removing a method) on the installed header (linking errors) b) removing a .moc file from the builddir doesn't produce a re-moc, cmake just tells gcc to compile the non-existing .moc-file. I'm actually not sure wether either of the two ever worked, but IMHO at least the second one should work. This is was tested on CMake 2.6 and 2.4.7. Andreas -- Increased knowledge will help you now. Have mate's phone bugged. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: recent KDE buildsystem changes that affect OSX?
Benjamin Reed wrote: I'm getting even more confused then... RUNTIME means executables in this context, doesn't it? Then maybe I was wrong in my assessment of what BUNDLE means in the install command in the first place... does it mean loadable modules (.bundle) or does it mean app-bundles? It means app bundles. bundle is such an overloaded term in OSX that without explicit context it's hard to know what you're referring to specifically. It would be clearer in the documentation if it was more like this: The TARGETS form specifies rules for installing targets from a project. There are five kinds of target files that may be installed: ARCHIVE, LIBRARY, RUNTIME, FRAMEWORK, and BUNDLE. Executables are treated as RUNTIME targets, except that those marked with the MACOSX_BUNDLE property are treated as BUNDLE targets on OS X. Static I've updated the documentation accordingly. I've also committed a fix that should make the old code continue to run (and use the RUNTIME destination). I added a new policy CMP0006 that will warn about not providing a BUNDLE destination. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: How to use PROPERTIES VERSION and SOVERSION?
On Friday 11 April 2008, Thiago Macieira wrote: Yet GENERIC_LIB_SOVERSION is just set to 4. I miss something, obviously. ELF doesn't support that. It should support two numbers: the minimum version and the current. That is, kdelibs 4.1 is backwards compatible with 4.0; Qt 4.4 is backwards compatible with 4.0 as well (including all in-between). Of course it does support that. It is called symbol versioning. It is quite a lot of manual maintenance overhead, and quite difficult to do for C++ (because it is hard to predict the mangled name). You'd need a good tool for that. I don't know one. Greetings, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: How to use PROPERTIES VERSION and SOVERSION?
Dirk Mueller wrote: On Friday 11 April 2008, Thiago Macieira wrote: Yet GENERIC_LIB_SOVERSION is just set to 4. I miss something, obviously. ELF doesn't support that. It should support two numbers: the minimum version and the current. That is, kdelibs 4.1 is backwards compatible with 4.0; Qt 4.4 is backwards compatible with 4.0 as well (including all in-between). Of course it does support that. It is called symbol versioning. It is quite a lot of manual maintenance overhead, and quite difficult to do for C++ (because it is hard to predict the mangled name). You'd need a good tool for that. I don't know one. It gets increasingly difficult when dealing with virtual tables and the sort. To the point that symbol versioning in C++ is impossible to use. -- 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: How to use PROPERTIES VERSION and SOVERSION?
Quoting Dirk Mueller [EMAIL PROTECTED]: On Friday 11 April 2008, Thiago Macieira wrote: Yet GENERIC_LIB_SOVERSION is just set to 4. I miss something, obviously. ELF doesn't support that. It should support two numbers: the minimum version and the current. That is, kdelibs 4.1 is backwards compatible with 4.0; Qt 4.4 is backwards compatible with 4.0 as well (including all in-between). Of course it does support that. It is called symbol versioning. It is quite a lot of manual maintenance overhead, and quite difficult to do for C++ (because it is hard to predict the mangled name). You'd need a good tool for that. I don't know one. There's more information about that in this article: http://people.redhat.com/drepper/dsohowto.pdf -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
