Hi,

I am trying to port coreutils to musl-linux-any. While doing so, I ran
into a build failure of coreutils. On the surface, logname fails to
link due to undefined symbols that evidently should come from -lsystemd.

Looking deeper, logname uses getlogin(). This is normally provided by
the C library (at least on glibc) except when the C library implements
getlogin() as `return getenv("LOGNAME");` such as musl. coreutils does
not consider this a sane implementation and provides its own
implementation. That implementation in turn uses read_utmp from
lib/readutmp.c. That latter file can integrate with systemd and does so
when available. Therefore logname ends up using -lsystemd symbols, but
its linker invocation lacks -lsystemd.

For most other tools, -lsystemd is conveyed via READUTMP_LIB and added
via ..._LDADD where necessary. Adding READUTMP_LIB to src_logname_LDADD
might be a simple way to fix this, but that would result in logname
uselessly linking -lsystemd when built on glibc. In looking further, I
stumbled into LOGNAME_LIB, which can be non-empty for Windows builds.
Unfortunately, it is set up via a separate functions to the one deciding
on the logname implementation.

I suggest fusing those two functions into one that both sets
REPLACE_LOGNAME and LOGNAME_LIB. When logname is being replaced,
READUTMP_LIB is added to LOGNAME_LIB. LOGNAME_LIB can then be added to
src_logname_LDADD without incurring unnecessary linkage.

Please find a patch attached. This is an upstream problem that likely
affects any Linux distribution that uses coreutils with systemd on musl.
At present, this probably is PostmarkedOS only, but Alpine and others
might pick this up soon. Please forward it upstream.

Helmut

Note there was worry about redundant linking with -lsystemd
when getlogin() is not replaced, however that is mitigated
in general with the --as-needed linker option (the lib-ignore
gnulib module). Tested with:

  ./configure --with-systemd gl_cv_func_getlogin_works=no

* NEWS: Mention the Build-related fix.
Reported at https://bugs.debian.org/1129960
---
 NEWS         | 3 +++
 src/local.mk | 1 +
 2 files changed, 4 insertions(+)

diff --git a/NEWS b/NEWS
index 3edfbd502..cf9334ef0 100644
--- a/NEWS
+++ b/NEWS
@@ -142,6 +142,9 @@ GNU coreutils NEWS                                    -*- outline -*-

 ** Build-related

+  'logname' now builds, where getlogin() is replaced (e.g. with musl),
+  and systemd libs are being used, by linking the required libraries.
+
   The multi-call binary built with configure --enable-single-binary is reduced
   in size by around 10KB through the more efficient reuse of the 'test' code
   by '[', and the 'true' code by 'false'.
diff --git a/src/local.mk b/src/local.mk
index cf13f1339..6ed4ed78f 100644
--- a/src/local.mk
+++ b/src/local.mk
@@ -344,6 +344,7 @@ src_pinky_LDADD += $(READUTMP_LIB)
 src_uptime_LDADD += $(READUTMP_LIB)
 src_users_LDADD += $(READUTMP_LIB)
 src_who_LDADD += $(READUTMP_LIB)
+src_logname_LDADD += $(READUTMP_LIB)

 # for strsignal
 src_kill_LDADD += $(LIBTHREAD)

Pádraig Brady <P@draigBrady.com> writes:

Agreed regarding a lib-ignore. It makes life much easier, and I assume
any platform we really care about supports it.

I see, we replaced getlogin on musl since there it just uses [1]:

    getenv ("LOGNAME")

which is incorrect according to POSIX [2]:

    The logname utility shall write the user's login name to standard
    output. The login name shall be the string that would be returned by
    the getlogin() function defined in the System Interfaces volume of
    POSIX.1-2024.

    [...]

    The logname utility explicitly ignores the LOGNAME environment
    variable because environment changes could produce erroneous
    results.

I assume the musl developers implemented it incorrectly on purpose
because they dislike utmp/wtmp [3].

Since systemd supporting musl, at least experimentally, is relatively
new excluding it was mostly fine up until now.

Collin

[1] https://github.com/kraj/musl/blob/cec26f5164f0deede51ed36591f58fca19c10795/src/unistd/getlogin.c#L6
[2] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/logname.html
[3] https://wiki.musl-libc.org/faq.html#Q:-Why-is-the-utmp/wtmp-functionality-only-implemented-as-stubs?