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
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.)
FTR in fails in Koji as well: https://koji.fedoraproject.org/koji/taskinfo?taskID=55390541
A scratch build with %make_build (has the -O flag): https://koji.fedoraproject.org/koji/taskinfo?taskID=55392921
Disabled LTO temporarily, filed upstream.
Distcc maintainer here. But we don't link against libsysatemd??? (And that code and it's addition to distcc predates libsystemd) Given that this is thus a break of suggested use of the code it would be nice to tag systemd too with this bug.
(In reply to Shawn Landden from comment #5) > But we don't link against libsysatemd??? (And that code and it's addition to > distcc predates libsystemd) You link against libsystemd indirectly, and you didn't rename the function when you imported it into the code base. As a result, it is ill-defined whether your copy of the function should be added to the dynamic symbol table automatically, so that it can preempt the libsystemd version. If you linked directly against libsystemd, your function would be exported. But as you don't, the situation is unclear.
Symbol has been renamed upstream
FEDORA-2021-f301788bb1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f301788bb1
FEDORA-2021-f301788bb1 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f301788bb1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f301788bb1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8bf98eaad6 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8bf98eaad6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8bf98eaad6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8bf98eaad6 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-f301788bb1 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.