[CMake] Simple (?) lib linking question

Anders Sundman anders.sundman at optonova.se
Mon Aug 7 11:52:57 EDT 2006


> At 03:13 AM 8/7/2006, Anders Sundman wrote:
>>> At 04:08 AM 8/4/2006, Anders Sundman wrote:
>>>>Shouldn't the line:
>>>>-> C:\MinGW\bin\g++.exe    -shared -o liba.dll
>>>> -Wl,--out-implib,liba.dll.a "CMakeFiles/a.dir/a.obj" -lb
>>>>
>>>>also contain a -L switch since I have the line
>>>> "LINK_DIRECTORIES(${TEST_SOURCE_DIR}/b)" in the cmake file for the
>>>> "a"-lib?
>>>>
>>>>// Anders Sundman
>>>
>>> It is an ordering problem, you have this:
>>>
>>> ADD_LIBRARY(liba SHARED liba.cpp)
>>> INCLUDE_DIRECTORIES(${TEST_SOURCE_DIR}/libb)
>>> LINK_DIRECTORIES(${TEST_SOURCE_DIR}/libb)
>>> TARGET_LINK_LIBRARIES(liba libb)
>>>
>>> The LINK_DIRECTORIES command has to come before the ADD_LIBRARY
>>> command.
>>>
>>> -Bill
>>>
>>
>>Thank you so much! That was it; now I get the -L option I expected.
>>
>>The example still doesn't compile though :) There seems to be one more
>>problem with it, possibly related.
>>
>>It goes like this: app uses lib a that uses lib b. I have lib b, can
>>compile lib a, but when it's time to compile the app, the following build
>>command is generated by cmake:
>>
>>C:\MinGW\bin\g++.exe "CMakeFiles/app.dir/app.obj" -o ../app.exe
>>-Lc:\dev\lab\cmtest2\build\a -Lc:\dev\lab\cmtest2\build -la -lb
>>
>>But the "-lb" option shouldn't be there. The app doesn't want to know
>>about the b lib. If I manually remove it and compile "by hand" then it
>>works fine.
>>
>>The cmakelists file for the app never mentions the b lib, so why does
>>cmake put the -lb option there?
>>
>>This is the entire cmakelists file for the app directory:
>>
>>INCLUDE_DIRECTORIES(${TEST_SOURCE_DIR}/a)
>>LINK_DIRECTORIES(${TEST_BINARY_DIR}/a)
>>ADD_EXECUTABLE(app app.cpp)
>>TARGET_LINK_LIBRARIES(app a)
>
> This is a feature of cmake, it will chain libraries.  There is no
> way to turn it off.  Why would this be a problem?
>
> -Bill
>
>

Ah, ok. I see. So the way to fix it is by specifying the path to "b" with 
LINK_DIRECTORIES in both the "a" lib and the "app" cmakelists files?

In the future, if I would implement the "a" lib, using a "c" lib instead
of "b" lib, would I have to update the cmakelists files for all
(hypothetical) 500 projects using the "a" lib?

What is the rationale for this design desision? It seems to me that this
feature introduces an unnecessary dependency? It's not realy a big issue
for me, but I'm curious.

When creating an app that uses a lib "a", that in turn uses a lib "b". You
now have to have access to lib "b" to build the app. If libraries weren't
chained, you would only have to have access to lib "b" to run the app;
building it would be fine without access. I admit that this is a fairly
uncommon situation though.

// Anders




More information about the CMake mailing list