| Summary: | cmake INSTALL(EXPORT) files installed into /usr/share/apps instead of /usr/lib*/, breaks multilib | ||
|---|---|---|---|
| Product: | [Developer tools] buildsystem | Reporter: | Nathan Phillip Brink (binki) <ohnobinki> |
| Component: | KDE4 (cmake) | Assignee: | Alexander Neundorf <neundorf> |
| Status: | RESOLVED WAITINGFORINFO | ||
| Severity: | normal | CC: | ernestoguevara, salamanderrake |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Nathan Phillip Brink (binki)
2010-11-06 15:26:40 UTC
Not sure I understand the issue, did you define CMAKE_INSTALL_PREFIX? Gentoo's portage properly sets CMAKE_INSTALL_PREFIX: ohnopublishing portage # grep -e CMAKE_INSTALL_PREFIX /var/tmp/portage/kde-base/kdelibs-4.5.2/work/kdelibs-4.5.2_build/CMakeCache.txt /var/tmp/portage/kde-base/libkdegam es-4.5.2/work/libkdegames-4.5.2_build/CMakeCache.txt /var/tmp/portage/kde-base/kdelibs-4.5.2/work/kdelibs-4.5.2_build/CMakeCache.txt:CMAKE_INSTALL_PREFIX:PATH=/usr /var/tmp/portage/kde-base/libkdegames-4.5.2/work/libkdegames-4.5.2_build/CMakeCache.txt:CMAKE_INSTALL_PREFIX:PATH=/usr If I understand kdelibs's CMakeLists.txt file, I think I'm essentially asking for the second of the two lines to be uncommented (although I think the line may have to be modified -- I'm not sure why ${CMAKE_CURRENT_BINARY_DIR} is being referenced or if that half of the line is supposed to work):
# the following will be the correct locations once cmake has the improved FIND_PACKAGE()
# install( FILES ${CMAKE_CURRENT_BINARY_DIR}/KDELibsDependencies.cmake DESTINATION ${PLUGIN_INSTALL_DIR}/cmake RENAME KDE4Config.cmake)
This also happens for me with polkit-kde-agent-0.99.0. The second 32bit pass results in a failure: -- <<< Gentoo configuration >>> Build type Gentoo Install path /usr Compiler flags: C -march=nocona -O2 -pipe -m32 -Wno-long-long -std=iso9899:1990 -Wundef -Wcast-align -Werror-implicit-function-declaration -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -Wmissing-format-attribute -fno-common C++ -march=nocona -O2 -pipe -m32 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden Linker flags: Executable -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed -m32 Module -Wl,--enable-new-dtags -Wl,--fatal-warnings -Wl,--no-undefined -lc -Wl,-O1 -Wl,--as-needed -m32 Shared -Wl,--enable-new-dtags -Wl,--fatal-warnings -Wl,--no-undefined -lc -Wl,-O1 -Wl,--as-needed -m32 [...] Linking CXX executable polkit-kde-authentication-agent-1 /usr/lib64/libkdeui.so.5.5.0: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [polkit-kde-authentication-agent-1] Error 1 make[1]: *** [CMakeFiles/polkit-kde-authentication-agent-1.dir/all] Error 2 make: *** [all] Error 2 Note that the linker tries to link against an so in /usr/lib64/ which of course is doomed. I'd happily run tests, apply patches or provide more information if needed. This bug is still present on gentoo systems with multilb portage. Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone! I think this bug can be closed. I didn't re-test it, as the default way of doing multilib in Gentoo changed since this bug was reported and multilib-portage (that was never default) is not necessary anymore for most use-cases. The multilib-portage project is still alive though, as it seems: https://github.com/gentoo-mirror/multilib-portage |