On 12/30/2010 07:55 PM, j s wrote:
> Hello Michael Wild,
>
> 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.
>
> Apparently Python 2.6 is frozen.
>
> 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:
> http://www.python.org/dev/peps/pep-0384/
>
> 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.
>
> Regards,
>
> Juan
>
> On Thu, Dec 30, 2010 at 6:23 AM, Michael Wild <them...@gmail.com> 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
>>>
>>>
>>> Regards,
>>>
>>> Juan
>>
>> There's nothing CMake can do about this, this is the linker getting in
>> your way. E.g. on my Ubuntu, /usr/lib/libpython2.6.so is a symlink to
>> /usr/lib/libpython2.6.so.1 which itself is a symlink to
>> /usr/lib/libpython2.6.so.1.0. The linker recursively resolves all
>> symlinks during the linking, and CMake can't do anything about it. You
>> could pass the full path to the /usr/lib/libpython2.6.so symlink instead
>> of -lpython2.6 and you would still get the same result.
>>
>> Actually, this is considered to be a feature. This way, newly compiled
>> programs will always link against the "current" version (the one pointed
>> to by the symlink-chain), while old programs can still use older
>> versions of the library without requiring to be recompiled.
>>
>> Michael
Huh?
$ echo "int main(){}" | gcc -x c -c -o test.o -
$ gcc test.o /usr/lib/libpython2.6.so
$ ldd a.out | grep libpython2.6
libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0x00007fbb350f1000)
$ ls -l /usr/lib/libpython2.6.so*
... /usr/lib/libpython2.6.so -> libpython2.6.so.1
... /usr/lib/libpython2.6.so.1 -> libpython2.6.so.1.0
... /usr/lib/libpython2.6.so.1.0
Sure looks like recursive symlink resolution to me...
Michael
_______________________________________________
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
