Summary: | fails to compile due to a hardcoded "-static" LDFLAG | ||
---|---|---|---|
Product: | Wayland | Reporter: | Vicente Olivert Riera <vincent.riera> |
Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | peter.hutterer |
Version: | 1.5.0 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | 82785 | ||
Bug Blocks: | |||
Attachments: | libinput-0001-fix-ldflags.patch |
Description
Vicente Olivert Riera
2014-08-07 11:55:46 UTC
I cannot reproduce this issue here. Both libevdev and libinput have "log_msg" functions indeed, but none are exported and I don't get this clash. What compiler version are you using and do you have any other configuration? Created attachment 104489 [details] [review] libinput-0001-fix-ldflags.patch (In reply to comment #1) > I cannot reproduce this issue here. Both libevdev and libinput have > "log_msg" functions indeed, but none are exported and I don't get this > clash. What compiler version are you using and do you have any other > configuration? Here you have the information about the toolchain. glibc-2.19 binutils-2.24 gcc-4.9.1 $ /buildroot/output/host/usr/bin/i586-buildroot-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/buildroot/output/host/usr/bin/i586-buildroot-linux-gnu-gcc COLLECT_LTO_WRAPPER=/buildroot/output/host/usr/libexec/gcc/i586-buildroot-linux-gnu/4.9.1/lto-wrapper Target: i586-buildroot-linux-gnu Configured with: ./configure --prefix=/buildroot/output/host/usr --sysconfdir=/buildroot/output/host/etc --enable-static --target=i586-buildroot-linux-gnu --with-sysroot=/buildroot/output/host/usr/i586-buildroot-linux-gnu/sysroot --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --with-gmp=/buildroot/output/host/usr --with-mpfr=/buildroot/output/host/usr --enable-target-optspace --disable-libquadmath --enable-tls --disable-libmudflap --enable-threads --with-mpc=/buildroot/output/host/usr --without-isl --without-cloog --disable-decimal-float --with-arch=i586 --with-tune=i586 --with-pkgversion='Buildroot 2014.08-rc1-01197-ge3bb4ac' --with-bugurl=http://bugs.buildroot.net/ --enable-languages=c,c++ --with-build-time-tools=/buildroot/output/host/usr/i586-buildroot-linux-gnu/bin --enable-shared --disable-libgomp Thread model: posix gcc version 4.9.1 (Buildroot 2014.08-rc1-01197-ge3bb4ac) I have attached a patch that fixes the problem. Could you please review it and see if it's ok to apply it upstream? The thing is that the tools are built statically deliberately to simplify debugging, so not sure I just want to apply them without understanding the reason for why it fails. Otherwise we could add a switch to configure that disables the tools or builds them as non-statics. (In reply to comment #3) > Otherwise we could add a switch to configure that > disables the tools or builds them as non-statics. Sounds sensible to me. what I'm wondering: your linker line links statically against libevdev.a which is where the problem comes from. did you use --disable-shared on libevdev or something? Update on this, this is actually a problem with static libraries in general. The libevdev static library leaks the symbols log_msg and log_priority, libinput leaks even more. I have yet to find a way to avoid that, any ideas are welcome. While searching for a solution I found something else though: we can replace -static with -no-install which prevents libtool from generating wrappers for the tools. And that was the only reason for using -static anyway. http://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode http://lists.freedesktop.org/archives/wayland-devel/2014-August/016599.html http://lists.freedesktop.org/archives/wayland-devel/2014-August/016600.html commit ad13bac1f4f491eaf86179c3e90e4ae2764803b7 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Tue Aug 19 07:57:25 2014 +1000 Use -no-install instead of -static for local noinst linking |
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.