On 13. Jan, 2010, at 13:51 , Nico Schlömer wrote:
>> Overlinking is actually only an issue for dynamic libraries. So as long as
>> you're absolutely sure that you only have static libraries, you're fine.
>
> Oh, I was thinking it is *unclean* to have a link line like
>
> -llibrarya /usr/local/local/liblapack.a --llibraryb
> /usr/local/local/liblapack.a (1)
>
> -- which (disappointingly?) is exactly what happens now that I have
> FindLibraryA.cmake and FindLibraryB.cmake, both equipped with
>
> SET_TARGET_PROPERTIES(A PROPERTIES
> IMPORTED_LOCATION "${A_LIBRARY}"
> IMPORTED_LINK_INTERFACE_LIBRARIES
> "${A_LINK_INTERFACE_LIBRARIES}"
> )
>
> where both ${A_LINK_INTERFACE_LIBRARIES} and
> ${B_LINK_INTERFACE_LIBRARIES} contain /usr/local/local/liblapack.a.
No, for static linking you often NEED to specify a library multiple times, e.g.
if you have mutually dependent libraries.
Problem with static linking is this: The linker keeps a running list of
unresolved symbols. Then, when a static library comes along, it tries to
resolve as many symbols as possible, but ONLY takes the required ones,
discarding the ones not used. If the newly imported symbols again contain
unresolved references, they are added to the list. And then it continues its
way until the input is exhausted. If all the symbols are now resolved,
everything is fine, otherwise it will complain to the user.
So, in static linking the ordering on the command line is important, and if you
have mutually dependent libraries, you might need to list some libraries
multiple times. The thing which works for me (usually) is this:
gcc -o myexe src1.o src2.o src3.o /usr/lib/liba.a /usr/lib/libb.a /usr/libc.a
/usr/lib/libb.a /usr/lib/liba.a
As you can see, the libraries are listed as a b c b a such that if b and c
need symbols from a, they appear after a (the same for c needing symbols from
b). If a needs symbols from b or c, that is covered in the "first" pass.
With static linking, the linker just picks what is needed. No information is
retained from which library these symbols came (after all, they are now part of
the final product)
>
>
>> Does the IMPORTED_LINK_INTERFACE_LIBRARIES thing work?
> So, yeap, it works, but I expected CMake to clean up after me
> dependency-wise -- instead of (1), this
>
> -llibrarya --llibraryb /usr/local/local/liblapack.a (1')
You shouldn't use -l flag, better specify the full path (CMake automatically
adds the -l flag if a library name is not a target or a path). Further, I
either it's a typo or really strange, but when using -l, the lib prefix must be
dropped (and the --l is definitely a typo).
>
> would be sufficient. My knowledge on the linking process itself is
> unfortunately not deep enough to tell if that makes an actual
> difference.
>
In your case, it might be, but that CMake can't know that (as I explained
above).
HTH
Michael
_______________________________________________
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
