biber: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

Question

biber: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

Tpaefawzen opened this issue 3 years ago · 10 comments

When I do latexmk -pdflua main.ltx, the following error appeared:

Rc files read:
  latexmkrc
Latexmk: This is Latexmk, John Collins, 20 November 2021, version: 4.76.
Latexmk: applying rule 'biber main'...
Rule 'biber main': The following rules & subrules became out-of-date:
      'biber main'
------------
Run number 1 of rule 'biber main'
------------
------------
Running 'biber  "main.bcf"'
------------
biber: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
Latexmk: Errors, so I did not complete making targets
Collected error summary (may duplicate other messages):
  biber main: Could not open biber log file for 'main'
Latexmk: Use the -f option to force complete processing,
 unless error was exceeding maximum runs, or warnings treated as errors.

My environment

I am running on Linux version 5.16.9-arch1-1 (linux@archlinux) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.38) #1 SMP PREEMPT Fri, 11 Feb 2022 22:42:06 +0000. I am managing almost every package on pacman, but not for TeX and LaTeX packages.
I am managing CTAN packages with tlmgr.

Info of biber on my environment

$ tlmgr info biber
package:     biber
category:    Package
shortdesc:   A BibTeX replacement for users of BibLaTeX
longdesc:    Biber is a BibTeX replacement for users of BibLaTeX. Biber supports full UTF-8, can (re)-encode input and output, supports highly configurable sorting, dynamic bibliography sets and many other features. The CTAN distribution offers a compressed tar archive of the sources, etc., together with "binary" distributions for a variety of platforms. Note: on SourceForge biber is formally named "biblatex-biber", to distinguish it from an earlier (now apparently moribund) project called "biber".
installed:   Yes
revision:    61867
sizes:       src: 1181k, doc: 269k, bin: 29325k
relocatable: No
cat-version: 2.17
cat-license: artistic2
cat-topics:  biblio
cat-related: bibtex crosstex biblatex
cat-contact-repository: https://github.com/plk/biber
cat-contact-home: http://biblatex-biber.sourceforge.net/
cat-contact-bugs: https://github.com/plk/biber/issues
collection:  collection-bibtexextra

`libcrypto*`

$ pacman -Qo /usr/lib/libcrypt*
/usr/lib/libcrypto.so is owned by openssl 1.1.1.m-1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.m-1
/usr/lib/libcryptsetup.so is owned by cryptsetup 2.4.3-2
/usr/lib/libcryptsetup.so.12 is owned by cryptsetup 2.4.3-2
/usr/lib/libcryptsetup.so.12.7.0 is owned by cryptsetup 2.4.3-2
/usr/lib/libcrypt.so is owned by libxcrypt 4.4.28-1
/usr/lib/libcrypt.so.2 is owned by libxcrypt 4.4.28-1
/usr/lib/libcrypt.so.2.0.0 is owned by libxcrypt 4.4.28-1

Files

main.ltx

% ...
\usepackage[
        sorting=none
]{biblatex}
\bibliography{main.bib}
% ...
\begin{document}
% ...
\printbibliography[title=参考文献]
\end{document}

latexmkrc

$latex='lualatex %O -synctex=1 -interaction=nonstopmode %S';
#$bibtex='upbibtex %O %B';
$bibtex='biber %O %B';
$makeindex='upmendex %O -o %D %S';
$pdf_mode=3;

Answer 1 · 2022-02-19T05:13:33.000Z

Just found this is a problem for Arch GNU/Linux-specified issue. So I am referring Missing libcrypt.so.1.

Answer 2 · 2022-02-23T05:58:20.000Z

gpg --keyserver keyserver.ubuntu.com --recv-keys 678CE3FEE430311596DB8C16F52E98007594C21D
yay -S libxcrypt-compat 
biber MyLibrary.bib

Answer 3 · 2022-03-09T20:02:36.000Z

Sorry, but I fail to see how the problem is resolved. I don't think biber should assume that libcrypt.so.1* exist once it is compiled.

Answer 4 · 2022-03-11T02:45:39.000Z

I encountered the same problem on my Arch system yesterday and have endeavored to see what I could discover from compiling the packaged executable myself and from looking at how biber is packaged in Debian. It seems to me that this is not an issue with biber itself, but rather has something to do with the version of Perl (or of some Perl modules) against which the CTAN-provided biber exe was compiled.

On stable Debian the core Perl package, currently at minor version 5.32, ultimately depends on the package libcrypt1, which seems to be equivalent to Arch's libxcrypt-compat and contains libcrypt.so.1.1.0. Arch on the other hand is on to Perl version 5.34, requiring only libxcrypt. Now I was able to get a perfectly functional exe compiling against the latest Perl on Arch (with a little unrelated tweaking of build.sh script). How exactly the Perl module dependencies installed when running Build install on the biber source with Perl 5.34 differ from those when working with Perl 5.32, I have no idea. At the very least, something appears no longer to look for libcrypt.so.1*.

What remains completely mysterious to me is why this problem should only have appeared to me in the last few days. As far as I can tell, I've never had libcrypt.so.1* on my system, yet I feel certain that I've had the CTAN biber exe working fine on my Arch system in the fairly recent past. I do most of my LaTeX writing on a different system and update the Arch system very frequently, so I don't think I'll every be able to say for sure exactly what occasioned the change, or if there even was one.

Answer 5 · 2022-03-11T02:52:58.000Z

@dave-white So it is a problem in Perl, not biber?

Answer 6 · 2022-03-11T04:54:21.000Z

@albinahlback Sorry I don't have a better answer for you, but here it is:

TL;DR: There does not appear to be any problem with Arch + perl-5.32* + biber v2.17 + the latest versions of biber's Perl module dependencies gotten via cpan. I'm left to think the problem has to do with the versions of the Perl module dependencies, but at this point the problem is beyond me.

I ran the following experiment:

Downgrade Perl on Arch to perl-5.32.1-1.
Downgrade to libxslt-1.1.33-1.
Just to be safe, obliterate the contents of site_perl and vendor_perl in /usr/bin, /usr/lib/perl5/5.34 and /usr/share/perl5.
git clone -b v2.17 https://github.com/plk/biber && cd biber.
Edit the --link's and other paths in dist/linux_x86_64/build.sh to reflect the file paths on Arch and to point to "generic" libssl.so since I don't know how to get libssl prior to major version 1. (I maintained all other version numbers.)
Follow the instructions to build the biber executable package given in the documentation.

The resulting executable (biber-linux_x86_64) did not produce any error regarding libcrypt.so.1 (and worked fine on my LaTeX projects). Consequently, I'm really at a loss to identify the root of the problem. My best guess is that it has to do with the version of some Perl module dependency downloaded by Build installdeps in Step 6 above. Without comparing my system to that on which the CTAN exe was built, I don't know how to sort out what's happening here.

Answer 7 · 2022-03-11T12:38:49.000Z

Basically, it's trial and error to get the right --link lines for a particular architecture. Running ldd on the biber.exe tells you basically where to start and you follow the chain of dependencies down with ldd until you hit generic system libraries and make sure all the non-system things have --link lines in the pp build. The issue is likely versions of some binary perl module which linked against a different or more recent version of a library and can't find it in the PAR cache on startup. This happens from time to time as OSes update some system library dependence. Can also happen when you install a binary perl module that was pre-compiled and packaged instead of being installed from source on the current system. I always install all dependencies for a platform using raw CPAN so I know what libraries they are linked against.

Answer 8 · 2023-02-28T02:23:19.000Z

Arch Linux + TeX Live 2022, used tlmgr to update to latest biblatex

When I am using biber, it throws out:

error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

After searching for the web, it seems that Perl has throw out libcrypt and use libxcrypt

https://stackoverflow.com/questions/71171446/biber-wants-to-load-libcrypt-so-1-but-it-is-missing

https://tex.stackexchange.com/questions/493231/biber-missing-libcrypt-so-1-library-on-fedora

This issue happens on 2022-10-19, Will it be solved in TeXLive 2023?

Answer 9 · 2023-02-28T08:53:14.000Z

Arch Linux + TeX Live 2022, used tlmgr to update to latest biblatex

When I am using biber, it throws out:
error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
After searching for the web, it seems that Perl has throw out libcrypt and use libxcrypt

https://stackoverflow.com/questions/71171446/biber-wants-to-load-libcrypt-so-1-but-it-is-missing

https://tex.stackexchange.com/questions/493231/biber-missing-libcrypt-so-1-library-on-fedora

This issue happens on 2022-10-19, Will it be solved in TeXLive 2023?

Are you sure that you are using biber from tlmgr? Simply do tlmgr install biber, and try running that version instead.

Answer 10 · 2023-04-24T17:19:23.000Z

Are you sure that you are using biber from tlmgr? Simply do tlmgr install biber, and try running that version instead.

Same thing for me here and yes, I'm sure.

The solution accepted at the linked StackOverflow question worked for me.