linking: absolute path vs -l<libname>

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

linking: absolute path vs -l<libname>

Nico Schlömer-3
Hi everyone,

I'm curious about when CMake decides to link a library by its absolute path and when it links using the `-l*` syntax. I came across this for the very simple test problem
```
cmake_minimum_required(VERSION 3.0)

project(mytest)

find_package(ZLIB REQUIRED)
find_package(netCDF REQUIRED)

add_executable(mytest main.cpp)
target_link_libraries(
  mytest
  ${ZLIB_LIBRARIES}
  ${netCDF_LIBRARIES}
  )
```
The resulting link line is
```
/usr/bin/c++       CMakeFiles/mytest.dir/main.cpp.o  -o mytest -rdynamic -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 
```
so ZLIB is linked with `-lz`, netCDF with the full absolute path.

Seems inconsistent? (ZLIB by the way is found through CMake's FindZLIB.cmake, netCDF by their own export files.)

So far, I had been under the impression that `-l*` defeats the purpose of CMake a little bit as it asks the linker to search in the system's paths for a libz.so, something CMake has already done.

A little clarification here would be great.

Cheers,
Nico

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Alexander Neundorf-3
On Friday, August 28, 2015 08:23:47 Nico Schlömer wrote:

> Hi everyone,
>
> I'm curious about when CMake decides to link a library by its absolute path
> and when it links using the `-l*` syntax. I came across this for the very
> simple test problem
> ```
> cmake_minimum_required(VERSION 3.0)
>
> project(mytest)
>
> find_package(ZLIB REQUIRED)
> find_package(netCDF REQUIRED)
>
> add_executable(mytest main.cpp)
> target_link_libraries(
>   mytest
>   ${ZLIB_LIBRARIES}
>   ${netCDF_LIBRARIES}
>   )
> ```
> The resulting link line is
> ```
> /usr/bin/c++       CMakeFiles/mytest.dir/main.cpp.o  -o mytest -rdynamic
> -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
> ```
> so ZLIB is linked with `-lz`, netCDF with the full absolute path.
>
> Seems inconsistent? (ZLIB by the way is found through CMake's
> FindZLIB.cmake, netCDF by their own export files.)
>
> So far, I had been under the impression that `-l*` defeats the purpose of
> CMake a little bit as it asks the linker to search in the system's paths
> for a libz.so, something CMake has already done.
>
> A little clarification here would be great.

it uses -l if the full path is not know or if the full path is one of the
system library dirs (like e.g. /usr/lib/ or the, IIRC, $LIBRARY_PATH env.var)

Alex

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Nico Schlömer-3
> it uses -l if the full path is not know or if the full path is one of the system library dirs

Hm, that sound a little weird. Using `-l` appears to delegate the library finding to the linker although CMake has already done that job. If one was overly cautious, one could ask questions like: What if there are two libraries by the same name in different system library dirs? What if there's only one library in a system dir at configure time, but two at link time?

Moreover, in the example I gave above it seems that both libraries are in the system path, yet still they are represented differently on the link line.

--Nico

On Mon, Aug 31, 2015 at 10:33 PM Alexander Neundorf <[hidden email]> wrote:
On Friday, August 28, 2015 08:23:47 Nico Schlömer wrote:
> Hi everyone,
>
> I'm curious about when CMake decides to link a library by its absolute path
> and when it links using the `-l*` syntax. I came across this for the very
> simple test problem
> ```
> cmake_minimum_required(VERSION 3.0)
>
> project(mytest)
>
> find_package(ZLIB REQUIRED)
> find_package(netCDF REQUIRED)
>
> add_executable(mytest main.cpp)
> target_link_libraries(
>   mytest
>   ${ZLIB_LIBRARIES}
>   ${netCDF_LIBRARIES}
>   )
> ```
> The resulting link line is
> ```
> /usr/bin/c++       CMakeFiles/mytest.dir/main.cpp.o  -o mytest -rdynamic
> -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
> ```
> so ZLIB is linked with `-lz`, netCDF with the full absolute path.
>
> Seems inconsistent? (ZLIB by the way is found through CMake's
> FindZLIB.cmake, netCDF by their own export files.)
>
> So far, I had been under the impression that `-l*` defeats the purpose of
> CMake a little bit as it asks the linker to search in the system's paths
> for a libz.so, something CMake has already done.
>
> A little clarification here would be great.

it uses -l if the full path is not know or if the full path is one of the
system library dirs (like e.g. /usr/lib/ or the, IIRC, $LIBRARY_PATH env.var)

Alex


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Hendrik Sattler
In reply to this post by Nico Schlömer-3
Hi,

is the netcdf find module defining an imported target? AFAIK, imported targets are always linked by full path. Else the rules already mentioned apply.

HS


Am 28. August 2015 10:23:47 MESZ, schrieb "Nico Schlömer" <[hidden email]>:
Hi everyone,

I'm curious about when CMake decides to link a library by its absolute path and when it links using the `-l*` syntax. I came across this for the very simple test problem
```
cmake_minimum_required(VERSION 3.0)

project(mytest)

find_package(ZLIB REQUIRED)
find_package(netCDF REQUIRED)

add_executable(mytest main.cpp)
target_link_libraries(
  mytest
  ${ZLIB_LIBRARIES}
  ${netCDF_LIBRARIES}
  )
```
The resulting link line is
```
/usr/bin/c++       CMakeFiles/mytest.dir/main.cpp.o  -o mytest -rdynamic -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 
```
so ZLIB is linked with `-lz`, netCDF with the full absolute path.

Seems inconsistent? (ZLIB by the way is found through CMake's FindZLIB.cmake, netCDF by their own export files.)

So far, I had been under the impression that `-l*` defeats the purpose of CMake a little bit as it asks the linker to search in the system's paths for a libz.so, something CMake has already done.

A little clarification here would be great.

Cheers,
Nico

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Alexander Neundorf-3
In reply to this post by Nico Schlömer-3
On Wednesday, September 02, 2015 08:22:08 Nico Schlömer wrote:

> > it uses -l if the full path is not know or if the full path is one of the
> > system
> library dirs
>
> Hm, that sound a little weird. Using `-l` appears to delegate the library
> finding to the linker although CMake has already done that job. If one was
> overly cautious, one could ask questions like: What if there are two
> libraries by the same name in different system library dirs? What if
> there's only one library in a system dir at configure time, but two at link
> time?
>
> Moreover, in the example I gave above it seems that both libraries are in
> the system path, yet still they are represented differently on the link
> line.

what values do ${ZLIB_LIBRARIES} and ${netCDF_LIBRARIES} have in your case ?

Alex

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Nico Schlömer-3
Curiously,
```
message(${ZLIB_LIBRARIES})
message(${netCDF_LIBRARIES})
```
yields
```
/usr/lib/x86_64-linux-gnu/libz.so
netcdf
```
Hm, I would have expected it the other way around. :)

--Nico

On Wed, Sep 2, 2015 at 10:17 PM Alexander Neundorf <[hidden email]> wrote:
On Wednesday, September 02, 2015 08:22:08 Nico Schlömer wrote:
> > it uses -l if the full path is not know or if the full path is one of the
> > system
> library dirs
>
> Hm, that sound a little weird. Using `-l` appears to delegate the library
> finding to the linker although CMake has already done that job. If one was
> overly cautious, one could ask questions like: What if there are two
> libraries by the same name in different system library dirs? What if
> there's only one library in a system dir at configure time, but two at link
> time?
>
> Moreover, in the example I gave above it seems that both libraries are in
> the system path, yet still they are represented differently on the link
> line.

what values do ${ZLIB_LIBRARIES} and ${netCDF_LIBRARIES} have in your case ?

Alex


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Alexander Neundorf-3
On Wednesday, September 02, 2015 20:28:35 Nico Schlömer wrote:

> Curiously,
> ```
> message(${ZLIB_LIBRARIES})
> message(${netCDF_LIBRARIES})
> ```
> yields
> ```
> /usr/lib/x86_64-linux-gnu/libz.so
> netcdf
> ```
> Hm, I would have expected it the other way around. :)


maybe "netcdf" is the name of an imported target.
Can you check that (e.g. by trying to get a target property from it and if so
, figure out the attached location ?

Alex

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Nico Schlömer-3
Indeed,
```
get_target_property(out ${netCDF_LIBRARIES} LOCATION)
message(${out})
```
gives
```
/usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
```
This value appears to be set in the CMake export file
```
/usr/lib/x86_64-linux-gnu/cmake/netCDF/netCDFTargets-none.cmake
```
What does this mean?

--Nico

On Wed, Sep 2, 2015 at 10:46 PM Alexander Neundorf <[hidden email]> wrote:
On Wednesday, September 02, 2015 20:28:35 Nico Schlömer wrote:
> Curiously,
> ```
> message(${ZLIB_LIBRARIES})
> message(${netCDF_LIBRARIES})
> ```
> yields
> ```
> /usr/lib/x86_64-linux-gnu/libz.so
> netcdf
> ```
> Hm, I would have expected it the other way around. :)


maybe "netcdf" is the name of an imported target.
Can you check that (e.g. by trying to get a target property from it and if so
, figure out the attached location ?

Alex


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: linking: absolute path vs -l<libname>

Alexander Neundorf-3
On Wednesday, September 02, 2015 22:12:39 Nico Schlömer wrote:

> Indeed,
> ```
> get_target_property(out ${netCDF_LIBRARIES} LOCATION)
> message(${out})
> ```
> gives
> ```
> /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
> ```
> This value appears to be set in the CMake export file
> ```
> /usr/lib/x86_64-linux-gnu/cmake/netCDF/netCDFTargets-none.cmake
> ```
> What does this mean?

this means that netcdf is a so-called "imported target".
I.e. for cmake, it is a library target, as those which are created when doing
add_library(foo foo.c bar.c blub.b),
but hass not been built by the project, but has been built and installed
before, and then during find_package() an "imported" target has been set up,
which has all necessary target properties set so it can be used the same way a
target which has been built inside cmake.

Maybe absolute paths of imported targets are handled differently, I'm not
sure.

Alex

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake