Porting systemd to musl Libc-powered Linux

Re:Porting systemd to musl Libc-powered Linux by kokada on Thursday September 05, 2024 @08:28AM (#41455967)

I don't think Lennart changed his opinion, if you look further in this thread[1] Lenart wasn't ever against musl per se, it is more like "we use non-POSIX features from glibc that we found useful, and we are not going to reinvent them, so either convince musl to implement those features or carry patches fixing the issues". That I kind concur with him, instead of workaround missing functions it may be better to just write a compatibility library that complements musl with the missing functions. This way, any program that needs those functions could just import this library if they're compiling in a non-glibc system.

I am seeing that lots of the fixes proposed by the author are things like "missing import because glibc exposes some symbols by mistake and musl does not". And this is definitely the kind of fix that upstream would accept[2].

[1]: https://github.com/systemd/systemd/issues/10130

[2]: https://github.com/systemd/systemd/pull/34066

[ Parent | on HN ]

Re:Porting systemd to musl Libc-powered Linux by NewJazz on Thursday September 05, 2024 @02:46PM (#41459401)

it may be better to just write a compatibility library that complements musl with the missing functions

It exists. See gcompat.

https://github.com/Stantheman/gcompat

[ Parent | on HN ]

Re:Porting systemd to musl Libc-powered Linux by awilfox on Thursday September 05, 2024 @07:47PM (#41461429)

FWIW, that is an unofficial mirror repo and very old. gcompat lives at https://git.adelielinux.org/adelie/gcompat.

[ Parent | on HN ]

Re:Porting systemd to musl Libc-powered Linux by NewJazz on Thursday September 05, 2024 @08:29PM (#41461679)

Cursed github monopolizing bing seo for open source projects.

[ Parent | on HN ]

Re:Porting systemd to musl Libc-powered Linux by kokada on Friday September 06, 2024 @05:28AM (#41464457)

> This library is designed to be used for binaries that are already compiled against glibc. It does not contain any headers, and cannot be used to build software that requires glibc. It is instead recommended that any software that requires glibc APIs be modified to become more portable.

This is exactly the opposite that I was talking about. What I was talking is a library that expose glibc compatible headers to compile software that uses Glibc-isms with minor or zero modifications, but this instead is a compatibility layer for binaries and doesn't expose headers (probably for proprietary software that can't be recompiled).

[ Parent | on HN ]