On 12/31/2010 03:43 PM, Michael Wild wrote: > On 12/31/2010 02:48 PM, Michael Hertling wrote: >> 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 <[email protected]> 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 > > > Ahh, yes, I see. Learned something new ;-) But still, not exactly a > CMake-issue, [...]
It's usual *nix/ELF business. > [...] although replacing full paths with -l flags might cause > wrong libraries from being picked up if a -L flag happens to be > specified before the library, right? Even if -L appears after the library it remains a pitfall as all -L options apply to all -l ones, regardless of their order. So, IMO, the rule of thumb should be: Always use full paths for libraries but never use -L, neither explicitly in TARGET_LINK_LIBRARIES(), LINK_FLAGS etc. nor indirectly via LINK_DIRECTORIES(), and if there's any trouble with CMake's decision to use -l because the library resides in a well known system directory, use the imported-target approach to enforce a full path in that case, too. Regards and Happy New Year, 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
