Build failures on arc and nds32 architectures

[ffontaine]

libxcrypt has been recently added to buildroot and it raises build failures with glibc on "exotic" architectures such as arc and nds32. These build failures are raised because those architectures are not defined in https://github.com/besser82/libxcrypt/blob/develop/lib/libcrypt.minver resulting in the following error:

checking minimum symbol version to use for compatibility symbols... ERROR
configure: error: libxcrypt port to arc-buildroot-linux-gnu is incomplete

or

checking minimum symbol version to use for compatibility symbols... ERROR
configure: error: libxcrypt port to nds32le-buildroot-linux-gnu is incomplete

I'm seeking advise to know how these failures should be handled. There is 3 options:

• Disable libxcrypt on those architectures in buildroot
• Disable obsolete API on those architectures in buildroot
• Update libcrypt.minver (but then what is the GLIBC version that should be used, GLIBC_2.0?)

[zackw]

I am not familiar with buildroot, but using --disable-obsolete-api is recommended whenever possible. As long as you never need to use the buildroot environment to run old binaries that were compiled outside the environment and make use of glibc's libcrypt, you shouldn't need the binary-compatible libcrypt.so.1. The "obsolete" APIs that are removed from the build by this option are insecure (due to use of the elderly DES cipher) and it's already not possible to link newly compiled programs with them. However, I am not sure whether --disable-obsolete-api actually bypasses the check for an entry in libcrypt.minver. We'd take a patch to make it do that, if it doesn't already, but I have no way to test it so I'm not going to write it myself.

It's our bug if libcrypt.minver does not contain an entry for any architecture supported by upstream glibc. This is the case for ARC (and also CSKY and RISCV-32, which you didn't mention). I will commit a patch adding those architectures to libcrypt.minver shortly.

NDS32, on the other hand, does not appear to be supported by upstream glibc, which means we can't add it to upstream libxcrypt's libcrypt.minver because we don't know what version tag to use. You will need to carry a patch for it. The procedure for adding the entry is:

• Locate the relevant libcrypt.abilist in your patched glibc that supports NDS32. It's probably named something like sysdeps/unix/sysv/linux/nds32/libcrypt.abilist, but the name of the subdirectory of .../sysv/linux may be different. The contents of this file should look something like this:

  GLIBC_2.32 crypt F
  GLIBC_2.32 crypt_r F
  

  but the number after GLIBC_ may be different.

• Add a line to the "Linux with GNU libc" block of libcrypt.minver. It should look something like this:

  GLIBC_2.32   linux.*gnu    nds32
  

  The first field must exactly match what you found in libcrypt.abilist. The second field is a regex; don't leave out the dot before the star. The third field is also a regex, and it needs to match the first field of what config.guess prints when run on your NDS32 system (this will probably be "nds32" but it might be different).

  libcrypt.minver is processed linearly, top to bottom, so you must add this line in the proper location to keep the overall "Linux with GNU libc" block sorted. See the comments at the top of the file for instructions (the paragraph starting "More specific regexes ...").

• If there wasn't already an entry for some architecture with the same "version tag" (the GLIBC_2.xx string), you must also add the version tag to the %chain lines at the bottom of libcrypt.map.in so the build scripts know how to sort it. Insert it in numeric order within the group of GLIBC_* entries.

We won't be able to merge it, but if you post a PR with your changes to libcrypt.minver and libcrypt.map.in I will be happy to check it over for you, I know these rules are tricky.

[ffontaine]

--disable-obsolete-api is working perfectly fine and it fixes the build failures. Following your feedback, I'll use it on buildroot to disable the obsolete and unsecure API for all architectures.
FYI, concerning NDS32, there is no libcrypt.abilist provided inside the toolchain.
I'm closing this issue.

[zackw]

@ffontaine Can you tell me whether your build of glibc on NDS32 produces an installed libcrypt.so.1?

[ffontaine]

Here is the result of find output/ -name libcrypt*:

output/host/opt/ext-toolchain/nds32le-linux/sysroot/lib/libcrypt-2.27.9000.so
output/host/opt/ext-toolchain/nds32le-linux/sysroot/lib/libcrypt.so.1
output/host/opt/ext-toolchain/nds32le-linux/sysroot/usr/lib/libcrypt.so
output/host/opt/ext-toolchain/nds32le-linux/sysroot/usr/lib/libcrypt.a
output/host/nds32le-buildroot-linux-gnu/sysroot/lib/libcrypt-2.27.9000.so
output/host/nds32le-buildroot-linux-gnu/sysroot/lib/libcrypt.so.1
output/host/nds32le-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.so
output/host/nds32le-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.a

[ffontaine]

It should be noted that this is an external (i.e. prebuilt) toolchain.