(Again, changing title, but not message ID references.)
On Sep 24, 2010, at 12:12 PM, H.sivank wrote:
> Le 24 sept. 2010 à 15:55, Joerg Mayer a écrit :
>> Btw, can you please provide me with a log what and how things fail when
>> you build with "set(LINK_MODE_MODULE MODULE)" instead of SHARED?
>
> This is the log with LINK_MODE_MODULE set to MODULE :
>
> Linking C shared module ../../lib/asn1.so
> cd /Users/laurent/Desktop/wireshark/build/plugins/asn1 && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/asn1.dir/link.txt --verbose=1
> /usr/bin/gcc -bundle -headerpad_max_install_names -compatibility_version 1.5.0 -o ../../lib/asn1.1.5.0.so CMakeFiles/asn1.dir/plugin.c.o CMakeFiles/asn1.dir/packet-asn1.c.o CMakeFiles/asn1.dir/asn1.c.o ../../lib/libwireshark.dylib ../../lib/libwiretap.dylib /usr/lib/libz.dylib ../../lib/libwsutil.dylib /usr/lib/libpcre.dylib /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libgmodule-2.0.dylib /opt/local/lib/libgthread-2.0.dylib /opt/local/lib/libintl.dylib /usr/lib/libpcap.dylib /opt/local/lib/libcares.dylib /usr/lib/libkrb5.dylib /opt/local/lib/libgcrypt.dylib /opt/local/lib/libgpg-error.dylib /opt/local/lib/libgnutls.dylib /opt/local/lib/libsmi.dylib /usr/lib/libm.dylib /opt/local/lib/liblua.a
> i686-apple-darwin10-gcc-4.2.1: -compatibility_version only allowed with -dynamiclib
Translated into something slightly closer to English, that means "you can only specify shared library version numbers if you're actually building a shared library".
OS X used to be more different from other UN*Xes in the past, when you had "dynamic shared libraries" - MH_DYLIB - and "run-time loadable bundles" - MH_BUNDLE - and only the former could be linked to with -l and only the latter could be loaded at run time. Now MH_DYLIBs can be loaded at run time as well; I suspect that was done for compatibility with other UN*Xes, to allow them to load libraries at run time.
CMake is using -bundle rather than -dylib/-dynamiclib to build the asn1 plugin, probably so that it'll work even on versions of OS X where you can't dynamically load an MH_DYLIB. That means you can't specify -compatibility_version.
We appear to be setting the SOVERSION property when building plugins; the cmake 2.6 documentation says
For shared libraries VERSION and SOVERSION can be used to specify the build version and api version respectively. When building or installing appropriate symlinks are created if the platform supports symlinks and the linker supports so-names. If only one of both is specified the missing is assumed to have the same version number. For executables VERSION can be used to specify the build version. When building or installing appropriate symlinks are created if the platform supports symlinks. For shared libraries and executables on Windows the VERSION attribute is parsed to extract a "major.minor" version number. These numbers are used as the image version of the binary.
I'm not sure it's appropriate to set those versions for a plugin - they aren't shared libraries, so all the versioning stuff for shared libraries on various platforms still applies. They shouldn't be installed with sonames - it should just be "asn1.so", not "asn1.so.1.5.0" with a symlink to "asn1.so" - and they shouldn't be built with -compatibility_version or -current_version on OS X, or with -soname on platforms using the GNU linker, or with +h on HP-UX with the HP linker, or with -h on Solaris with the Sun linker, and so on.
What happens if we remove all the set_target_properties calls in the CMakeLists.txt files for the plugins - but revert to using MODULE as the link mode for the plugins?
(Oh, and why are we *not* setting the version numbers for libwiretap, libwireshark, and libwsutil in CMake? Those *are* shared libraries....)
