Bug 1896772 - distcc fails to build: collect2: fatal error: libsystemd.so.0: error adding symbols: DSO missing from command line
Summary: distcc fails to build: collect2: fatal error: libsystemd.so.0: error adding s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: distcc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F34FTBFS PYTHON3.10 1907727
TreeView+ depends on / blocked
 
Reported: 2020-11-11 14:13 UTC by Tomáš Hrnčiar
Modified: 2021-01-13 01:58 UTC (History)
10 users (show)

Fixed In Version: distcc-3.3.5-1.fc32 distcc-3.3.5-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1907727 1907730 (view as bug list)
Environment:
Last Closed: 2021-01-13 01:35:31 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github distcc distcc issues 402 0 None closed 3.3.3 Build fails with LTO enabled 2021-02-16 17:54:44 UTC

Description Tomáš Hrnčiar 2020-11-11 14:13:49 UTC
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

Comment 1 Florian Weimer 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.)

Comment 2 Miro Hrončok 2020-11-11 14:48:49 UTC
FTR in fails in Koji as well: https://koji.fedoraproject.org/koji/taskinfo?taskID=55390541

Comment 3 Miro Hrončok 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

Comment 4 Gwyn Ciesla 2020-11-23 20:48:28 UTC
Disabled LTO temporarily, filed upstream.

Comment 5 Shawn Landden 2021-01-02 19:00:02 UTC
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.

Comment 6 Florian Weimer 2021-01-02 23:19:40 UTC
(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.

Comment 7 Shawn Landden 2021-01-03 16:05:28 UTC
Symbol has been renamed upstream

Comment 8 Fedora Update System 2021-01-04 16:01:39 UTC
FEDORA-2021-f301788bb1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f301788bb1

Comment 9 Fedora Update System 2021-01-05 01:12:58 UTC
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.

Comment 10 Fedora Update System 2021-01-05 01:58:13 UTC
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.

Comment 11 Fedora Update System 2021-01-13 01:35:31 UTC
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.

Comment 12 Fedora Update System 2021-01-13 01:58:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.