libdbus needs to be statically linked on Linux |
||
Issue descriptionWe recently switched to using the debian Stretch sysroot on CrOs: https://chromium.googlesource.com/chromium/src/+/4dfcf263240a67065f940ca458cddca1d882959a Stretch has an updated libdbus where all symbols are retroactively versioned with LIBDBUS_1_3. This causes a warning on systems that have the older library where the symbols were unversioned: ./browser_tests: /lib/x86_64-linux-gnu/libdbus-1.so.3: no version information available (required by ./browser_tests) https://chromium-swarm.appspot.com/task?id=39b4d15362a63610&refresh=10&show_raw=1 While it appears to be harmless (so far), I don't like this spam when running every binary. The solution is to statically link libdbus. This should be relatively safe as libdbus has no dependencies (besides libc and libpthread). The libdbus static library on my system is 600Kb, but I don't expect we're using all of these symbols. So with LTO, I expect the binary to increase in size by some amount < 600Kb. This will allow us to switch to the Stretch sysroot on desktop Linux too.
,
Nov 10 2017
Hm.. Actually I think statically linking libdbus is impossible due to different configurations. I tried building dbus with the default options, straight from the freedesktop git repo, and it had these defines: -DDBUS_MACHINE_UUID_FILE=\""/usr/local/var/lib/dbus/machine-id"\" -DDBUS_RUNSTATEDIR=\""/usr/local/var/run"\" -DDBUS_SESSION_CONFIG_FILE=\""/usr/local/share/dbus-1/session.conf"\" -DDBUS_SYSTEM_CONFIG_FILE=\""/usr/local/share/dbus-1/system.conf"\" But building the libdbus from my Debian distro has different paths: -DDBUS_MACHINE_UUID_FILE=\""/var/lib/dbus/machine-id"\" -DDBUS_SESSION_CONFIG_FILE=\""/usr/share/dbus-1/session.conf"\" -DDBUS_SYSTEM_CONFIG_FILE=\""/usr/share/dbus-1/system.conf"\" I tried running chrome with a freshly built vanilla dbus and it seemed to work, but there were errors printed out about wrong paths. I think the switch is not as safe as I initially thought, so we should probably try to find a different solution. |
||
►
Sign in to add a comment |
||
Comment 1 by thomasanderson@chromium.org
, Nov 9 2017