Bug 201287

Summary:	xfsprogs 4.17 and later can't be built as static binaries anymore
Product:	File System	Reporter:	Andreas K. Hüttel (dilfridge)
Component:	XFS	Assignee:	FileSystem/XFS Default Virtual Assignee (filesystem_xfs)
Status:	RESOLVED INVALID
Severity:	normal	CC:	david, jeffm, sandeen
Priority:	P1
Hardware:	All
OS:	Linux
See Also:	https://bugs.gentoo.org/show_bug.cgi?id=666196
Kernel Version:	n/a	Subsystem:
Regression:	Yes	Bisected commit-id:

Description Andreas K. Hüttel 2018-09-29 23:03:12 UTC

In Gentoo we offer the possibility to build xfsprogs fully static, e.g. for initramdisks.

This still worked fine with 4.14. 

With 4.17 and 4.18 we however get:

../libfrog/.libs/libfrog.a(convert.o): In function `gid_from_string':
convert.c:(.text+0x984): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

and final linking fails.

See also https://bugs.gentoo.org/666196

Comment 1 Eric Sandeen 2018-09-30 00:06:26 UTC

Is there a recipe to demonstrate this failure in the upstream git tree w/o the gentoo patches or build environment?

Comment 2 Jeff Mahoney 2018-09-30 00:18:34 UTC

This isn't an xfsprogs problem at all.  It's a glibc change:

$ cat tmp.c
#define _GNU_SOURCE
#include <grp.h>
#include <stdio.h>

int
main(void)
{
	struct group *grp;

	grp = getgrnam("users");

	return grp != NULL;
}

$ cc tmp.c -static
/tmp/ccPA29iG.o: In function `main':
tmp.c:(.text+0xe): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Comment 3 Andreas K. Hüttel 2018-09-30 00:26:29 UTC

Ugh. I can't reproduce the final link failure with the unmodified release tarball. So that part is likely our problem, sorry for the noise.

[We sed LLDFLAGS += -all-static into the Makefiles.]

Comment 4 Andreas K. Hüttel 2018-09-30 00:28:15 UTC

(In reply to Andreas K. Hüttel from comment #3)
> Ugh. I can't reproduce the final link failure with the unmodified release
> tarball. So that part is likely our problem, sorry for the noise.
> 
> [We sed LLDFLAGS += -all-static into the Makefiles.]

(More precisely, simplified from the "ebuild":

sed -i -e "1iLLDFLAGS += -all-static" include/builddefs.in
find -name Makefile -exec sed -i -r -e '/^LLDFLAGS [+]?= -static(-libtool-libs)?$/d' {} +

)

Comment 5 Andreas K. Hüttel 2018-09-30 00:32:59 UTC

With above two commands and the configure call below I can reproduce the problem with the otherwise unmodified 4.18 tarball.
 
(Feel free to close anyway if you see fit.)

./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --docdir=/usr/share/doc/xfsprogs-4.18.0 --htmldir=/usr/share/doc/xfsprogs-4.18.0/html --libdir=/usr/lib64 --disable-lto --enable-blkid --with-crond-dir=/etc/cron.d --with-systemd-unit-dir=/lib/systemd/system --disable-libicu --enable-gettext --disable-readline --disable-editline --enable-static

Comment 6 Dave Chinner 2018-09-30 03:00:54 UTC

So the distro build env modifies the xfsprogs build flags to add something upstream doesn't support, right? And that distro hack doesn't work anymore, yes?

If so, this is a distro package build problem, not an upstream issue. If the distro package maintainers want the upstream source tree to support static builds as the distro requires, then please send patches to support this functionality directly out of the upstream tree to linux-xfs@vger.kernel.org.

-Dave.

Comment 7 Eric Sandeen 2018-09-30 05:18:50 UTC

(FWIW I think the issue here is that getgrnam() wanders into different libnss* libraries, which glibc dlopens (?) and so it's pretty much impossible to statically link.)