community/busybox (static) builds fine with musl:

LINK busybox_unstripped
Trying libraries: crypt m resolv
Library crypt is not needed, excluding it
Library m is not needed, excluding it
Library resolv is not needed, excluding it
Final link with: <none>

As a general rule, Arch does not provide static libraries per policy, because per policy we expect things to be built dynamically. This bug should be automatically closed as invalid, however, I will give you one chance to change your approach. Instead of attempting to explain how static libraries would enable building things statically (do you *really* think we don't know this???), try to explain why we should *care*.

Why is this specific library *so* important that it should be an exception to the policy?

Thank you for the quick response.

Let me explain the current state of libxcrypt as I see it:
1. Initially libcrypt was part of glibc, but there is a discussion about excluding it from glibc and replacing it with separate libxglibc project: https://sourceware.org/legacy-ml/libc-alpha/2017-08/msg01257.html

2. glibc provides static libraries, so I suppose there is an exception for it:
$ pacman -Ql glibc | grep "\.a"
glibc /usr/lib/libBrokenLocale.a
glibc /usr/lib/libanl.a
glibc /usr/lib/libc.a
glibc /usr/lib/libc_nonshared.a
glibc /usr/lib/libdl.a
glibc /usr/lib/libg.a
glibc /usr/lib/libm-2.32.a
glibc /usr/lib/libm.a
glibc /usr/lib/libmcheck.a
glibc /usr/lib/libmvec.a
glibc /usr/lib/libpthread.a
glibc /usr/lib/libresolv.a
glibc /usr/lib/librt.a
glibc /usr/lib/libutil.a
glibc /usr/share/locale/locale.alias

3. Right now there are two versions of dynamic libcrypt.so, one from glibc /usr/lib/libcrypt.so.1, that is supposed to be deprecated, and second from libxcrypt: /usr/lib/libcrypt.so.2, but there is no static version of this library anywhere.

4. I suppose that if there was an exception to have static libs for glibc it is reasonable to have static libraries for libcrypt replacement(libxcrypt) to preserve compatibility. There is a TODO about it https://www.archlinux.org/todo/libxcrypt-rebuild/ but there is no discussion about static lib here.


I have (maybe incorrect) impression from you comment that I violate some policy by opening this bug, if so could you explain more details about it. I am not going to insist of adding static libs if it is strongly discouraged.

glibc is an exception because you need it to build static binaries for any reason. Same goes for libstdc++ (and more) from gcc. You need this basically per default in order to make use of gcc -static.

We have gotten bug reports asking for static binaries in random userland packages before. They don't typically have good justification... largely because they don't have much use for building standalone static applications without an extensive system of static libraries which we don't provide. Still, it's possible there is a good reason.

Mainly, I would like to see conversation about reasons. It's typically just *assumed* that this should be provided, simply because the user requested it.

"Initially part of glibc but split out to achieve faster development" is a lot better than most rationales I've heard. How common is it to link libxcrypt into an application by assuming it's part of the base system (not something to build as a dependency)?

For context, it's not just libc -- e.g. we provide libz.a too.

As 'man 5 crypt' says: "The hashing methods implemented by crypt(3) are designed only to process user passphrases for storage and authentication; they are not suitable for use as general-purpose cryptographic hashes."

It looks like this type of functionality required by applications that works with user passwords databases (/etc/shadow) and it it pretty basic system functionality. Static libxcrypt library is useful for compiling base system apps for embedded systems or small vm/container images. Musl is an option as you mention before, but glibc with static linking is a reasonable choice too.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.