[CMake] Resolving static lib dependency at executable link time

[Pierre Mallard]

Surely I can refactor code to avoid cross-dependencies...
But the problem is more on the definition of the target link line at
executable level than on cross dependency.

Indeed even if C does not depends on B, or in your example X, writing
TARGET_LINK_LIBRARIES(EX1 libD libX1)
would always leads to have libB written after libX1 in gcc command line.

However I finally understand why order of library is a problem in gcc. It
is because unneeded symbol at time gcc find library in command line are
discarded.
Therefore when libC comes before libB, all libC symbols used by libB are
removed because they are not needed by preceding libraries, and when gcc
reach libB there is not the symbol libB needs.
Solution is to force gcc to keep all symbols of libC :

TARGET_LINK_LIBRARIES(exe1 libD -Wl,-whole-archive libC1
-Wl,-no-whole-archive)

And know we are able to remove TARGET_LINK_LIBRARIES(libB libC1) and
TARGET_LINK_LIBRARIES(libC libB).

My problem is solve !

Thanks for your help,
Pierre


On Mon, Feb 25, 2013 at 2:44 PM, Leif Walsh <leif.walsh at gmail.com> wrote:

> I see. I would not try to express this complexity to cmake. Is there a way
> you can separate the alternate functionality out of C so that it doesn't
> cause the dependency graph to fragment this way? Usually circular
> dependencies mean you need to refactor something anyway. If you can make
> the dep graph more like this it could work:
>
> EX1: D C B C B X1
> EX2: D C B C B X2
>
> (Where C1 was split into C and X1, and C2 was split into C and X2)
>
> Sent from my iPhone
>
> On Feb 25, 2013, at 8:38, Pierre Mallard <mallard.pierre at gmail.com> wrote:
>
> Hi everyone,
>
> Reading answer from leif and andreas, leads me to advance a bit.
>
> To my opinion writing target_link_libraries(exe1 libB libC) would
> certainly works (but I m not able to test it at the moment).
>
> But my problem should be explain the more tricky way :
> libB depends on libC function implementation but is a dependency of libD :
>
> I got Exe depends upon libD which use libB which use libC. libC uses
> function defined in libB.
>
> If I try Leif and Andreas idea : TARGET_LINK_LIBRARIES(Exe1 libD libC1)
> This line leads to output this gcc link line (schematically) :
>
> gcc -o exe1 libD libC1 libB <==== Dependency of libD appears after all
> other "executable direct" dependencies
>
> This does not work since libB depends on libC. The right gcc line would be
> :
>
> gcc -o exe1 libD libC1 libB libC1 libB <==== I know this repetition of
> libB libC1 looks a bit stupid but it does not work else ...
>
> These last line of gcc is what is done when setting all dependency.
> (TARGET_LINK_LIBRARIES(libB libC1) and TARGET_LINK_LIBRARIES(libC1 libB)
> but again the whole solution would require to build twice libB (and
> therefore libD and etc etc) to build with two different flavor of libC
> (libC1 and libC2).
>
> Thks for your help ...
> Pierre
>
>
>
>
>
> On Mon, Feb 25, 2013 at 2:14 PM, Andreas Stahl <
> andreas.stahl at tu-dresden.de> wrote:
>
>> Hello Pierre,
>>
>> my knowledge concerning the linking process is rather limited, but
>> wouldn't that mean you don't need to inter-link the libraries at all, when
>> the symbols are resolved at link-time with the executable?
>> add_executable(ex1 libB libC1 libC2) should suffice then.
>>
>> Best regards,
>> Andreas
>>
>>
>> Am 25.02.2013 um 13:47 schrieb Pierre Mallard:
>>
>> > Well it is indeed possible and it works... Note that static libraries
>> 's object files are built with unresolved symbols. Final resolution is
>> performed when building executable
>> > Therefore libB can compile without libC and conversely ...
>> > Anyone else ?
>> >
>> >
>> >
>> > On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš <ansis.malins at gmail.com>
>> wrote:
>> > >libB depends on libC and libC depends on libB.
>> > How is that even possible? You compile B and it fails because there's
>> no C yet. You compile C and it fails because there's no B yet.
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130225/a90520c1/attachment-0001.htm>