Hello Michael Wild,<br><br>I regret deciding to go with an Python parser for my application. I use
such a small subset of the API, I was hoping to be able to rerelease my
app everytime it changes.<br>
<br>
Apparently Python 2.6 is frozen.<br><br>In the future, the Python people are
hoping to stabilize the ABI in the 3 series so that I can just link
against a libpython3.so:<br>
<a href="http://www.python.org/dev/peps/pep-0384/">http://www.python.org/dev/peps/pep-0384/</a><br><br>As stated by Michael Hertling, the symlinks are not being recursively resolved. The soname is encoded into the so, so the linker chooses to ignore the original filename.<br>
<br>Regards,<br><br>Juan<br>
<br><div class="gmail_quote">On Thu, Dec 30, 2010 at 6:23 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com" target="_blank">themiwi@gmail.com</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>On 12/30/2010 12:28 AM, j s wrote:<br>
</div><div><div></div><div>> 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>
><br>
> Regards,<br>
><br>
> Juan<br>
<br>
</div></div>There's nothing CMake can do about this, this is the linker getting in<br>
your way. E.g. on my Ubuntu, /usr/lib/<a href="http://libpython2.6.so" target="_blank">libpython2.6.so</a> is a symlink to<br>
/usr/lib/libpython2.6.so.1 which itself is a symlink to<br>
/usr/lib/libpython2.6.so.1.0. The linker recursively resolves all<br>
symlinks during the linking, and CMake can't do anything about it. You<br>
could pass the full path to the /usr/lib/<a href="http://libpython2.6.so" target="_blank">libpython2.6.so</a> symlink instead<br>
of -lpython2.6 and you would still get the same result.<br>
<br>
Actually, this is considered to be a feature. This way, newly compiled<br>
programs will always link against the "current" version (the one pointed<br>
to by the symlink-chain), while old programs can still use older<br>
versions of the library without requiring to be recompiled.<br>
<font color="#888888"><br>
Michael<br>
</font><div><div></div><div><br>
<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>
</div></div></blockquote></div><br>