On 12/31/2010 11:56 AM, Michael Wild wrote:
> 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...
No, it's the soname that gets incorporated in the resulting binary;
recursively resolving the symlinks is insignificant in this regard:
echo "void f(void){}" > f.c
echo "void g(void){}" > g.c
gcc -o libf.so -shared -fPIC -Wl,-soname,xyz f.c
gcc -o libg.so.1.0 -shared -fPIC g.c
ln -sf libg.so.1.0 libg.so.1
ln -sf libg.so.1 libg.so
ls -l libg.so*
... libg.so -> libg.so.1
... libg.so.1 -> libg.so.1.0
... libg.so.1.0
echo "int main(void){return 0;}" > main.c
gcc -o main main.c libf.so libg.so
LD_LIBRARY_PATH=. ldd main
...
xyz => not found
libg.so => ./libg.so (0xb7fbd000)
...
A recursive symlink resolution would make the main executable being
linked against libg.so.1.0 instead of libg.so. In fact, main is linked
against the library specified by the soname - if present - even if that
library doesn't exist at all like xyz in the example above. If there is
no soname the linker incorporates the library as denoted on the command
line. With libpython2.6, the executable is linked against .so.1.0 since
this is the library's soname, but not due to the .so-->so.1-->.so.1.0
symlink resolution. BTW, the soname denoting the non-existing xyz is
completely artificial, of course, and designed only to clarify the
concern. Usually, ldconfig ensures that there is a valid symlink
soname --> actual library file.
Regards,
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
