Mail archive

Re: [alpine-devel] libnss-winbind ABI disagrees with glibc ABI for NSS modules

From: Josiah Worcester <>
Date: Sat, 05 Nov 2016 18:25:49 +0000

On Sat, Nov 5, 2016 at 8:26 AM Timo Teras <> wrote:

> Hi,
> On Fri, 28 Oct 2016 22:25:39 +0000
> Josiah Worcester <> wrote:
> > I've been working on writing an nscd for musl systems (
> > ).
> Cool!
> > This nscd assumes the glibc ABI for NSS modules is in place.
> Unfortunately, if nss.h is not present
> > at compile time for Samba, then it uses its own version of the NSS
> > ABI (in
> >
> > ), which does not quite match.
> What does not match? The sole enum there? Is something else needed?

That's exactly what doesn't match.

> I'd like to continue supporting the glibc ABI for NSS modules, to
> > potentially let proprietary NSS modules continue to function. To do
> > this, Samba will need to have an appropriate nss.h around.
> >
> > I suppose if musl-nscd were in alpine upstream, then just depending
> > on a dev package would be appropriate. For now, I feel like the
> > appropriate thing would be to copy nss.h into the apkbuild (e.g. from
> > ), and
> > make sure Samba uses it. Think this could get done?
> Could we just patch the samba nss.h until musl-nscd-dev becomes
> available? Or does it trigger additional functionality to be built if
> nss.h exists?
> What modules of samba use this file? Is it just some nss plugin which
> has been unused so far? If yes, I'm happy to just apply a patch. But if
> it affects some other potentially in-use things, we need to consider if
> it breaks things.

This values in the enum also apply to some of libwbclient's return values.
I don't believe this is currently being used outside of samba's own tools,
though, because to my knowledge the header also isn't exported.

Aside from that, the only use is this nss plugin, which is built anyways.
As such, patching samba's values might well be the best solution.

Thanks for looking into this!

Received on Sat Nov 05 2016 - 18:25:49 UTC