Bug 936927 – net-fs/autofs-5.1.9-r1 fails to compile: master.c:1632:16: error: implicit declaration of function basename [-Wimplicit-function-declaration]

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Agostino Sarubbo 2024-07-30 07:56:40 UTC]

https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: net-fs/autofs-5.1.9-r1 fails to compile.
Discovered on: amd64 (internal ref: tinderbox_musl)
System: MUSL-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#MUSL)

Info about the issue:
https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0002

[Comment 1 Agostino Sarubbo 2024-07-30 07:56:41 UTC]

Created attachment 898626 [details]
build.log

build log and emerge --info

[Comment 2 Ben Buhse 2025-02-21 01:24:38 UTC]

Created attachment 919593 [details, diff]
autofs patch

This patch should fix building on musl

[Comment 3 Fabian Groffen 2025-06-09 19:29:58 UTC]

same with net-fs/autofs-5.1.9-r2

Somehow, I feel the proposed patch in comment #2 is a bit big.

basename() returns the component following the final '/'.
If path does not contain a slash, basename() returns a copy of path.

POSIX says to include libgen.h, and that basename will not alter its input.  Also that the returned pointers should not be freed, for they may be pointers to the original input.

So, just including libgen.h should fix this thing?

[Comment 4 Fabian Groffen 2025-06-09 19:40:14 UTC]

Aherm, ok I see now why you made the change, POSIX defines basename(char *), so they can't pass const char * without a warning or disputable cast.  The other locations copy the value to solve this.

Did you attempt to bring your patch upstream, it looks sane with my renewed insights.

[Comment 5 Ben Buhse 2025-06-09 22:34:38 UTC]

I did send the patch to the autofs ML back in February and sent a ping about a month later but never heard anything back from the maintainer(s) https://lore.kernel.org/autofs/[e-mail]/T/#t