Re: RPATH order problem
On Friday 18 May 2007 04:32:13 Brad King wrote: Alexander Neundorf wrote: On Thursday 17 May 2007 14:51, Allen Winter wrote: On Thursday 17 May 2007 2:46:39 pm Brad King wrote: Brad King wrote: David Faure wrote: I was talking to Simon on IRC and he suggested that -L/usr/lib32 should also not be generated. Can I suggest this patch? (I see that the CMake-2-4 branch is unchanged after this discussion, so this is still TODO) [snip] emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Yes, this has been on my TODO list since that conversation. I've committed it to the main tree but need to wait for a day or two of nightly tests before I can put it on the branch. Okay, this fix is now in the 2.4 branch. It will be included in 2.4.7. Is this fix important enough to justify requiring 2.4.7 for KDE 4.0? No, I don't think so, at least not now. I mean, for most systems it works, and where it doesn't work, there people can still install cmake 2.4.7. Requiring *everybody* to update to 2.4.7 once it's released is no good idea. Also there is a simple work-around for people on the platforms causing the problem: just install the qt4-dev package. Then the proper rpaths will be computed. I cannot confirm that this workaround actually works. I've tried /with/ and /without/ the qt4-dev package. But then without the qt4-dev package it was probably some other package that caused it. It's hard to find out /what/ package exactly causes it, and upgrading cmake is certainly less painful than trying to find the offending package. And removing the package /entirely/ (not just libqt4-dev but also for example libqt4-core) is not an option. Simon pgpSm6JM2q91G.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
On Friday 18 May 2007, Brad King wrote: Alexander Neundorf wrote: On Thursday 17 May 2007 14:51, Allen Winter wrote: On Thursday 17 May 2007 2:46:39 pm Brad King wrote: Brad King wrote: David Faure wrote: I was talking to Simon on IRC and he suggested that -L/usr/lib32 should also not be generated. Can I suggest this patch? (I see that the CMake-2-4 branch is unchanged after this discussion, so this is still TODO) [snip] emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Hmm, shouldn't emitted.insert(/lib); be added to that list too? Someone in the koffice irc channel just reported seeing -L/lib in his link line. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
David Faure wrote: emitted.insert(/usr/lib); + emitted.insert(/usr/lib32); + emitted.insert(/usr/lib64); Hmm, shouldn't emitted.insert(/lib); be added to that list too? Someone in the koffice irc channel just reported seeing -L/lib in his link line. Okay, instead of prediciting all the implicit link directories hard-coded in the cmake binary I've created a platform configuration variable: CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES This just lists the paths that should not be emitted. In Modules/Platform/UnixPaths.cmake it is set to have /lib, /usr/lib, /usr/lib32, and /usr/lib64 on all unix systems. This way if a new path is discovered it can just be appended to this list in the user project instead of waiting for a new CMake release. I'll try go get this in 2.4.7. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: RPATH order problem
On Friday, 18. May 2007, David Faure wrote: Hmm, shouldn't emitted.insert(/lib); be added to that list too? Someone in the koffice irc channel just reported seeing -L/lib in his link What about /opt/testing/lib, /opt/kde4/lib, /usr/local/lib ? Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem