| Summary: | Build issue: R14 FTBFS with cmake 2.8.12 | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | other (any) | Assignee: | Slávek Banko <slavek.banko> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | bugwatch, darrella, fatzer2, kb9vqf, slavek.banko |
| Priority: | P1 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: |
Fix build with cmake >= 2.8.12
Fix build with cmake >= 2.8.12 (1) cmake-2.8.12-suppress-warnings.patch tdelibs-fix-FTBFS-with-cmake-2.8.10.patch |
||
Even if a final patch is not pushed immediately to git for R14, this bug needs attention.
Digging deeper into why tdelibs now FTBFS on my system with cmake 2.8.12, I found this message in the build log:
CMake Error:
Error evaluating generator expression:
$<LINK_ONLY:-Wl,-whole-archive>
$<LINK_ONLY> expression requires exactly one parameter.
This is the closest related online conversation I found:
http://cmake.3232098.n2.nabble.com/cmake-2-8-12-generator-expression-error-when-linker-flags-have-comma-td7585816.html
Confirmed. Wherever used EMBED occurs FTBFS due to an error in CMake 2.8.12 - it is necessary to update CMake to at least 2.8.12.1. >Confirmed. Wherever used EMBED occurs FTBFS due to an error in CMake 2.8.12 -
>it is necessary to update CMake to at least 2.8.12.1.
That's fine. One caveat with that is packagers and developers are on their own to do that if the upstream distro maintainers don't want to update the cmake package. :-(
Our (eventual) README for R14.0.0 should exlain all of this --- after we are sure what is needed to resolve the related issues.
So, is there any way to fix this for all CMake versions including 2.8.12? >So, is there any way to fix this for all CMake versions including 2.8.12?
That's the way I see things. We are the ones that have to work-around the problem, not everybody else upstream. Sucks big time, but we can't force anybody upstream to do anything. :-(
(Odpověď na komentář #4)
> So, is there any way to fix this for all CMake versions including 2.8.12?
I have no idea, that would help. The problem is inside target_link_libraries - on 2.8.12 fails when there are used extra flags for linking - such as -Wl,-whole-archive (for embed).
(In reply to comment #6) > (Odpověď na komentář #4) > > So, is there any way to fix this for all CMake versions including 2.8.12? > > I have no idea, that would help. The problem is inside target_link_libraries - > on 2.8.12 fails when there are used extra flags for linking - such as > -Wl,-whole-archive (for embed). The problem that causes FTBFS is inside cmake. The cmake guys are screwed up, so IMO we don't have to and even shouldn't do anything about it... Moreover upstream already fixed it, so now 2.8.12 will be just yet another buggy version which not supposed to be used... The warnings about CMP0022 is an another issue... Created attachment 1738 [details] Fix build with cmake >= 2.8.12 First, I solved tdebase FTBFS (and potentially some other modules) with the previous patch from http://trinity-devel.pearsoncomputing.net/?0::11736 Then I tried to create a "hack" that would allow build also with broken cmake 2.8.12.0. I went through several blind alleys until perhaps eventually succeeded! Please test it! Created attachment 1739 [details]
Fix build with cmake >= 2.8.12 (1)
How do I find out when the next test with CMake 2.8.12.1, with an updated patch returned warnings of this type:
INTERFACE_LINK_LIBRARIES:
tqt;tqt-mt;Xrender;X11;c;tqt;tqt-mt;Xrender;X11;c
LINK_INTERFACE_LIBRARIES:
tqt;tqt-mt;Xrender;X11;c
Fixed in the updated patch.
Created attachment 1740 [details] cmake-2.8.12-suppress-warnings.patch My patch to suppress warnings with cmake-2.8.12+ Previously published on the maillist: http://trinity-devel.pearsoncomputing.net/?0::11760 Seems my messages are not correctly displays on the archive, so here is a couple of words about the patch from there: cmake_policy and cmake_required declaration won't affect includers. see CMP0011 cmake_required added to make policy CMP0011 work as new. Using cmake_policy is a normal and legal way to keep old code working (without warnings and rewriting it) on newer versions. AFAIK It's not some sort of hack, a quick fix or a deprecated syntax. It won't break at least unless version 3 (Or I don't know when/if they are going to break the compatibility). IMHO it's better than making code more and more complicated... Created attachment 1741 [details]
tdelibs-fix-FTBFS-with-cmake-2.8.10.patch
Here is the second patch. It will fix the build with cmake-2.8.12
Seems it's the only place with the construction which triggers the bug: a STATIC library «links» to another one with EMBED. So I suppose no more fixes will be required.
I haven't tested if other modules will FTBFS(especialy something networkmanager-related) but they shouldn't. If they actually do so with complain to unresolved symbols, there will be need a couple of edits in tdecore's CMakeLists.txt.
Slavek, Testing the patch for backwards compatibility against 2.8.8 looks great. Nothing unusual happened through tdebase. Nice and clean everywhere, just as before. :) Testing against 2.8.12, tdelibs configured and did not fail with the LINK_ONLY error. No build failures or warnings through tdebase. Testing against 2.8.12.1, tdelibs configured and did not fail with the LINK_ONLY error. No build failures or warnings through tdebase. Final package sizes looked normal. Woohoo! Looks great although I tested only through tdebase. Good job! Now then, how do Alexander's patches fit into the puzzle? (Odpověď na komentář #11)
> Vytvořena příloha 1741
> tdelibs-fix-FTBFS-with-cmake-2.8.10.patch
>
> Here is the second patch. It will fix the build with cmake-2.8.12
>
> Seems it's the only place with the construction which triggers the bug: a
> STATIC library «links» to another one with EMBED. So I suppose no more fixes
> will be required.
>
> I haven't tested if other modules will FTBFS(especialy something
> networkmanager-related) but they shouldn't. If they actually do so with
> complain to unresolved symbols, there will be need a couple of edits in
> tdecore's CMakeLists.txt.
Have you tried this your patch? Your patched one case is not the only place where is EMBED used. And 'all' these EMBED uses are a potential cause for FTBFS. In my tests were reported $<LINK_ONLY:-Wl,-whole-archive> definitely listed more times than once.
Therefore, I believe that this patch is not sufficient.
(In reply to comment #13) > (Odpověď na komentář #11) > > Have you tried this your patch? Your patched one case is not the only place > where is EMBED used. And 'all' these EMBED uses are a potential cause for > FTBFS. In my tests were reported $<LINK_ONLY:-Wl,-whole-archive> definitely > listed more times than once. > > Therefore, I believe that this patch is not sufficient. Yes, I have. But as noted on the maillist, I haven't reproduced those errors from the first shot. So it may be insufficient... In my case the only trigger condition is EMBED statement in _STATIC_ libraries. Have you or Darrell tested it? Follow up to previous post, I ran full build sets during the night against 2.8.12 and 2.8.8. No cmake related surprises. I have not run a full build set against 2.8.12.1. I haven't had time to test Alexander's patches attached here. That said, Slavek's explanation for his more complicated patch sounds plausible to me for covering all possibilities. I'll test what I can but my primary focus was 2.8.12 because that is what the stock Slackware 14.1 was released with. I also believe we can't demand Trinity packagers and users to update to 2.8.12.1 if their upstream distro maintainers have not done that. For the moment I'm content with Slavek's patch, despite not knowing or understanding whether Alexander's patch is feasible. I admit this entire cmake affair is way over my head. You two decide. :) I'll try to justify why I think my proposed patch as a better solution. Hopefully I will be convincing.
I examined the reports of this type:
INTERFACE_LINK_LIBRARIES:
tqt;tqt-mt;Xrender;X11;c;tqt;tqt-mt;Xrender;X11;c
LINK_INTERFACE_LIBRARIES:
tqt;tqt-mt;Xrender;X11;c
I was wondering why they are libraries listed twice in INTERFACE_LINK_LIBRARIES. I looked for the cause and I found that this is due to the double call target_link_librarie. First on line 696, the second on line 705. In the first case for shared library, in the second case for all libraries - including previously added shared => libraries for linking are listed twice. It looks like the first error. And really, I tried a simple patch:
--- a/cmake/modules/TDEMacros.cmake
+++ b/cmake/modules/TDEMacros.cmake
@@ -693,6 +693,9 @@
endif( NOT ${_lib} MATCHES ".+-static" )
#endif( NOT "STATIC_LIBRARY" STREQUAL "${_lib_type}" )
endforeach( _lib )
+ foreach( _lib ${_shared_libs} )
+ list( REMOVE_ITEM _link ${_lib} )
+ endforeach( _lib )
target_link_libraries( ${_target} LINK_INTERFACE_LIBRARIES ${_shared_libs} )
With this small patch, most warnings disappeared. Deliberately I not say "all" but "most". Warning remains for static libraries - for example:
INTERFACE_LINK_LIBRARIES:
tqt;tqt-mt;kICE-static
LINK_INTERFACE_LIBRARIES:
tqt;tqt-mt
And warning remains also for embeded libraries - somewhat comical "library" -Wl,-whole-archive:
INTERFACE_LINK_LIBRARIES:
dbus-1-tqt;-Wl,-whole-archive;tdenm_dbus-static;-Wl,-no-whole-archive;tdenm_dbus-static
Link implementation:
-Wl,-whole-archive;tdenm_dbus-static;-Wl,-no-whole-archive;tdenm_dbus-static
Small patch above therefore does not solve all problems, but there is also a second error. Dual use target_link_libraries leads to a change order in the list of linked libraries. In the list of libraries therefore shared libraries first are and then all the static and again also shared (with the above patch shared is not repeated).
With the change in the order of libraries related to a third error. Libraries to embed are included in the top of the list of libraries. But because of a previous call target_link_libraries for shared libraries are in the list of libraries shared first, then embed and then all static and shared again.
Therefore, I believe that the new warning from CMake 2.8.12 helped us to detect these errors. And my proposed patch in attachment 1739 [details] fix these errors.
By the way, "suppress warnings" for me always sounds like "I do not want to look a bug for now" and also "bug come back later in the least opportune moment."
I will be pushing patches soon, and will be going with Slavek's solution.
Slavek, am I correct in understanding that only the patch in attachment 1739 [details] is needed?
(Odpověď na komentář #17) > I will be pushing patches soon, and will be going with Slavek's solution. > > Slavek, am I correct in understanding that only the patch in attachment 1739 [details] is > needed? Yes, the patch from attachment 1739 [details] is sufficient, other have been proposed as an alternative solution. Because we have also prepared a patches for renaming kdewidgets => tdewidgets, I'm ready to push all patches for both common modules. Since you seem to know what needs to be done go ahead and apply all the patches. I have deactivate the automatic builds for now; let me know when all the patches are in so I can initiate a full rebuild. Thanks! Tim Patches waiting to commit into common modules pushed. Also performed a complete update of submodules. This bug fixed in GIT hash ce8049e3. Ok... let it be so... I'm still disagree with some statements but let it be so... Please also review the patch from the maillist that fixes FTBFS with clang. (Odpověď na komentář #21) > Ok... let it be so... I'm still disagree with some statements but let it be > so... > Please also review the patch from the maillist that fixes FTBFS with clang. Patch for clang from mail http://trinity-devel.pearsoncomputing.net/?0::11763 is already pushed in GIT hash 541bb2f4 :) If all the patches are now pushed, can we mark this resolved? Hmmm...the rebuild is throwing an awful lot of errors of this form on all distributions and versions: checking for KDE... configure: error: I can't find the designer plugins. These are required and should have been installed by tdelibs For example: http://quickbuild.pearsoncomputing.net:58080/5189144/buildlog_ubuntu-raspbian-wheezy-armhf.libtdeldap-trinity_4%3A14.0.0-r100-0debian7.0.0%2Bpr8~raspbian_FAILEDTOBUILD.txt.gz Has anyone else seen this since the patches went in? Thanks! Never mind; it seems tdelibs needed to be rebuilt earlier than I thought. |
I attempted to compile R14 on the newly released Slackware 14.1, which contains cmake 2.8.12. This bug report is not specific to Slackware. The arts package compiled with cmake warnings while tdelibs FTBFS with the same warnings. arts warnings: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in flow/gsl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in flow/gsl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: tdelibs warnings: CMake Warning (dev) in tdecore/tdehw/CMakeLists.txt: CMake Warning (dev) in tdecore/tdehw/networkbackends/network-manager/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in tdecore/svgicons/CMakeLists.txt: CMake Warning (dev) in tdeio/tdeio/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in tdehtml/java/CMakeLists.txt: Accompanied with each warning was something like this: CMake Warning (dev) in libltdl/CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run "cmake --help-policy CMP0022" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Static library target "ltdlc-static" has a INTERFACE_LINK_LIBRARIES property. This should be preferred as the source of the link interface for this library. Ignoring the property and using the link implementation as the link interface instead. This warning is for project developers. Use -Wno-dev to suppress it. Policy CMP0022 was introduced in cmake 2.8.12. cmake --help-policy CMP0022 cmake version 2.8.12 CMP0022 INTERFACE_LINK_LIBRARIES defines the link interface. CMake 2.8.11 constructed the 'link interface' of a target from properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?. The modern way to specify config-sensitive content is to use generator expressions and the IMPORTED_ prefix makes uniform processing of the link interface with generator expressions impossible. The INTERFACE_LINK_LIBRARIES target property was introduced as a replacement in CMake 2.8.12. This new property is named consistently with the INTERFACE_COMPILE_DEFINITIONS, INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_OPTIONS properties. For in-build targets, CMake will use the INTERFACE_LINK_LIBRARIES property as the source of the link interface only if policy CMP0022 is NEW. When exporting a target which has this policy set to NEW, only the INTERFACE_LINK_LIBRARIES property will be processed and generated for the IMPORTED target by default. A new option to the install(EXPORT) and export commands allows export of the old-style properties for compatibility with downstream users of CMake versions older than 2.8.12. The target_link_libraries command will no longer populate the properties matching LINK_INTERFACE_LIBRARIES(_<CONFIG>)? if this policy is NEW. The OLD behavior for this policy is to ignore the INTERFACE_LINK_LIBRARIES property for in-build targets. The NEW behavior for this policy is to use the INTERFACE_LINK_LIBRARIES property for in-build targets, and ignore the old properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?. This policy was introduced in CMake version 2.8.12. CMake version 2.8.12 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly.