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 <mhertl...@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 >
_______________________________________________ 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