[CMake] CMake removing duplicated static libraries from target_link_libraries list?

[Marco]

Hi Michael,

here's the plain example. I have a package with its CMakeLists.txt file 
like this:

#
# Generate library
#
add_library(TrkBase ${Sources})
target_link_libraries(TrkBase ${LIB_LINK_LIST})

#
# Generate executable
#
add_executable(TrkExchangeDataTest bins/TrkExchangeDataTest.cc)
target_link_libraries(TrkExchangeDataTest ${BIN_LINK_LIST})

Now my LIB_LINK_LIST is the following:

/usr/lib/libboost_regex.a;TrajGeom;PDT;CommonUtils;gfortran;ProbTools;Experiment;BField;BbrGeom;difAlgebra;m;AssocTools;AbsEvent;AbsEnv;ProxyDict;ErrLogger;BbrStdUtils;/usr/lib/libboost_regex.a;BaBar;CLHEP;CLHEP-2.0.3.2

while the BIN_LINK_LIST is:

TrkBase;BbrGeom;difAlgebra;m;ErrLogger;BbrStdUtils;/usr/lib/libboost_regex.a;BaBar;CLHEP;CLHEP-2.0.3.2

and this is the generated link.txt:

/usr/bin/c++ 
CMakeFiles/TrkDifPieceTrajTest.dir/bins/TrkDifPieceTrajTest.cc.o  -o 
TrkDifPieceTrajTest 
-L/data/exp_software/superb/releases/FastSim/V0.2.7/lib/Linux26SL5_i386_gcc412 
-L/data/exp_software/superb/cern/root/5.26/lib 
-L/data/exp_software/superb/cern/clhep/2.0.3.2/lib 
../../../lib/Linux26SL5_i386_gcc412/libTrkBase.a 
../../../lib/Linux26SL5_i386_gcc412/libBbrGeom.a -ldifAlgebra -lm 
-lErrLogger -lBbrStdUtils /usr/lib/libboost_regex.a -lBaBar -lCLHEP 
-lCLHEP-2.0.3.2 -lTrajGeom -lPDT -lCommonUtils -lgfortran -lProbTools 
-lExperiment -lBField -ldifAlgebra -lm -lAssocTools -lAbsEvent -lAbsEnv 
-lProxyDict -lErrLogger -lBbrStdUtils /usr/lib/libboost_regex.a -lBaBar 
-lCLHEP -lCLHEP-2.0.3.2

As I expected, CMake puts first the list of libraries from BIN_LINK_LIST 
(maybe in the previous mail I misplaced them...) and then, since TrkBase 
has itself too a list of dependencies (LIB_LINK_LIST), the libraries 
from LIB_LINK_LIST. The point is that the second BbrGeom library 
disappears from the link command, for, I suspect, it's been already 
inserted by BIN_LINK_LIST. In fact, looking at the libraries, you see 
that libboost_regex.a, shows up twice most likely because CMake 
recognizes it as a static library, while BbrGeom, which is static too 
but not "fully qualified" by its path/name, is dropped.

I also noticed that, for example, ErrLogger too is listed twice but is 
always referred to as -lErrLogger, not with the full path/name. The same 
happens to CLHEP. The one that disappears is just BbrGeom. I also made a 
reverse check avoiding the build of BbrGeom package with cmake and 
treating it as a "external" library. In this case the list is preserved 
and BbrGeom shows up twice.

/usr/bin/c++ 
CMakeFiles/TrkDifPieceTrajTest.dir/bins/TrkDifPieceTrajTest.cc.o  -o 
TrkDifPieceTrajTest 
-L/home/corvo/SuperB/FastSim/V0.2.7_RC6/lib/Linux26SL5_i386_gcc412 
-L/data/exp_software/superb/releases/FastSim/V0.2.7/lib/Linux26SL5_i386_gcc412 
-L/data/exp_software/superb/cern/root/5.26/lib 
-L/data/exp_software/superb/cern/clhep/2.0.3.2/lib 
../../../lib/Linux26SL5_i386_gcc412/libTrkBase.a -lBbrGeom -ldifAlgebra 
-lm -lErrLogger -lBbrStdUtils /usr/lib/libboost_regex.a -lBaBar -lCLHEP 
-lCLHEP-2.0.3.2 -lTrajGeom -lPDT -lCommonUtils -lgfortran -lProbTools 
-lExperiment -lBField -lBbrGeom -ldifAlgebra -lm -lAssocTools -lAbsEvent 
-lAbsEnv -lProxyDict -lErrLogger -lBbrStdUtils /usr/lib/libboost_regex.a 
-lBaBar -lCLHEP -lCLHEP-2.0.3.2

To sum up it looks to me as if CMake, when manages the build of a static 
library directly and has to link it to an executable, then drops off all 
other occurencies of that lib, if any is found along the list of linking 
libraries, somehow treating them as dynamic libs. If otherwise the 
library is out of its control, then the list of libraries passed to 
target_link_libraries is preserved.
The only way to keep also the other occurency, which I need as TrajGeom 
depends on BbrGeom, is to declare BbrGeom with its full path/name, so 
that CMake is forced to consider it static.

I tried to set CMAKE_EXE_LINKER_FLAGS -static and -Bstatic, but the 
point is not with the linker, but in the way CMake itself considers 
libraries internally when managing target_link_libraries lists.

Sorry for the very long mail. Hope that the problem I'm facing is clear.

Marco


On 2/2/11 4:13 PM, Michael Hertling wrote:
> On 02/02/2011 03:04 PM, Marco wrote:
>> Hi all,
>>
>> I'm wondering, if I understood correctly the behaviour of CMake, whether
>> there'a a way to prevent CMake from deleting duplicated libraries in a
>> target_link_libraries list.
>>
>> I have an executable which links against (all static) libraries A, B and
>> C. A itself links against C,D,E... and so on. When CMake creates the
>> link.txt file what I see is:
>>
>> c++ -o myExe -lA -lC -lD -lE -lB
>>
>> that is cmake links the executable against A followed by its dependents,
>> then against B but not against C. The point is that B needs C to follow
>> it as B depends on C. This is why I suspect that CMake removes the
>> duplicated libraries listed in a target_link_libraries directive.
>>
>> Is it correct? And is there a way to force CMake to preserve exactly the
>> list of libraries passed to target_link_libraries?
>
> If B depends on C without C appearing after B in the link command, this
> probably means that CMake isn't aware of the B-on-C dependency, so how
> do you establish the latter? Could you provide a minimal but complete
> example which demonstrates this issue?
>
> AFAIK, CMake does not remove libraries from the link command if they
> are necessary to resolve any dependencies and if these dependencies
> are set up correctly, so the libraries' exact order - for library
> targets - is nothing the user usually needs to worry about.
>
> Regards,
>
> 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

-- 
Marco Corvo
SuperB experiment
CNRS - Orsay