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