[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] make target export file follow symlinks (or something better?)
From: Andreas Pakulat <apaku () gmx ! de>
Date: 2014-08-23 9:01:15
Message-ID: CAExHGmTdcax5PejhcD39GFDNMXhEGrAD84wThaOp6_inozq43Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
On Sat, Aug 23, 2014 at 8:12 AM, Nico Schlömer <nico.schloemer@gmail.com>
wrote:
> Hi all,
>
> I'm linking my shared library against
> ```
> /usr/lib/x86_64-linux-gnu/libhdf5.so -> libhdf5.so.7.0.0
> /usr/lib/x86_64-linux-gnu/libhdf5.so.7 -> libhdf5.so.7.0.0
> /usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0
> ```
> resulting in the dynamic dependency
> ```
> $ ldd mylib.so.1.0.0 | grep hdf5
> libhdf5.so.7 => /usr/lib/x86_64-linux-gnu/libhdf5.so.7 (0x00007f50179e2000)
> ```
> The export file `mylibTargets.cmake` however lists
> ```
> set_target_properties(mylib PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
> INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/libhdf5.so"
> )
> ```
> (without the so-version). This is not good since this symlink might
> not be present when I configure a project against mylib. And it
> doesn't have to be either:
Actually it does have to be there (or rather it will be there).
> > All I need is
> `/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by `ldd`.
>
No, what you also need are the headers of that library, i.e. the
'development' part of the library installation. Since those development
parts are usually mutually exclusively installable between different
versions there's going to be only 1 installed. So the .so symlink will be
there and hence the linking will work. If the symlink links to a different
so-version the linker will abort when trying to link against mylib.
The only exception would be if your mylib does not expose any of the API
that hdf5 provides and a user of mylib does not need to know or care that
you're using hdf5. In that case you should drop that library from your
public link interface. That'll automatically drop the imported target in
the export file, as the linker does not need to know what mylib links
against when linking an app against mylib. (at least for shared libraries).
Andreas
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug \
23, 2014 at 8:12 AM, Nico Schlömer <span dir="ltr"><<a \
href="mailto:nico.schloemer@gmail.com" \
target="_blank">nico.schloemer@gmail.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi all,<br> <br>
I'm linking my shared library against<br>
```<br>
/usr/lib/x86_64-linux-gnu/libhdf5.so -> libhdf5.so.7.0.0<br>
/usr/lib/x86_64-linux-gnu/libhdf5.so.7 -> libhdf5.so.7.0.0<br>
/usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0<br>
```<br>
resulting in the dynamic dependency<br>
```<br>
$ ldd mylib.so.1.0.0 | grep hdf5<br>
libhdf5.so.7 => /usr/lib/x86_64-linux-gnu/libhdf5.so.7 (0x00007f50179e2000)<br>
```<br>
The export file `mylibTargets.cmake` however lists<br>
```<br>
set_target_properties(mylib PROPERTIES<br>
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"<br>
INTERFACE_LINK_LIBRARIES "/usr/lib/x86_64-linux-gnu/libhdf5.so"<br>
)<br>
```<br>
(without the so-version). This is not good since this symlink might<br>
not be present when I configure a project against mylib. And it<br>
doesn't have to be either:</blockquote><div><br></div><div>Actually it does have \
to be there (or rather it will be there).</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> > All I need is<br>
`/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by \
`ldd`.<br></blockquote><div><br></div><div>No, what you also need are the headers of \
that library, i.e. the 'development' part of the library installation. Since \
those development parts are usually mutually exclusively installable between \
different versions there's going to be only 1 installed. So the .so symlink will \
be there and hence the linking will work. If the symlink links to a different \
so-version the linker will abort when trying to link against mylib.</div> \
<div><br></div><div>The only exception would be if your mylib does not expose any of \
the API that hdf5 provides and a user of mylib does not need to know or care that \
you're using hdf5. In that case you should drop that library from your public \
link interface. That'll automatically drop the imported target in the export \
file, as the linker does not need to know what mylib links against when linking an \
app against mylib. (at least for shared libraries).</div> \
<div><br></div><div>Andreas</div></div></div></div>
--
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic