View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008946CMakeCMakepublic2009-04-29 06:552016-06-10 14:30
ReporterAlexandre Feblot 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008946: Need a solution to surround some libraries with linker flags inthe link line
DescriptionThere is no way to surround some (whatever they are, whereever they are located in the link line) libraries with linker flags such as -Wl,-whole-archive / -Wl,-no-whole-archive in the link command.

This is needed for imported targets, and probably for regular targets too.

There could be 2 target properties for this: LINK_PRE_FLAG, LINK_POST_FLAG

I've found an ugly and probably not robust workaround to surround *one* library, but it does not work for more (because the flags are only added once in the link line), as shown in this post:
http://www.cmake.org/pipermail/cmake/2009-March/028348.html [^]

TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0016245)
Brad King (manager)
2009-04-29 10:22

I propose the names LINK_INTERFACE_PRE_FLAGS and LINK_INTERFACE_POST_FLAGS since they affect things that link to the target rather than the target itself.

The proper place to evaluate them is in cmComputeLinkInformation::AddTargetItem where the target file path is added to the command line.

I still need to think about how this interacts with install(EXPORT). Flags are specific to the compiler used by the importing project, so it is probably not appropriate for an exporting project to put these flags on its exported targets. Furthermore, in the whole-archive case, some importing projects may want the whole archive and some may not.
(0016247)
Alexandre Feblot (reporter)
2009-04-29 11:43

*** Not sure about how you understand it, but there should be a different PRE_FLAGS/POST_FLAG setting for each library used in an executable target link.

See this little example:

# in libraries CMakeLists:
set_target_properties(LIBA PROPERTIES PRE_FLAGS <preflagForLibA>
                                      POST FLAG <postFlagForlibA>)
set_target_properties(LIBB PROPERTIES PRE_FLAGS <preflagForLibB>
                                      POST FLAG <postFlagForlibB>)
# in exes CMakeLists:
target_link_libraries(EXE1 LIBA LIBB LIBC ...)
target_link_libraries(EXE2 LIBA LIBB LIBC ...)


*** After thinking a little more, this settings should/could also be executable-dependant, although I have not needed this yet.
To take into account this executable-dependant requirement, I see 2 solutions:

1) Overwite the properties in each executable CMakeLists.

2) Use dynamic variable like these, (which I find ugly):

LINK_INTERFACE_PRE_FLAGS_<library>
LINK_INTERFACE_POST_FLAGS_<library>

i.e.:

# in exes CMakeLists:
set_target_properties(EXE1 PROPERTIES PRE_FLAGS_LIBA <preflagForLibAInExe1>
                                      POST FLAG_LIBA <postFlagForlibAInExe1>
                                      PRE_FLAGS_LIBB <preflagForLibBInExe1>
                                      POST FLAG_LIBB <postFlagForlibBInExe1>)
set_target_properties(EXE2 PROPERTIES PRE_FLAGS_LIBA <preflagForLibAInExe2>
                                      POST FLAG_LIBA <postFlagForlibAInExe2>
                                      PRE_FLAGS_LIBB <preflagForLibBInExe2>
                                      POST FLAG_LIBB <postFlagForlibBInExe2>)
target_link_libraries(EXE1 LIBA LIBB LIBC ...)
target_link_libraries(EXE2 LIBA LIBB LIBC ...)


Note: I just used shorter property names to make it easy in the example.
(0016248)
Brad King (manager)
2009-04-29 12:33

In the case of whole-archive, the entire archive will be copied into the target. IMO this should be a deliberate act by the creator of that target, and not done through a chain of dependencies. In other words, the archive (e.g. 'whole') should appear on the target_link_libraries line:

  target_link_libraries(myexe whole)

and not just brought in through the link interface of a library:

  target_link_libraries(mylib whole) # copy 'whole' into mylib?
  target_link_libraries(myexe mylib) # copy 'whole' into myexe? duplicates?

Therefore the feature you request is not necessary. One can just write

  target_link_libraries(myexe -Wl,--whole-archive whole -Wl,--no-whole-archive)

CMake will preserve the flags and library in order. If 'whole' depends on anything else (e.g. zlib) then its dependencies will be added at the end.
(0016252)
Alexandre Feblot (reporter)
2009-04-29 15:31

"IMO this should be a deliberate act by the creator of that target, and not done through a chain of dependencies"

Well, as you say ;-)
But this is not always possible. My entire system is built on taking advantage of the dependency chain to generate the link, with 360 project libs and about 50 third party libs used in 60 different executables.
In this project, when describing an executable top dependencies, we have no idea of what will be linked through the dependency chain. That's exactly the beauty of the system: Just describe first level dependencies of each lib and let cmake do the job.
But, it turns out that a few third party libs need to be forced to be fully included, because some of their symbols will be required by a dlopen'ed shared lib.

I think IHMO my situation is not totally absurd and not so specific, and the feature request makes sens here. What do you think about it?
(0016253)
Alexandre Feblot (reporter)
2009-04-29 15:33

I forgot to mention that I also use the dependency chain mechanism for third party libs, by describing each of them as an imported target, and setting it's dependency property.
(0016267)
Brad King (manager)
2009-04-30 08:54

What kind of targets are your intermediate dependencies?

  add_library(whole STATIC ...)
  set_target_properties(whole PROPERTIES ...) # requested link flag properties

  # case 1
  add_library(myArchive STATIC ...)
  target_link_libraries(myArchive whole) # doesn't really link
  add_executable(myExeA ...)
  target_link_libraries(myExeA myArchive) # links myArchive, copies 'whole'

  # case 2
  add_library(myShared SHARED ...)
  target_link_libraries(myShared whole) # copies 'whole' into myShared
  # uh, oh...objects from 'whole' are not -fPIC
  add_executable(myExeS ...)
  target_link_libraries(myExeS myShared) # links myShared, copies 'whole'
  # uh, oh...objects from 'whole' appear twice

You never have case 2?
(0016268)
Alexandre Feblot (reporter)
2009-04-30 09:19

Right, I only have to deal with case 1 for now.
(0030494)
Brad King (manager)
2012-08-13 10:36

Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

 http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.
(0034330)
Stephen Kelly (developer)
2013-11-02 11:18

In case 2, users could be required to set the POSITION_INDEPENDENT_CODE target property to detect/diagnose that case.
(0041549)
Kitware Robot (administrator)
2016-06-10 14:27

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2009-04-29 06:55 Alexandre Feblot New Issue
2009-04-29 09:35 Bill Hoffman Status new => assigned
2009-04-29 09:35 Bill Hoffman Assigned To => Brad King
2009-04-29 10:22 Brad King Note Added: 0016245
2009-04-29 11:43 Alexandre Feblot Note Added: 0016247
2009-04-29 12:33 Brad King Note Added: 0016248
2009-04-29 12:38 Brad King Severity major => feature
2009-04-29 15:31 Alexandre Feblot Note Added: 0016252
2009-04-29 15:33 Alexandre Feblot Note Added: 0016253
2009-04-30 08:54 Brad King Note Added: 0016267
2009-04-30 09:19 Alexandre Feblot Note Added: 0016268
2012-08-13 10:36 Brad King Status assigned => backlog
2012-08-13 10:36 Brad King Note Added: 0030494
2013-11-02 11:18 Stephen Kelly Note Added: 0034330
2016-06-10 14:27 Kitware Robot Note Added: 0041549
2016-06-10 14:27 Kitware Robot Status backlog => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:30 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team