GNU-only components that make it impossible to build in Musl or any other libC

[xplshn]

• Due to the fact that libxo uses cdefs.h
• fts_open is not provided by musl-fts nor Musl itself
• rpmatch should not be used outside of glibc internal code, apparently

Check this excellent Gentoo wiki page: https://wiki.gentoo.org/wiki/Musl_porting_notes

See Juniper/libxo#94:

/usr/include/sys/cdefs.h:4:2: warning: usage of non-standard #include <sys/cdefs.h> is deprecated [-W#warnings]
    4 | #warning usage of non-standard #include <sys/cdefs.h> is deprecated

Developers like to wrongly include sys/cdefs.h to use the _*_DECLS macros. This is a bug and the correct way to do it is to use:

#ifdef __cplusplus
extern "C" {
#endif

Instead of:

#ifdef __cplusplus
}
#endif

And instead of _END_DECLS
https://wiki.gentoo.org/wiki/Musl_porting_notes

This causes problems on other OSes, like Illumos based ones, such as OpenIndiana, and also when */Linux based distros that use Musl, uClibc, Bionic libc (Android libc) or anything other than glibc try to compile libxo

Is chimera really "GNU-free" if it still uses header files and functionality provided only by the glibc? ...

[nekopsykose]

Due to the fact that libxo uses cdefs.h

https://github.com/chimera-linux/cports/blob/ffc52fa2ee50fae630f59d7802bd2a4890cc6e0c/main/libxo/patches/portability.patch

feel free to upstream it

fts_open is not provided by musl-fts nor Musl itself

wrong: https://github.com/chimera-linux/musl-fts/blob/9fd7d89c72689e5dd0d9ccedde1d9f2b4bec87a4/fts.c#L128

rpmatch should not be used outside of glibc internal code, apparently

that's what https://github.com/chimera-linux/musl-rpmatch is for. do you have a reference for 'should not be used outside glibc internals'?

b64; VGhlcmUgYXJlIG9ubHkgdHdvIHNleGVzLgo=

very mature of you.

[xplshn]

that's what https://github.com/chimera-linux/musl-rpmatch is for. do you have a reference for 'should not be used outside glibc internals'?

I linked the Gentoo Musl Porting guide. It doesn't say anything about musl-rpmatch, but still, the rpmatch function is not defined in the SUSV3/4, neither in any of the POSIX specifications, it was present in Solaris, thus various OSes packaged it as a standalone library to ease porting, then later followed Glibc, which has it since version 2.19 when using _DEFAULT_SOURCE or prior if using _SVID_SOURCE.

It is not present in any of these OSes: macOS, NetBSD, OpenBSD, Minix, HP-UX, IRIX, Cygwin, mingw, MSVC, nor Android (because Android uses the Bionic libC)

You can still use it with a standalone port of the library tho, but why use a ported Glibc component?

And under the section of cdefs.h it says 'should not be used outside glibc internals'.

fts_open is not provided by musl-fts nor Musl itself

wrong: https://github.com/chimera-linux/musl-fts/blob/9fd7d89c72689e5dd0d9ccedde1d9f2b4bec87a4/fts.c#L128

Seems I was mistaken with this

I will do some surgery to get this working on Alpine

[q66]

Due to the fact that libxo uses cdefs.h

https://github.com/chimera-linux/cports/blob/ffc52fa2ee50fae630f59d7802bd2a4890cc6e0c/main/libxo/patches/portability.patch

feel free to upstream it

ftr that has been done for ages Juniper/libxo#82

fts_open is not provided by musl-fts nor Musl itself

wrong: https://github.com/chimera-linux/musl-fts/blob/9fd7d89c72689e5dd0d9ccedde1d9f2b4bec87a4/fts.c#L128

rpmatch should not be used outside of glibc internal code, apparently

that's what https://github.com/chimera-linux/musl-rpmatch is for. do you have a reference for 'should not be used outside glibc internals'?

freebsd libc has rpmatch and therefore the tools use it; musl-rpmatch is a from-scratch implementation as far as i know, it could be rolled into the builtin libcompat but i don't see much point

b64; VGhlcmUgYXJlIG9ubHkgdHdvIHNleGVzLgo=

very mature of you.

[xplshn]

ftr that has been done for ages Juniper/libxo#82

Okay, I see you updated libxo minutes ago and deleted a patch and now there is only the bmake compat one.

Thanks for clarifying everything