The name of the cmake generated dbus shared library differs from the related library generated by autotools. Autotools uses the versioned library name libdbus-1-3.dll, while cmake uses a non versioned file name e.g. libdbus-1.dll.
Created attachment 92930 [details] [review] Keep cmake generated shared library file name in sync with autotools for windows builds
Created attachment 92931 [details] [review] Keep cmake generated shared library file name in sync with autotools for windows builds minor subject fix
Created attachment 92935 [details] [review] Keep cmake generated shared library file name in sync with autotools on unix
*** Bug 42357 has been marked as a duplicate of this bug. ***
Just got a hint that libtool should use -version-number instead of -version-info, see https://github.com/chewing/libchewing/issues/55 for more informations.
Comment on attachment 92935 [details] [review] Keep cmake generated shared library file name in sync with autotools on unix Review of attachment 92935 [details] [review]: ----------------------------------------------------------------- ::: cmake/dbus/CMakeLists.txt @@ +277,5 @@ > target_link_libraries(dbus-1 ws2_32 advapi32 netapi32 iphlpapi) > endif(WINCE) > else(WIN32) > + if(DBUS_LIBRARY_REVISION) > + set_target_properties(dbus-1 PROPERTIES VERSION ${DBUS_LIBRARY_REVISION}.${DBUS_LIBRARY_AGE}.${DBUS_LIBRARY_REVISION} SOVERSION ${DBUS_LIBRARY_REVISION}) If you want it to match Autotools' logic, then the VERSION (assuming it has the same semantics as Linux library versioning) should be (current - age).age.revision, and the SOVERSION should be (current - age). Here is what libtool does on Linux: linux) # correct to gnu/linux during the next big refactor func_arith $current - $age major=.$func_arith_result versuffix="$major.$age.$revision" ;; and on Windows: windows) # Use '-' rather than '.', since we only want one # extension on DOS 8.3 filesystems. func_arith $current - $age major=$func_arith_result versuffix="-$major" ;; For instance, if we had a library with current=42, age=10, revision=23, what that means is: * the current ABI version is 42 * ABI version 42 is compatible with the previous ABI 10 versions (i.e. no ABI was deleted or changed incompatibly between versions 32 and 42) * there have been 23 "micro versions" that didn't change the ABI so we'd have libfoo.so.32, a symlink to libfoo.so.32.10.23. Compare with Linux library versioning, which behaves more like a version number: * major version increased every time we break ABI * minor version increased every time we add ABI * micro version increased every time we don't * when you increase any version you set the "smaller" versions to zero I can see why libtool -version-number is considered easier...
Comment on attachment 92931 [details] [review] Keep cmake generated shared library file name in sync with autotools for windows builds Review of attachment 92931 [details] [review]: ----------------------------------------------------------------- ::: cmake/CMakeLists.txt @@ -132,4 @@ > endif(VCS) > > if(WIN32) > - set(CMAKE_DEBUG_POSTFIX "d") I don't really know whether/why it's desirable to give the "debug" build a different name on Windows. I have some vague memory of the suffix indicating whether it was linked against a "debug" or "release" C runtime library, which are awkward to mix in one process-space because (for instance) FILE structs are different sizes? libdbus is quite careful not to put OS types like the FILE struct in its API, so that sort of thing probably doesn't matter for libdbus - unless it's unsafe to have both the "debug" and the "release" C runtime library in your process' memory at all. If it isn't desirable, sure, delete this. ::: cmake/dbus/CMakeLists.txt @@ +262,5 @@ > ${libdbus_HEADERS} > ) > if(WIN32) > + if(DBUS_LIBRARY_REVISION) > + get_target_property(LEGACY_FILE_NAME dbus-1 LOCATION) Does anything actually set this property?
(In reply to comment #5) > For instance, if we had a library with current=42, age=10, revision=23, what > that means is: > > * the current ABI version is 42 > * ABI version 42 is compatible with the previous ABI 10 versions > (i.e. no ABI was deleted or changed incompatibly between > versions 32 and 42) > * there have been 23 "micro versions" that didn't change the ABI > > so we'd have libfoo.so.32, a symlink to libfoo.so.32.10.23. ... and continuing that example, if we broke ABI in the next release, we'd have: * current ABI version is 43 * age=0, i.e. there is no previous version with which we are compatible * revision=0 and we'd have libfoo.so.43, a symlink to libfoo.so.43.0.0 (yes, this means that if you break ABI frequently, the major version gets large).
Comment on attachment 92931 [details] [review] Keep cmake generated shared library file name in sync with autotools for windows builds Review of attachment 92931 [details] [review]: ----------------------------------------------------------------- ::: cmake/modules/MacrosAutotools.cmake @@ +10,4 @@ > # ${prefix}_MAJOR_VERSION > # ${prefix}_MINOR_VERSION > # ${prefix}_MICRO_VERSION > +# ${prefix}_LIBRARY_REVISION DBUS_LIBRARY_REVISION is set by calling the macro autoversion in the main CMakeLists.txt
(In reply to comment #9) > DBUS_LIBRARY_REVISION is set by calling the macro autoversion in the main > CMakeLists.txt Yes, I realize that. What I'm complaining about is that you're setting the "version" and SOVERSION to: REVISION.AGE.REVISION REVISION where I'm pretty sure they should be: (CURRENT - AGE).AGE.REVISION (CURRENT - AGE) It isn't obvious at the moment because you'd get 3.8.3 either way. Try temporarily setting LT_REVISION to some large number like 123 in configure.ac - the desired result is libdbus-1-3.dll and libdbus.so.3.8.123, but I think what you'd actually get with these patches would be libdbus-1-123.dll and libdbus.so.123.8.123.
Created attachment 93016 [details] [review] Keep cmake generated shared dbus-1 library file name in sync with autotools (update 1) Follow real used autotools naming scheme
(In reply to comment #10) > (In reply to comment #9) > > DBUS_LIBRARY_REVISION is set by calling the macro autoversion in the main > > CMakeLists.txt > > Yes, I realize that. What I'm complaining about is that you're setting the > "version" and SOVERSION to: > > REVISION.AGE.REVISION > REVISION > > where I'm pretty sure they should be: > > (CURRENT - AGE).AGE.REVISION > (CURRENT - AGE) > > It isn't obvious at the moment because you'd get 3.8.3 either way. Try > temporarily setting LT_REVISION to some large number like 123 in > configure.ac - the desired result is libdbus-1-3.dll and libdbus.so.3.8.123, > but I think what you'd actually get with these patches would be > libdbus-1-123.dll and libdbus.so.123.8.123. Thanks for this explanation, got it now
(In reply to comment #7) > Comment on attachment 92931 [details] [review] [review] > Keep cmake generated shared library file name in sync with autotools for > windows builds > > Review of attachment 92931 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: cmake/CMakeLists.txt > @@ -132,4 @@ > > endif(VCS) > > > > if(WIN32) > > - set(CMAKE_DEBUG_POSTFIX "d") > > I don't really know whether/why it's desirable to give the "debug" build a > different name on Windows. I have some vague memory of the suffix indicating > whether it was linked against a "debug" or "release" C runtime library, > which are awkward to mix in one process-space because (for instance) FILE > structs are different sizes? yes. In the beginning of the KDE on windows project some external win32libs binary packages has been used which contains release and debug libraries distinguished by the debug postfix, which lead to the decision to let dbus also have a debug postfix. With increasing experience of the build system team all 3rd party packages are build from source to avoid incompatible configure time decisions and to get full control about the configure process. After been able to build all packages (about 200) from source, the next step was to use different build trees for each compiler and release/debug builds to avoid several problems (see below for examples). At least this obsolates debug postfix completly. > > libdbus is quite careful not to put OS types like the FILE struct in its > API, so that sort of thing probably doesn't matter for libdbus - unless it's > unsafe to have both the "debug" and the "release" C runtime library in your > process' memory at all. with msvc it is much more worse: If you instance a FILE struct in a release dll and provide it to a dll build in debug mode there may be crashes because of different struct member positions. :-( Also Qt explicit do not allow mixing of debug/release builds see for example http://code.google.com/p/drmemory/issues/detail?id=1345. Don't remember if this is msvc specific > > If it isn't desirable, sure, delete this. see above
Comment on attachment 93016 [details] [review] Keep cmake generated shared dbus-1 library file name in sync with autotools (update 1) Review of attachment 93016 [details] [review]: ----------------------------------------------------------------- ::: cmake/dbus/CMakeLists.txt @@ +261,4 @@ > ${libdbus_SOURCES} > ${libdbus_HEADERS} > ) > +if(DBUS_LIBRARY_REVISION) How can this condition be false? @@ +268,2 @@ > if(WIN32) > + if(DBUS_LIBRARY_REVISION) Likewise @@ +268,3 @@ > if(WIN32) > + if(DBUS_LIBRARY_REVISION) > + get_target_property(LEGACY_FILE_NAME dbus-1 LOCATION) If I'm understanding this correctly, we "read" a "variable" called LEGACY_FILE_NAME, but we never "write" it? How does it get its value? Are developers expected to call "cmake -DLEGACY_FILE_NAME=something" if they want this feature? @@ +281,5 @@ > target_link_libraries(dbus-1 ws2_32 advapi32 netapi32 iphlpapi) > endif(WINCE) > else(WIN32) > + if(DBUS_LIBRARY_REVISION) > + set_target_properties(dbus-1 PROPERTIES VERSION ${DBUS_LIBRARY_MAJOR}.${DBUS_LIBRARY_AGE}.${DBUS_LIBRARY_REVISION} SOVERSION ${DBUS_LIBRARY_MAJOR}) Just to check: in Autotools, what we get is: libdbus-1.so.${MAJOR}.${AGE}.${REVISION} (the real file) libdbus-1.so.${MAJOR} (symlink to real file) libdbus-1.so (symlink to real file) The symlink with the "major version" at the end is used by the runtime dynamic linker (ld-linux.so), and the one with no version is for the compile-time linker (ld). Does that match what cmake will now produce?
Comment on attachment 93016 [details] [review] Keep cmake generated shared dbus-1 library file name in sync with autotools (update 1) Review of attachment 93016 [details] [review]: ----------------------------------------------------------------- ::: cmake/dbus/CMakeLists.txt @@ +261,4 @@ > ${libdbus_SOURCES} > ${libdbus_HEADERS} > ) > +if(DBUS_LIBRARY_REVISION) In the case the macro autoversion fails to parse configure.ac. It is to avoid invalid versions. @@ +268,3 @@ > if(WIN32) > + if(DBUS_LIBRARY_REVISION) > + get_target_property(LEGACY_FILE_NAME dbus-1 LOCATION) The property LOCATION from the target dbus, which is the full path to the shared library in the build dir, will be stored into the variable LEGACY_FILE_NAME (see http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:get_target_property) and used later as target in the platform independent cmake copy file command (cmake -E copy...) @@ +281,5 @@ > target_link_libraries(dbus-1 ws2_32 advapi32 netapi32 iphlpapi) > endif(WINCE) > else(WIN32) > + if(DBUS_LIBRARY_REVISION) > + set_target_properties(dbus-1 PROPERTIES VERSION ${DBUS_LIBRARY_MAJOR}.${DBUS_LIBRARY_AGE}.${DBUS_LIBRARY_REVISION} SOVERSION ${DBUS_LIBRARY_MAJOR}) yes, cmake generates the following files libdbus-1.so.3.8.3 (real file) libdbus-1.so.3 -> libdbus-1.so.3.8.3 (symlink) libdbus-1.so -> libdbus-1.so.3 (symlink) with LT_REVISION = 123 I get libdbus-1.so.3.8.123 libdbus-1.so.3 -> libdbus-1.so.3.8.123 libdbus-1.so -> libdbus-1.so.3 The difference to autotools is, that the compile time linker file is a symlink to the one for dynamic linking instead of pointing to the real file.
(In reply to comment #15) > In the case the macro autoversion fails to parse configure.ac. It is to > avoid invalid versions. OK, makes sense. > > @@ +268,3 @@ > > if(WIN32) > > + if(DBUS_LIBRARY_REVISION) > > + get_target_property(LEGACY_FILE_NAME dbus-1 LOCATION) > > The property LOCATION from the target dbus, which is the full path to the > shared library in the build dir, will be stored into the variable > LEGACY_FILE_NAME (see > http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command: > get_target_property) and used later as target in the platform independent > cmake copy file command (cmake -E copy...) Oh, I see. So what you're doing, in pseudocode, is: # dbus-1's SUFFIX == ${CMAKE_SHARED_LIBRARY_SUFFIX} == ".dll" let LEGACY_FILE_NAME = dbus-1's LOCATION # LEGACY_FILE_NAME == "libdbus-1.dll" dbus-1's SUFFIX = "-${DBUS_LIBRARY_MAJOR}${CMAKE_SHARED_LIBRARY_SUFFIX}" # dbus-1's LOCATION is now "libdbus-1-3.dll" copy from dbus-1's LOCATION to LEGACY_FILE_NAME # i.e. copy "libdbus-1-3.dll" to "libdbus-1.dll" If that's what's going on, then yes, this patch is fine - please merge to master (but not to 1.8, unless 1.8.0 is unusable on Windows at the moment). > The difference to autotools is, that the compile time linker file is a > symlink to the one for dynamic linking instead of pointing to the real file. That seems fine, I doubt it will break anything.
Comment on attachment 93016 [details] [review] Keep cmake generated shared dbus-1 library file name in sync with autotools (update 1) committed to master
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.