src/xdetect_linux.c:167: warning: ISO C forbids an empty translation unit [-Wpedantic] 167 | #endif /* __linux__ */ | x86_64-pc-linux-gnu-gcc -o spacenavd src/cfgfile.o src/client.o src/dev.o src/dev_serial.o src/dev_usb.o src/dev_usb_darwin.o src/dev_usb_linux.o src/dummy_usb.o src/event.o src/hotplug_darwin.o src/hotplug_linux.o src/kbemu.o src/logger.o src/magellan/smag.o src/magellan/smag_comm.o src/magellan/smag_detect.o src/magellan/smag_event.o src/proto_unix.o src/proto_x11.o src/serial/sball.o src/serial/sballserial.o src/spnavd.o src/spnavd_win32.o src/xdetect_freebsd.o src/xdetect_linux.o -L/usr/local/lib -Wl,-O1 -Wl,--as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: src/client.o:(.bss+0x20): multiple definition of `cfg'; src/cfgfile.o:(.bss+0x20): first defined here /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: src/client.o:(.bss+0x0): multiple definition of `verbose'; src/cfgfile.o:(.bss+0x0): first defined here ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd-20200205-101527 ------------------------------------------------------------------- Please see the tracker bug for details. gcc-config -l: [1] x86_64-pc-linux-gnu-9.2.0 * llvm: 9.0.1 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.6 [3] python3.7 (fallback) [4] python2.7 (fallback) [5] pypy3 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-1.41.0 * ghc: The Glorious Glasgow Haskell Compilation System, version 8.0.2 repository: ==> /var/db/repos/gentoo/metadata/timestamp.chk <== Fri, 07 Feb 2020 17:27:09 +0000 emerge -qpvO app-misc/spacenavd [ebuild N ] app-misc/spacenavd-0.7 USE="-X"
there is still a similar issue at unstable amd64 tinderbox image 17.1_systemd-20200205-101527 (see bug 707734)
Created attachment 612578 [details] emerge-info.txt
Created attachment 612580 [details] app-misc:spacenavd-0.7:20200207-182611.log
Created attachment 612582 [details] emerge-history.txt
Created attachment 612584 [details] environment
Created attachment 612586 [details] etc.portage.tbz2
Created attachment 612588 [details] temp.tbz2
I have trouble understanding the actual issue here. Can you help me understand what is causing the link error?
(In reply to Sebastian Pipping from comment #8) > I have trouble understanding the actual issue here. Can you help me > understand what is causing the link error? The trigger is CFLAGS=-fno-common. gcc-10 will have it by default and app-misc/spacenavd will stop compiling. https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common has a trivial example how source code with multiple definition can trigger link failures. Or did I misunderstand the question?
The repo is from Fri, 07 Feb 2020 17:27:09 +0000 and the issue still exists, so I do think, that the fix in bug 707732 did not fixed it, or?
(In reply to Toralf Förster from comment #10) > The repo is from Fri, 07 Feb 2020 17:27:09 +0000 and the issue still exists, > so I do think, that the fix in bug 707732 did not fixed it, or? Oh, I see there was one attempt to fix it once by adding -fcommon in https://bugs.gentoo.org/706966. Unfortunately that is not a correct fix as user's CFLAGS with -fno-common will override it: > x86_64-pc-linux-gnu-gcc -pedantic -Wall -fno-strict-aliasing -fcommon -I./src -I/usr/local/include -fno-common -c src/cfgfile.c -o src/cfgfile.o For fix to work -fcommon has to go after users' flags in upstream build system.
(In reply to Sergei Trofimovich from comment #11) > For fix to work -fcommon has to go after users' flags in upstream build > system. Makes perfect sense — thanks for the explanation! I'm unsure if upstream should be bothered about it or if we should just filter out -fno-common in the ebuild. What do you think?
(In reply to Sebastian Pipping from comment #12) > (In reply to Sergei Trofimovich from comment #11) > > For fix to work -fcommon has to go after users' flags in upstream build > > system. > > Makes perfect sense — thanks for the explanation! > > I'm unsure if upstream should be bothered about it or if we should just > filter out -fno-common in the ebuild. What do you think? Filtering out should work. My minor worry is that some other gcc flags might enable -fno-common in future, like -std=c<something>. Adding 'append-flags -fcommon' to the ebuild might be more robust to counter possible effect of users' flags.
(In reply to Sergei Trofimovich from comment #13) > Adding 'append-flags -fcommon' to the ebuild might be more robust to counter > possible effect of users' flags. Great idea, adding it just now
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6b3d60e88ce863e4c5bd26ef81c8a9e9fc4d3d0 commit a6b3d60e88ce863e4c5bd26ef81c8a9e9fc4d3d0 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2020-02-09 13:58:23 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2020-02-09 13:59:13 +0000 app-misc/spacenavd: Enforce -fcommon Closes: https://bugs.gentoo.org/708648 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-2.3.84, Repoman-2.3.20 app-misc/spacenavd/spacenavd-0.6.ebuild | 3 ++- app-misc/spacenavd/spacenavd-0.7.1.ebuild | 3 ++- app-misc/spacenavd/spacenavd-0.7.ebuild | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-)
