-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
build(linux): fix build packages with systemd services and udev #4304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@ReenigneArcher Started this PR to discuss furter. Docker works differently with systemd (it doesn't work unless...) but it should work with the variable query that Sunshine does. I will look into it. |
Install the dev packages of systemd and udev to unsure pkg-config can work with them.
cae4d3f to
a100ccb
Compare
…compilers Fixes dynamic linking errors in runtime
Fixes dynamic linking errors (runtime) on bare debian based distros.
|
|
@ReenigneArcher I've fixed the debian issue but came across some more issues. See updated op. |
ReenigneArcher
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. There's a lot going on in this and probably should be broken up in multiple.
For starters I have moved the new dependencies to #4319 and added you as a co-author.
I'm not a huge fan of the ci argument. I like the idea of it, but it doesn't work in reality due to the large variation across linux distors. For example, I would love to have docs enabled for all ci builds, but it's just not super feasible due to different versions of doxygen that come with each distro.
More investigation might be needed on the libicu dependency. I think that's a dependency of boost actually?
I like the static link of libgcc. Maybe even for all builds (LizardByte/roadmap#17)
|
I've created PR #4321 to fix the ubuntu-22 build. I do agree that most of it should be static linked. When looking into Besides that all other distros have this included in their base except for Debian (docker). The desktop versions of Debian all have this package installed so these should have no problems. I think the current solution is still the best (add it to package dependencies) so we can ensure it's there for at least the Debian based builds. Concerning the |
|
For libicu, is there a way to detect which version to use? We can also put it into the else section of this block, since I believe it only applies when we static link boost. if(NOT BOOST_USE_STATIC)
set(CPACK_DEBIAN_PACKAGE_DEPENDS "\
${CPACK_DEBIAN_PACKAGE_DEPENDS}, \
libboost-filesystem${Boost_VERSION}, \
libboost-locale${Boost_VERSION}, \
libboost-log${Boost_VERSION}, \
libboost-program-options${Boost_VERSION}")
set(CPACK_RPM_PACKAGE_REQUIRES "\
${CPACK_RPM_PACKAGE_REQUIRES}, \
boost-filesystem >= ${Boost_VERSION}, \
boost-locale >= ${Boost_VERSION}, \
boost-log >= ${Boost_VERSION}, \
boost-program-options >= ${Boost_VERSION}")
endif() |
|
I think I found the issue with libicu. Sunshine/cmake/packaging/linux.cmake Lines 96 to 97 in f52891d
Is this still nessecary? I only found an issue with the file package not installed. Turning this back on and adding file to the debian package list fixes all dependency issues. Just like in the COPR build it would automatically add all shared dependencies, including libicu.
Anyway if create PR #4323 with this build setup. Alternative: find_package(ICU COMPONENTS uc data i18n REQUIRED)
# ICU does not provide a minor / major version variable.
string(REGEX MATCH "^[0-9]+" ICU_VERSION_MAJOR ${ICU_VERSION})
# Debian-based distros have libicu versioned in the name.
set(CPACK_DEBIAN_PACKAGE_DEPENDS "\
${CPACK_DEBIAN_PACKAGE_DEPENDS}, \
libicu${ICU_VERSION_MAJOR}")
# Fedora based distros provide a general package
set(CPACK_RPM_PACKAGE_REQUIRES "\
${CPACK_RPM_PACKAGE_REQUIRES}, \
libicu") |
|
I've created the last PR #4325 for Fedora builds. I personally could never build sunshine properly on my own Fedora (docker) but with some changes implemented to the build script taken from the rpm spec I managed to make it work in docker. Closing this because I think we got just about everything done. |



Description
Issues
I've found the following issues while testing the build system:
Builds do not fail anymore when systemd or udev is not found. Adding
if(UDEV_FOUND)andif(SYSTEMD_FOUND)to:Sunshine/cmake/packaging/linux.cmake
Lines 22 to 34 in c4e5a69
will make the build silently fails if something changes to the build environment and thus will not install the associating files. I believe this change was made to allow builds on other init systems.
The newly added test that uses udevadm would silently not run when udev is missing when it should be there.
Some of the docker images that build the packages are failing on install or at runtime.
Goals
Changes
Added a flag in Cmake that sets SUNSHINE_CI. This can be used to check if the build is running in the Sunshine ci. Other possibilities could be to set something like SUNSHINE_NO_SYSTEMD or pass the init system. This is now used to fail the build if systemd/udev/udevadm is not found. I've als implemented it into the build script (--ci) and added it to the COPR build.
Added the missing packages for the Debian build. It now need *-dev packages to allow pkg-config to query it.
This project uses recent c++ syntax that requires an up-to-date compiler. Ubuntu-22 does not provide a recent enough compiler. This is added with a ppa:
Sunshine/scripts/linux_build.sh
Lines 262 to 266 in c4e5a69
libstdc++library. If the user tries to run sunshine without updating their system with this ppa, it will give a runtime link error. So I tested a bit and the solution I could come up with is to static link this lib when the compiler is < 14 (56cd373).Some of the debian-based builds also had a runtime error for missing the package
libicu. This lib is versioning itself within its name... which is :(. This a unicode lib, I believe, so I would expect it to be there on almost all systems. To be sure I've added the debian-base distro versions (libicu76 | libicu74 | libicu70) to the deb package dependencies (e1286f6).This fixed all the build / run issues with docker and the ci.
Notes
As a bonus I've added an extra info step to the docker builds. This prints all the relevant information about the package to debug faster.
Let me know what you think. Also I'm not sure about the --ci flag naming (maybe be more specific with naming it SYSTEMD something).
Issues Fixed or Closed
Fixes #4243
Roadmap Issues
Type of Change
Checklist
AI Usage