By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1759 - Build issue: R14 FTBFS with cmake 2.8.12
Summary: Build issue: R14 FTBFS with cmake 2.8.12
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: other (any) (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: All Linux
: P1 blocker
Assignee: Slávek Banko
URL:
Depends on:
Blocks:
 
Reported: 2013-12-06 19:55 CST by Darrell
Modified: 2013-12-24 18:52 CST (History)
5 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Fix build with cmake >= 2.8.12 (1.92 KB, patch)
2013-12-21 21:12 CST, Slávek Banko 		Details | Diff
Fix build with cmake >= 2.8.12 (1) (1.94 KB, patch)
2013-12-21 22:19 CST, Slávek Banko 		Details | Diff
cmake-2.8.12-suppress-warnings.patch (542 bytes, patch)
2013-12-21 23:17 CST, Alexander Golubev (Fat-Zer) 		Details | Diff
tdelibs-fix-FTBFS-with-cmake-2.8.10.patch (509 bytes, patch)
2013-12-21 23:27 CST, Alexander Golubev (Fat-Zer) 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2013-12-06 19:55:22 CST 
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.
Comment 1 Darrell 2013-12-09 15:01:36 CST 
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
Comment 2 Slávek Banko 2013-12-18 18:34:25 CST 
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.
Comment 3 Darrell 2013-12-18 19:30:46 CST 
>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.
Comment 4 Timothy Pearson 2013-12-18 19:46:11 CST 
So, is there any way to fix this for all CMake versions including 2.8.12?
Comment 5 Darrell 2013-12-18 20:02:24 CST 
>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. :-(
Comment 6 Slávek Banko 2013-12-18 22:06:37 CST 
(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).
Comment 7 Alexander Golubev (Fat-Zer) 2013-12-20 09:53:39 CST 
(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...
Comment 8 Slávek Banko 2013-12-21 21:12:46 CST 
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!
Comment 9 Slávek Banko 2013-12-21 22:19:53 CST 
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.
Comment 10 Alexander Golubev (Fat-Zer) 2013-12-21 23:17:41 CST 
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...
Comment 11 Alexander Golubev (Fat-Zer) 2013-12-21 23:27:29 CST 
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.
Comment 12 Darrell 2013-12-22 00:51:05 CST 
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?
Comment 13 Slávek Banko 2013-12-22 04:15:55 CST 
(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.
Comment 14 Alexander Golubev (Fat-Zer) 2013-12-22 08:56:30 CST 
(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?
Comment 15 Darrell 2013-12-22 11:43:19 CST 
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. :)
Comment 16 Slávek Banko 2013-12-22 12:03:23 CST 
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."
Comment 17 Timothy Pearson 2013-12-23 02:20:51 CST 
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?
Comment 18 Slávek Banko 2013-12-23 02:29:14 CST 
(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.
Comment 19 Timothy Pearson 2013-12-23 04:42:10 CST 
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
Comment 20 Slávek Banko 2013-12-23 09:59:41 CST 
Patches waiting to commit into common modules pushed.
Also performed a complete update of submodules.

This bug fixed in GIT hash ce8049e3.
Comment 21 Alexander Golubev (Fat-Zer) 2013-12-23 10:44:45 CST 
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.
Comment 22 Slávek Banko 2013-12-23 11:08:31 CST 
(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 :)
Comment 23 Timothy Pearson 2013-12-24 16:10:44 CST 
If all the patches are now pushed, can we mark this resolved?
Comment 24 Timothy Pearson 2013-12-24 18:32:55 CST 
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!
Comment 25 Timothy Pearson 2013-12-24 18:52:21 CST 
Never mind; it seems tdelibs needed to be rebuilt earlier than I thought.