Re: [CMake] linking: absolute path vs -l
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
Re: [CMake] linking: absolute path vs -l
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
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
Re: [CMake] linking: absolute path vs -l
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
Re: [CMake] linking: absolute path vs -l
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
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
Re: [CMake] linking: absolute path vs -l
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
Re: [CMake] linking: absolute path vs -l
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"
:
>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
Re: [CMake] linking: absolute path vs -l
> 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
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
Re: [CMake] linking: absolute path vs -l
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
[CMake] linking: absolute path vs -l
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
