[CMake] Installing shared libs with symlinks

[Martin Apel]

Philip Lowman wrote:
> On Fri, Dec 12, 2008 at 9:34 AM, Martin Apel <martin.apel at simpack.de
> <mailto:martin.apel at simpack.de>> wrote:
>
>     Philip Lowman wrote:
>     > On Wed, Dec 10, 2008 at 4:04 AM, Martin Apel
>     <martin.apel at simpack.de <mailto:martin.apel at simpack.de>
>     > <mailto:martin.apel at simpack.de <mailto:martin.apel at simpack.de>>>
>     wrote:
>     >
>     >     Hi there,
>     >
>     >     I am trying to install the boost libraries my software needs
>     into the
>     >     target installation directory as follows:
>     >
>     >     Find_Package(Boost 1.34.1 COMPONENTS filesystem system signals
>     >     program_options REQUIRED)
>     >     FOREACH (Lib ${Boost_FILESYSTEM_LIBRARY} ${Boost_SYSTEM_LIBRARY}
>     >     ${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})
>     >      INSTALL(PROGRAMS ${Lib} DESTINATION run/bin)
>     >     ENDFOREACH (Lib ${Boost_FILESYSTEM_LIBRARY}
>     ${Boost_SYSTEM_LIBRARY}
>     >     ${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})
>     >
>     >     The variables returned from FindBoost contain symlinks to
>     the real
>     >     libraries, e.g.
>     >      libboost_system-gcc43-mt-1_35.so ->
>     >     libboost_system-gcc43-mt-1_35.so.1.35.0
>     >
>     >     When installing these the files in the destination directory are
>     >     symlinks again, which is not what I want. I tried using
>     >        GET_FILENAME_COMPONENT(LibWithoutSymLink ${Lib} ABSOLUTE)
>     >     in the above loop, but this does not help, the returned path
>     still
>     >     does
>     >     not contain the resolved name. This looks to me like a bug
>     in the
>     >     implementation
>     >     of GET_FILENAME_COMPONENT. Is there any recommended way to
>     install
>     >     referenced libraries including resolving any symlinks?
>     >
>     >
>     > You could file a feature request to have that implemented.
>      Ultimately
>     > though that won't be portable because on Windows it would
>     resolve to a
>     > ".lib" when you would want a ".dll".  And you probably want
>     something
>     > that works now for this.
>     >
>     >
>     > Boost_INCLUDE_DIR in conjuction with FILE(GLOB...) and INSTALL()
>     would
>     > probably work much better for you.  Perhaps something like this?
>     >
>     > FILE(GLOB my_boost_system_libs
>     > ${Boost_INCLUDE_DIR}/lib/libboost_system*.so)
>     > IF(my_boost_system_libs)
>     >      INSTALL(FILES ${my_boost_system_libs} DESTINATION lib)
>     > ENDIF()
>     >
>     > Obviously you would need two GLOB's for this to be portable to
>     WIN32.
>     Hi Philip,
>
>     I tried to avoid this, because the naming scheme for Boost
>     libraries is
>     complicated (compiler version, threading). Therefore I used the
>     variables provided by FindBoost to get the names. Anyway I would have
>     expected GET_FILENAME_COMPONENT to return the referenced file,
>     which it
>     doesn't. I'm still not sure, if this is a bug or expected behaviour?
>
>
> This looks like a missing feature request and not a bug.  I would
> request an option be added to GET_FILENAME_COMPONENT that follows
> symbolic links recursively back to their source (CANONICALIZE
> perhaps?).  In the meantime you can use the "readlink" program to do
> this for you.
Hi Philip,

to me it looks more like a bug, because the documentation for
GET_FILENAME_COMPONENT states, that for ABSOLUTE the file name is
returned without symlinks.
Anyway at least under Unix I could use readlink, but then I will have to
do platform-dependant stuff here, which I tried to avoid.

Regards,

Martin

____________
Virus checked by G DATA AntiVirus
Version: AVF 19.219 from 12.01.2009