[musl] Musl & libxcrypt library.

[musl] Musl & libxcrypt library.

[lid gnulinux]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Hello, I hope it's still relevant with musl.
About two months ago, I built a Linux
From Scratch with musl. I mistakenly also
built libxcrypt and not knowing that libxcrypt
will replace some header files from musl.
I fortunately restore some replaced headers
back. Today I realized I still have libcrypt.so
from libxcrypt. Do I need to keep that library?
When I move it (instead of delete it) I can't
build shadow package (it complained about
missing crypt() function). Thanks.

[-- Attachment #2: Type: text/html, Size: 600 bytes --]

Re: [musl] Musl & libxcrypt library.

[Rich Felker]

On Thu, May 01, 2025 at 09:03:16PM +0700, lid gnulinux wrote:
> Hello, I hope it's still relevant with musl.
> About two months ago, I built a Linux
> >From Scratch with musl. I mistakenly also
> built libxcrypt and not knowing that libxcrypt
> will replace some header files from musl.
> I fortunately restore some replaced headers
> back. Today I realized I still have libcrypt.so
> from libxcrypt. Do I need to keep that library?
> When I move it (instead of delete it) I can't
> build shadow package (it complained about
> missing crypt() function). Thanks.

musl has a working crypt implementation and it's not intended that you
need to use libxcrypt on a musl-based system, unless you want it for
the "heavy" hashes. If you do want to use it, it's recommended that
you install the headers in a separate directory so you can select them
by putting the appropriate -I in CFLAGS, rather than clobbering the
libc header. Likewise, the library should be named libxcrypt, not
libcrypt, so it doesn't supersede or clobber the (intentionally empty;
all actual functions are in libc.{a,so}) libcrypt.a shipped with musl.
Then you can select it with the appropriate -I and -l.

Without further information I don't know what your problem building
the shadow package is, and whether it's a consequence of something
that got clobbered, some wrong detection the shadow build process is
doing, or just failure to re-run configure or whatever after fixing
the mess.

Re: [musl] Musl & libxcrypt library.

[lid gnulinux]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

Thank Rich, I thought I solved my case. Today I cleaned all libxcrypt
related stuff / deleted libcrypt.so. Shadow package and linux-pam were
built successfully. I still need to figure out suitable pam configuration.
I think we can close this discussion. Thanks.

On Sat, May 3, 2025 at 8:12 PM Rich Felker <dalias@libc.org> wrote:

> On Thu, May 01, 2025 at 09:03:16PM +0700, lid gnulinux wrote:
> > Hello, I hope it's still relevant with musl.
> > About two months ago, I built a Linux
> > >From Scratch with musl. I mistakenly also
> > built libxcrypt and not knowing that libxcrypt
> > will replace some header files from musl.
> > I fortunately restore some replaced headers
> > back. Today I realized I still have libcrypt.so
> > from libxcrypt. Do I need to keep that library?
> > When I move it (instead of delete it) I can't
> > build shadow package (it complained about
> > missing crypt() function). Thanks.
>
> musl has a working crypt implementation and it's not intended that you
> need to use libxcrypt on a musl-based system, unless you want it for
> the "heavy" hashes. If you do want to use it, it's recommended that
> you install the headers in a separate directory so you can select them
> by putting the appropriate -I in CFLAGS, rather than clobbering the
> libc header. Likewise, the library should be named libxcrypt, not
> libcrypt, so it doesn't supersede or clobber the (intentionally empty;
> all actual functions are in libc.{a,so}) libcrypt.a shipped with musl.
> Then you can select it with the appropriate -I and -l.
>
> Without further information I don't know what your problem building
> the shadow package is, and whether it's a consequence of something
> that got clobbered, some wrong detection the shadow build process is
> doing, or just failure to re-run configure or whatever after fixing
> the mess.
>

[-- Attachment #2: Type: text/html, Size: 2304 bytes --]