[CMake] Removing SONAME from .so.* (Re: binary contains an unresolvable reference to symbol sym)

Mathieu Malaterre mathieu.malaterre at gmail.com
Fri Apr 13 07:28:38 EDT 2012


Dear all,

I have been going over the cmake code. I can clearly see the
IMPORTED_NO_SONAME property for IMPORTED libraries. However I still
could not find how to skip the explicit setting of -Wl,-soname on
either add_library( SHARED ) or add_library( MODULE ). My system is
debian/linux.

Instead does anyone knows of a platform specific tools to remove
SONAME from .so.* files ? Much like the chrpath would do for RPATH.

Thanks very much !

On Thu, Apr 12, 2012 at 2:03 PM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
> Dear all,
>
>  I am trying to solve one remaining issue with one of my package in
> debian [1]. The report says basically "binary  contains an
> unresolvable reference to symbol sym". According to the documentation
> [2]:
>
>              The indicated symbol has not been found in the libraries  linked
>              with the binary. The binary is most likely a plugin and the sym-
>              bol is probably provided by the program that loads this  plugin.
>              In  theory a plugin doesn't have any SONAME but this binary does
>              have one and as such it could not be clearly identified as such.
>              However  the  fact  that  the  binary  is stored in a non-public
>              directory is a strong indication that's it's not a normal shared
>              library.  If  the binary is really a plugin, then disregard this
>              warning. But there's always the possibility  that  it's  a  real
>              library  and  that  programs linking to it are using an RPATH so
>              that the dynamic loader finds it. In that case, the  library  is
>              broken and needs to be fixed.
>
> The solution seems pretty straightforward: remove the -soname command
> line switch when generating the python module. Looking at:
> Modules/CMakeCInformation.cmake I can see:
>
> ...
> IF(NOT CMAKE_C_CREATE_SHARED_MODULE)
>  SET(CMAKE_C_CREATE_SHARED_MODULE ${CMAKE_C_CREATE_SHARED_LIBRARY})
> ENDIF(NOT CMAKE_C_CREATE_SHARED_MODULE)
> ...
>
>  So basically /module/ and /shared/ behave exactly the same on *nix
> platform, correct ? If so how is someone supposed to remove the
> explicit setting of CMAKE_SHARED_LIBRARY_SONAME_C_FLAG in such case ?
>
> For example on my system I can see:
>
> $ readelf -d /usr/lib/pyshared/python2.7/_gdcmswig.so | grep SONAME
>  0x000000000000000e (SONAME)             Library soname: [_gdcmswig.so]
>
> While in another package (using python distutils/setup.py):
>
> $ readelf -d /usr/lib/python2.7/dist-packages/libtiff/tif_lzw.so  | grep SONAME
> -> no output
>
>
>
> Thanks much in advance,
>
> [1] https://buildd.debian.org/~brlink/packages/g/gdcm.html
> [2] http://man.he.net/man1/dpkg-shlibdeps
> --
> Mathieu



-- 
Mathieu


More information about the CMake mailing list