Ultimately this is the same problem as we've seen with distcc. +++ This bug was initially created as a clone of Bug #1896772 +++ Hello, I ran to another failure with collect2 while building packages in Python3.10 Copr. /usr/bin/ld: src/util.o (symbol from plugin): undefined reference to symbol 'sd_is_socket@@LIBSYSTEMD_209' /usr/bin/ld: /usr/lib64/libsystemd.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status You can find whole log for package distcc here: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01760244-distcc/builder-live.log.gz --- Additional comment from Florian Weimer on 2020-11-11 14:43:02 UTC --- Would you please add the -O flag to the make invocation? It makes it easier to attribute error messages. As far as I can tell, the linker invocation is this: gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fcommon -MD -W -Wall -Wimplicit -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wmissing-declarations -Wuninitialized -D_REENTRANT -pthread -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o distcc src/backoff.o src/climasq.o src/clinet.o src/clirpc.o src/compile.o src/cpp.o src/distcc.o src/remote.o src/ssh.o src/state.o src/strip.o src/timefile.o src/traceenv.o src/include_server_if.o src/where.o src/auth_distcc.o src/emaillog.o src/arg.o src/argutil.o src/cleanup.o src/compress.o src/trace.o src/util.o src/io.o src/exec.o src/rpc.o src/tempfile.o src/bulk.o src/help.o src/filename.o src/lock.o src/netutil.o src/pump.o src/sendfile.o src/safeguard.o src/snprintf.o src/timeval.o src/dotd.o src/hosts.o src/hostfile.o src/implicit.o src/loadfile.o lzo/minilzo.o src/zeroconf.o src/gcc-id.o src/auth_common.o -lgssapi_krb5 -liberty -lpopt -lpopt -lavahi-common -lavahi-client This looks like a package bug and a toolchain bug. src/util.c in distcc has this: 992 int sd_is_socket(int fd, int family, int type, int listening) { 993 int r; 994 995 if (family < 0) 996 return -EINVAL; 997 998 r = sd_is_socket_internal(fd, type, listening); 999 if (r <= 0) 1000 return r; 1001 1002 if (family > 0) { 1003 union sockaddr_union sockaddr = {}; 1004 socklen_t l = sizeof(sockaddr); 1005 1006 if (getsockname(fd, &sockaddr.sa, &l) < 0) 1007 return -errno; 1008 1009 if ((size_t)l < sizeof(sa_family_t)) 1010 return -EINVAL; 1011 1012 return sockaddr.sa.sa_family == family; 1013 } 1014 1015 return 1; 1016 } This function collides with the sd_is_socket function in libsystemd. Normally, the expectation is that if you link against library that exports a symbol that an application defines as well, the symbol is automatically exported to create an interposing definition. This is definitely not what you want here, though. So the LTO failure is actually a good thing because it pointed you to a real bug. The toolchain bug is the inconsistency between the LTO and non-LTO behavior. I'm not sure which behavior is more correct. The behavior that is least surprising to me would be the creation of an interposing function definition even for indirect dependencies, without reporting an error. But that needs opening and analyzing indirect dependencies in the link editor. (I suspect this interposing behavior will surprise most programmers, so what I expect is probably not a good benchmark.) --- Additional comment from Miro Hrončok on 2020-11-11 14:48:49 UTC --- FTR in fails in Koji as well: https://koji.fedoraproject.org/koji/taskinfo?taskID=55390541 --- Additional comment from Miro Hrončok on 2020-11-11 14:51:49 UTC --- A scratch build with %make_build (has the -O flag): https://koji.fedoraproject.org/koji/taskinfo?taskID=55392921 --- Additional comment from Gwyn Ciesla on 2020-11-23 20:48:28 UTC --- Disabled LTO temporarily, filed upstream.
Dear Maintainer, your package has an open Fails To Build From Source bug for Fedora 34. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. If you have already fixed this issue, please close this Bugzilla report. Following the policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks (not sooner than 2021-02-09). A week before the mass branching of Fedora 35 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 33 will be retired regardless of the status of this bug. [1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Fixed in avahi-0.8-9.fc34
Had to fix it again, someone reverted the workaround https://src.fedoraproject.org/rpms/avahi/c/2ad878bdde7bc552f0a6d9e0a98d8fd564265378 Re-added for f34-only this time