Re: libfetch / libnbcompat fails to build on Linux

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

On Fri, 10 May 2024 at 17:56:15 +0200, Benny Siegert wrote:
> On a freshly upgraded Fedora Linux system, building libfetch fails 
> within libnbcompat:
>
> cc -DHAVE_NBCOMPAT_H=1 
> -I/home/bsiegert/pkgsrc/net/libfetch/work/libnbcompat -I. -I.  -O2 
> -DHAVE_CONFIG_H -c lchflags.c
>
> lchflags.c: In function 'lchflags':
>
> lchflags.c:49:17: error: implicit declaration of function 'chflags'; 
> did you mean 'lchflags'? [-Wimplicit-function-declaration]
>
>   49 |         return (chflags(path, flags));
>      |                 ^~~~~~~
>      |                 lchflags
> *** [lchflags.o] Error code 1
>
> I don't think there is a chflags function on Linux. Any ideas why it is 
> trying to use this unconditionally?

libnbcompat includes an implementation of lchflags that in turn
unconditionally expects chflags to be available. That evidently isn't
safe. Without the (now default on) -Wimplicit-function-declaration it
will indeed build and link against glibc, but what glibc provides seems
to be a stub implying it shouldn't be used (that isn't new in Fedora
40, from what I see looking at 39).

Debian's solution for this was simply to remove lchflags from their
packaged version of libnbcompat.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066593
They note it doesn't work properly anyway, which begs the question what
it was added for in the first place. Someone would need to check if it
really is used anywhere in packages that depend on libnbcompat.

A hack is of course to do
CFLAGS.Linux+=		-Wno-implicit-function-declaration
but that isn't really correct. (I used that to get cwrappers to build.)

Better options would be to either add chflags itself to libnbcompat, or
if safe, simply remove lchflags a la Debian.

Regards,

Dave