[CMake] linking: absolute path vs -l<libname>

Nico Schlömer nico.schloemer at gmail.com
Wed Sep 2 04:22:08 EDT 2015


> 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 <a.neundorf-work at gmx.net>
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150902/43efe1d3/attachment-0001.html>


More information about the CMake mailing list