Bug 74117 - Difference between cmake and autotools generated dbus shared library name
Summary: Difference between cmake and autotools generated dbus shared library name
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Havoc Pennington
QA Contact:
URL:
Whiteboard:
Keywords:
: 42357 (view as bug list)
Depends on:
Blocks: 90199
  Show dependency treegraph
 
Reported: 2014-01-27 15:05 UTC by Ralf Habacker
Modified: 2015-04-27 20:02 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Keep cmake generated shared library file name in sync with autotools for windows builds (2.83 KB, patch)
2014-01-28 15:16 UTC, Ralf Habacker
Details | Splinter Review
Keep cmake generated shared library file name in sync with autotools for windows builds (2.84 KB, patch)
2014-01-28 15:18 UTC, Ralf Habacker
Details | Splinter Review
Keep cmake generated shared library file name in sync with autotools on unix (2.09 KB, patch)
2014-01-28 15:59 UTC, Ralf Habacker
Details | Splinter Review
Keep cmake generated shared dbus-1 library file name in sync with autotools (update 1) (3.59 KB, patch)
2014-01-29 22:51 UTC, Ralf Habacker
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Habacker 2014-01-27 15:05:43 UTC
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.
Comment 1 Ralf Habacker 2014-01-28 15:16:52 UTC
Created attachment 92930 [details] [review]
Keep cmake generated shared library file name in sync with autotools for windows builds
Comment 2 Ralf Habacker 2014-01-28 15:18:42 UTC
Created attachment 92931 [details] [review]
Keep cmake generated shared library file name in sync with autotools for windows builds

minor subject fix
Comment 3 Ralf Habacker 2014-01-28 15:59:32 UTC
Created attachment 92935 [details] [review]
Keep cmake generated shared library file name in sync with autotools on unix
Comment 4 Ralf Habacker 2014-01-29 16:27:00 UTC
*** Bug 42357 has been marked as a duplicate of this bug. ***
Comment 5 Ralf Habacker 2014-01-29 16:28:35 UTC
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 6 Simon McVittie 2014-01-29 18:03:01 UTC
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 7 Simon McVittie 2014-01-29 18:07:42 UTC
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?
Comment 8 Simon McVittie 2014-01-29 18:10:50 UTC
(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 9 Ralf Habacker 2014-01-29 18:27:22 UTC
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
Comment 10 Simon McVittie 2014-01-29 19:53:50 UTC
(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.
Comment 11 Ralf Habacker 2014-01-29 22:51:19 UTC
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
Comment 12 Ralf Habacker 2014-01-29 22:58:53 UTC
(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
Comment 13 Ralf Habacker 2014-01-29 23:35:33 UTC
(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 14 Simon McVittie 2014-01-30 12:20:58 UTC
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 15 Ralf Habacker 2014-01-30 14:27:47 UTC
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.
Comment 16 Simon McVittie 2014-01-30 16:04:32 UTC
(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 17 Ralf Habacker 2014-01-30 16:20:13 UTC
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.