4 ms·

> Either way, super cool. What's the likelihood that this ends up getting upstreamed? High: <https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3Aawilfo

> Either way, super cool. What's the likelihood that this ends up getting upstreamed? High: <https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3Aawilfox https://github.com/systemd/systemd/pulls?q=is%3Apr+author%3A...>.

blueflow 2y ago
Did Lennart change his mind? https://lists.freedesktop.org/archives/systemd-devel/2014-October/023869.html https://lists.freedesktop.org/archives/systemd-devel/2014-Oc...
- kokada 2y ago
  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 https://github.com/systemd/systemd/issues/10130 [2]: https://github.com/systemd/systemd/pull/34066 https://github.com/systemd/systemd/pull/34066
  - NewJazz 2y ago
    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 https://github.com/Stantheman/gcompat
    - awilfox 2y ago
      FWIW, that is an unofficial mirror repo and very old. gcompat lives at https://git.adelielinux.org/adelie/gcompat https://git.adelielinux.org/adelie/gcompat.
      - NewJazz 2y ago
        Cursed github monopolizing bing seo for open source projects.
    - kokada 2y ago
      > 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).
bhaney 2y ago
Less than a day later and everything in this list is already merged. Congrats! Do those PRs represent everything necessary to compile systemd against musl, or are there more PRs coming to finish the job?

blueflow 2y ago

Did Lennart change his mind? https://lists.freedesktop.org/archives/systemd-devel/2014-October/023869.html https://lists.freedesktop.org/archives/systemd-devel/2014-Oc...

kokada 2y ago
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 https://github.com/systemd/systemd/issues/10130 [2]: https://github.com/systemd/systemd/pull/34066 https://github.com/systemd/systemd/pull/34066
- NewJazz 2y ago
  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 https://github.com/Stantheman/gcompat
  - awilfox 2y ago
    FWIW, that is an unofficial mirror repo and very old. gcompat lives at https://git.adelielinux.org/adelie/gcompat https://git.adelielinux.org/adelie/gcompat.
    - NewJazz 2y ago
      Cursed github monopolizing bing seo for open source projects.
  - kokada 2y ago
    > 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).

bhaney 2y ago

Less than a day later and everything in this list is already merged. Congrats! Do those PRs represent everything necessary to compile systemd against musl, or are there more PRs coming to finish the job?