Version: (using KDE 4.0.98) Installed from: Fedora RPMs This KDE 4.1.0 showstopper is tracked as https://bugzilla.redhat.com/show_bug.cgi?id=456722 downstream. This looks like a problem with how CMake is used. It happens both with cmake 2.4 (cmake-2.4.8-2.fc9) and 2.6 (cmake-2.6.0-1.fc10). Description of problem: kdebindings 4.1 (and prereleases like 4.0.99) confuses the Ruby and Python bindings, Python bindings get installed into the Ruby directory: *** WARNING: identical binaries are copied, not linked: /usr/lib64/python2.5/site-packages/PyKDE4/solid.so and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/solid.so *** WARNING: identical binaries are copied, not linked: /usr/lib64/python2.5/site-packages/PyKDE4/ktexteditor.so and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/ktexteditor.so *** WARNING: identical binaries are copied, not linked: /usr/lib64/python2.5/site-packages/PyKDE4/khtml.so and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/khtml.so *** WARNING: identical binaries are copied, not linked: /usr/lib64/python2.5/site-packages/PyKDE4/phonon.so and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/phonon.so *** WARNING: identical binaries are copied, not linked: /usr/lib64/python2.5/site-packages/PyKDE4/soprano.so and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/soprano.so *** WARNING: identical binaries are copied, not linked: /usr/lib64/python2.5/site-packages/PyKDE4/nepomuk.so and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/nepomuk.so Version-Release number of selected component (if applicable): kdebindings-4.1.0-3.fc10 How reproducible: Always Steps to Reproduce: 1. Compare the files or look at the build.log. Actual results: The wrong bindings are installed into the Ruby folder. Expected results: Ruby bindings and Python bindings are correctly distinguished. Additional info: This is a regression from KDE 4.0 and kdebindings 4.1 should not reach F9 updates before this is fixed.
CCing Dirk because IMHO this is a showstopper for 4.1.0!
Hi Kevin, could you please attach the output of your "cmake" (those configure-part that prints details like what was found, etc.).
Build logs (including cmake output) here: http://kojipkgs.fedoraproject.org/packages/kdebindings/4.1.0/3.fc9/data/logs/x86_64/build.log http://kojipkgs.fedoraproject.org/packages/kdebindings/4.1.0/3.fc10/data/logs/x86_64/build.log
Well this is unexpected considering that kdebindings/python/pykde4/cmake/modules/SIPMacros.cmake explicitly uses a different logical name (_python_sip_foobar)) for this and uses SET_TARGET_PROPERTIES() to install the library with the correct name on disk. Is SIPMacros.cmake in kdebindings 4.1 being picked up correctly?
I think the problem is that the physical name is the same and so one of the files gets overwritten with the other at some point during the build. > Is SIPMacros.cmake in kdebindings 4.1 being picked up correctly? How would I check that?
From the Ruby binding: Linking CXX shared module ../../lib/solid.so From the Python binding: Linking CXX shared library ../../lib/solid.so So yes, the 2 files both get staged in the same directory (the lib/ subdirectory of the CMake build directory) and thus overwrite each other.
Good detective work. Now we just need a cmake guru who can tells us how to fix this.
/me summons cmake guru ;-)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib/pykde) at the top of kdebindings/python/pykde4/CMakeLists.txt fixes it for me. But probably the same need to be made with CMAKE_ARCHIVE_OUTPUT_DIRECTORY and maybe there is even a more elegant way to prevent the need to redefine it for each binding-impl.
Thanks! I'm now testing a kdebindings build with this patch: http://cvs.fedoraproject.org/viewcvs/rpms/kdebindings/devel/kdebindings-4.1.0-kde%23167450.patch?rev=1.1&view=markup (essentially your one-line fix with a comment added).
does it work? :)
Works with cmake 2.6 (Rawhide), not with 2.4 (Fedora 9). :-(
The Rawhide build log: http://koji.fedoraproject.org/koji/getfile?taskID=740067&name=build.log > Linking CXX shared library ../../lib/pykde/solid.so and the files no longer collide. The Fedora 9 build log from the exact same specfile with the exact same patch: http://koji.fedoraproject.org/koji/getfile?taskID=740072&name=build.log > Linking CXX shared library ../../lib/solid.so [...] > *** WARNING: identical binaries are copied, not linked: > /usr/lib64/python2.5/site-packages/PyKDE4/solid.so > and /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/solid.so So it looks like CMake 2.4 does not support CMAKE_LIBRARY_OUTPUT_DIRECTORY.
Looking at one file from another project which uses that variable: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/CMakeLists.txt?rev=8527 we need to use LIBRARY_OUTPUT_PATH on CMake 2.4.
re comment #14; y, I was just on my way to post that snippet; IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION LESSER 6) SET(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/lib/pykde) ELSE(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION LESSER 6) SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib/pykde) ENDIF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION LESSER 6) (untested cause I don't have 2.4 around any longer).
yay, s/LESSER/LESS/
Thanks, testing this now: http://cvs.fedoraproject.org/viewcvs/rpms/kdebindings/devel/kdebindings-4.1.0-kde%23167450.patch?rev=1.2&view=markup (I had arrived to essentially the same thing almost at the same time (and was about to post it when I got your reply), but with "EQUAL 4" rather than "LESS 6". I changed it to your version because I hadn't committed the patch to the Fedora package CVS yet anyway.)
BTW, the OpenSceneGraph folks deserve a beating for using this broken construct: IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4) - this will break the day CMake 3.0 is released. :-/ I guess I should file a bug with them.
To end the OT part, I was nice and reported this: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014833.html Let this serves as an example how _not_ to check the version of CMake in KDE. ;-) The kdebinding builds with the latest patch are still running, I'll report as soon as they complete.
I can report success: The patch from comment #17 fixes the problem, both on Rawhide (cmake 2.6) and on F9 (cmake 2.4).
Fantastic. Very much thanks! So, now it's up to our release-dude or can I still do something to help there to get kdebindings@4.1.0 rocking?!
SVN commit 837912 by mueller: fix python/ruby build mixup. Many thanks to Kevin Kofler for the analysis and the patch BUG: 167450 M +7 -0 CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=837912