[CMake] CMAKE uses wrong symlink to so

[j s]

Thanks for the explanation.

It appears I am at the mercy of how the python library was created.  Since
python can never seem to commit to a stable ABI, I guess I'll have to be
wary of this issue.

Regards,

Juan

On Thu, Dec 30, 2010 at 3:19 AM, Michael Hertling <mhertling at online.de>wrote:

> On 12/30/2010 12:28 AM, j s wrote:
> > I specified the full name to an so in CMAKE 2.8.1.  Unfortunately it
> links
> > against the versioned so name,
> > libpython2.6.so.1.0
> >
> > instead of the exact name I specified.
> > /usr/lib/libpython2.6.so
> >
> > SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
> > TARGET_LINK_LIBRARIES (myapp  parser engine ${PYTHON_ARCHIVE}
> > ${OPENSSL_ARCHIVE})
> >
> > Is there any way to tell cmake to do the right thing in Linux?  For some
> > strange reason using -l on the link line, and doesn't even use the
> > corresponding -L to the path I specify.
> >   -lpython2.6
>
> See [1] for an explanation of the latter behavior. Nevertheless, I
> can confirm that - on my system - /usr/lib/libpython2.5.so turns to
> -lpython2.5 whereas /usr/lib/libpython2.5.so.1{,.0} do not. Here, I
> assume that CMake just uses the well-known extensions .so and .a when
> deciding whether a file specification denotes a library in an implicit
> system location, so /usr/lib/libpython2.5.so is identified as such one,
> but /usr/lib/libpython2.5.so.1{,.0} are not. This results in full paths
> in the linker's command line for the latters and a -l option without an
> appropriate -L one for the former. Use the trick with imported targets
> to force a full path for the /usr/lib/libpythonX.X.so library, too.
>
> However, the fact that your target links against libpython2.6.so.1.0
> instead of libpython2.6.so is no CMake issue, but relates to that
> library's soname; try
>
> readelf -d /usr/lib/libpython2.6.so | grep SONAME
>
> and see ld's manpage, in particular:
>
> "-soname=name
>   When creating an ELF shared object, set the internal DT_SONAME field
>   to the specified name.  When an executable is linked with a shared
>   object which has a DT_SONAME field, then when the executable is run
>   the dynamic linker will attempt to load the shared object specified
>   by the DT_SONAME field rather than the using the file name given to
>   the linker."
>
> 'hope that helps.
>
> Regards,
>
> Michael
>
> > [1]
> http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101230/81ada0f2/attachment.htm>