On 5/28/2017 10:07, Carsten Mattner wrote:
On Sun, May 28, 2017 at 1:25 PM, John Marino <[email protected]> wrote:

I hit some snags due to my unfamiliarity with glibc (namely it's
inability to static link due to dynamic link requirements with NSS,
libdl, etc) but have that resolved now I think. It also took some
time to fix some ports to build on linux.

musl libc is available on many Linux distros and there are at least
two distros (void and alpine) where it's the only or optional system
libc.

A ports tree ala pkgsrc that works on Linux and DragonflyBSD sounds
like a great value proposition and bootstrapping musl as a
prerequisite for Ravenports on Linux systems where it's not available
is a simple enough build task that I'd certainly appreciate a musl
based Ravenports. That would make life easier when building stuff
for use on both a glibc and musl Linux distro from one buildhost.

If you like the idea, please consider it in addition or better (less
maintenance work) as a replacement for glibc compatibility.


Well, the problem with musl is that now all glibc-based libraries (libc, libm, pthread, etc) have to become a BUILDRUN-DEPENDS for most ports. Right now ravenports provides everything except libc, libm, libpthread, libutil, and a couple of others. If I went the musl route, these would both have to be provided and conditionally added as deps for linux.

pros: even more compatible across linux systems, dropping even glibc ABI requirement
cons: a lot of extra work, might need extra patches for pkg(8)

so using glibc covers many/most major systems. supporting musl-based systems might be contract work, or at least something maybe somebody else would have to champion, at least for now.

for example, I'd rather spend the time bootstrapping solaris. I'd get more bang for the effort IMO.

Anyway, ftigeot gave me the idea about musl and I looked into it, but with the extra cost and the fact some ports aren't buildable yet with musl and that glibc is already pretty compatible with systems, I didn't look into it further.

John

Reply via email to