[dbus] dbus-daemon and dbus-launch are runtime executables and should be provided in both release and debug versions #37625
Assignees
Labels
category:port-feature
The issue is with a library, which is requesting new capabilities that didn’t exist
Comments
tsondergaard
added
the
category:port-feature
|
I've made a PR to update the documentation: microsoft/vcpkg-docs#292 |
tsondergaard
added a commit
to tsondergaard/vcpkg
that referenced
this issue
Mar 26, 2024
dbus-daemon, dbus-launch and the other executables in the dbus port are integral components of the D-Bus system. libdbus-1 is of no utility in itself without dbus-daemon. A case could be made that libdbus-1 in Vcpkg could be used on Linux against the distro-provided dbus-daemon, but this is not true on Windows and other platforms where the dbus package is also available (and usefully so). Therefore these executables must be treated as first-class artifacts in the vcpkg port that can be installed along with shared libraries to a prefix by consuming applications. The release version of the dbus-* executables are available in the tools folder, but that leaves a hole for dynamically linked debug builds. These cannot install the dbus-* executables from the tools folder as they are release binaries that are not (necessarily) compatible with the installed libdbus-1.so/dll and other shared library dependencies. To properly support debug builds with dynamic linking the debug variant of these executables must also be preserved. They cannot be moved to tools/<port>/debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib]. Instead all dbus-* executables are left in the bin and bin/debug layout. Fixes microsoft#37625
tsondergaard
added a commit
to tsondergaard/vcpkg
that referenced
this issue
Mar 26, 2024
dbus-daemon, dbus-launch and the other executables in the dbus port are integral components of the D-Bus system. libdbus-1 is of no utility in itself without dbus-daemon. A case could be made that libdbus-1 in Vcpkg could be used on Linux against the distro-provided dbus-daemon, but this is not true on Windows and other platforms where the dbus package is also available (and usefully so). Therefore these executables must be treated as first-class artifacts in the vcpkg port that can be installed along with shared libraries to a prefix by consuming applications. The release version of the dbus-* executables are available in the tools folder, but that leaves a hole for dynamically linked debug builds. These cannot install the dbus-* executables from the tools folder as they are release binaries that are not (necessarily) compatible with the installed libdbus-1.so/dll and other shared library dependencies. To properly support debug builds with dynamic linking the debug variant of these executables must also be preserved. They cannot be moved to tools/<port>/debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib]. Instead all dbus-* executables are left in the bin and bin/debug layout. Fixes microsoft#37625
7 tasks
tsondergaard
added a commit
to tsondergaard/vcpkg
that referenced
this issue
Mar 27, 2024
dbus-daemon, dbus-launch and the other executables in the dbus port are integral components of the D-Bus system. libdbus-1 is of no utility in itself without dbus-daemon. A case could be made that libdbus-1 in Vcpkg could be used on Linux against the distro-provided dbus-daemon, but this is not true on Windows and other platforms where the dbus package is also available (and usefully so). Therefore these executables must be treated as first-class artifacts in the vcpkg port that can be installed along with shared libraries to a prefix by consuming applications. The release version of the dbus-* executables are available in the tools folder, but that leaves a hole for dynamically linked debug builds. These cannot install the dbus-* executables from the tools folder as they are release binaries that are not (necessarily) compatible with the installed libdbus-1.so/dll and other shared library dependencies. To properly support debug builds with dynamic linking the debug variant of these executables must also be preserved. Fixes microsoft#37625
JavierMatosD
pushed a commit
that referenced
this issue
Apr 22, 2024
dbus-daemon, dbus-launch and the other executables in the dbus port are integral components of the D-Bus system. libdbus-1 is of no utility in itself without dbus-daemon. A case could be made that libdbus-1 in Vcpkg could be used on Linux against the distro-provided dbus-daemon, but this is not true on Windows and other platforms where the dbus package is also available (and usefully so). Therefore these executables must be treated as first-class artifacts in the vcpkg port that can be installed along with shared libraries to a prefix by consuming applications. The release version of the dbus-* executables are available in the tools folder, but that leaves a hole for dynamically linked debug builds. These cannot install the dbus-* executables from the tools folder as they are release binaries that are not (necessarily) compatible with the installed libdbus-1.so/dll and other shared library dependencies. To properly support debug builds with dynamic linking the debug variant of these executables must also be preserved. They cannot be moved to tools/<port>/debug as that change of directory layout is not compatible with the RUNPATH in the executables [$ORIGIN:$ORIGIN/../../lib]. Instead all dbus-* executables are left in the bin and bin/debug layout. Fixes #37625 - [x] Changes comply with the [maintainer guide](https://github.com/microsoft/vcpkg-docs/blob/main/vcpkg/contributing/maintainer-guide.md). - [x] SHA512s are updated for each updated download. - [x] The "supports" clause reflects platforms that may be fixed by this new version. - [x] Any fixed [CI baseline](https://github.com/microsoft/vcpkg/blob/master/scripts/ci.baseline.txt) entries are removed from that file. - [x] Any patches that are no longer applied are deleted from the port's directory. - [x] The version database is fixed by rerunning `./vcpkg x-add-version --all` and committing the result. - [x] Only one version is added to each modified port's versions file. Co-authored-by: Jon <v-zhli17@microsoft.com>
This was referenced Jun 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
dbus-daemon and dbus-launch are only installed in release versions in
${VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET}/tools/dbus. This matches the recommendations in installation-tree-layout#layout-tools, but the recommendations should be updated to depend on whether the executables are needed at runtime. Tools that applications will be using at runtime should be installed in both release and debug versions.I need dbus-daemon and dbus-launch to work both from their location in vcpkg_installed/ and when copied to an install prefix together with other dependencies and my own software and I need this to work for both release and debug builds that use dynamic linking. My install prefix keeps both libraries and binaries in the same folder on Windows and on Linux my project uses the typical bin/ and lib/ folder. The requirements for this to work is that I have both the release and debug versions of the executables and on linux I would very much like the RUNPATH to include $ORIGIN/../lib, although I can patch that with
patchelfwhen I install the executables to my CMAKE_INSTALL_PREFIX.Proposed solution
Update the dbus port to also install debug versions of all tools, but at least dbus-daemon and dbus-launch.
Describe alternatives you've considered
If the software needs to be able to be able to run from an install prefix then the only alternatives I can think of is to use a system provided version of dbus-launch and dbus-daemon. This is not great and also does not work on all platforms.
Additional context
No response
The text was updated successfully, but these errors were encountered: