1

I installed vanilla TeX Live 2020 on my Debian-based system, Knoppix 8.6.1, according to the manual at http://www.tug.org/texlive/quickinstall.html

Whenever I try to start xelatex I get this error-message:

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

Whenever I try to start xetex I get this error-message:

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

Question:

What am I to do to get xetex / xelatex to work ?


$ sudo apt-get install libfontconfig1

yields the following message:

libfontconfig1 is already the latest version (2.13.1-2).


$ sudo apt-get install fontconfig

yields the following message:

fontconfig is already the latest version (2.13.1-2).


Edit/Answer:

Shame on me:

I found out that the TeX Live installer assumed the wrong platform:

x86_64-linux instead of i386-linux .

The system in question, Knoppix 8.6.1, is based on Debian/stable (buster), with some packages from Debian/testing and unstable (sid) for newer graphics drivers or desktop software packages. It uses Linux kernel 5.3.5 and Xorg 7.7 (core 1.20.4).

The system in question can be used as a Live-System which can be installed on DVD/USB-stick/(micro) SD-memory-card as well.

Therefore i386-binaries are used by this system no matter if the machine in use is i386 or x86_64.

I ran this system on an x86_64-machine.

Thus the command arch yielded: x86_64
while the command dpkg --print-architecture yielded i386.

The TeX Live Installer "assumed" an x86_64-platform which I didn't realize.

If you run the installer as described in the linked manual, i.e., via the command sudo ./install-tl -gui, then on x86_64-machines installation for x86_64-platforms is pre-entered in the "Advanced" settings of the GUI no matter if Debian-i386-binaries are in use (which is possible with x86_64-machines). And you can't change this pre-entered setting in the GUI-"Advanced"-screen but only have i386-binaries installed additionally to the x86_64-binaries.

Removing the erroneous x86_64-TeX Live installation and running the installer with the -force-platform-option, i.e., via the command sudo ./install-tl -gui -force-platform i386-linux now gave me a TeX Live-installation with i386-binaries where everything works smoothly.

Sorry for the noise.

11
  • Run LD_DEBUG=libs xetex to see where XeTeX is looking for libraries. Dec 21 '20 at 9:50
  • Try also rebuilding the ld.so.cache using sudo sh -c "rm /etc/ld.so.cache; ldconfig" Dec 21 '20 at 9:54
  • Because on Debian the file is located at /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 but that is not looked up by your dynamic linker. Dec 21 '20 at 9:55
  • A last thing to try would be to list all files included in libfontconfig1 using dpkg -L libfontconfig1 to see where libfontconfig.so.1 is installed. Dec 21 '20 at 10:07
  • 1
    @HenriMenke I edited my question to add that information. Meanwhile I found the reason for the problem: Binaries for the wrong platform were automatically installed by the TeX Live installer: x86_64 instead of i386 because the machine is x86_64 while the Debian-binaries in use (a Live System on USB-stick which I am going to remaster) are i386. Dec 21 '20 at 19:36
1

While the TeX Live installer could detect this specific case (as mentioned on the mailing list, and I will discuss this with Karl), a solution could be to

dpkg --add-architecture amd64
apt-get update
apt-get install libfontconfig1:amd64

should work, too.

3
  • You are right - as long as you focus only on the x86_64-machine which was in use by me the day when my installing-attempts took place. The scenario described by me focuses on a Live System runable from USB-Stick/(micro) SD-card/DVD (after remastering) which is intended to work both on i386-platforms and on x86_64-platforms. Installing TeX Live x86_64-linux binaries and making xetex work by additionally installing libfontconfig1:amd64 would lead to TeX Live not working when running the Live System in question on i386-machines. Dec 23 '20 at 11:10
  • That is true, but for these very specific cases the --force-platform is here. I don't think we can and want to try to detect all combinations (next is arm64 running on amd64? Or qemu runs, ...).
    – norbert
    Dec 24 '20 at 3:21
  • That's why in the mailing list I wrote that probably it is sufficient to mention in the short installation-tutorials that there are edge scenarios where you are on your own with making sure that binaries for the correct platform are installed by applying the -force-platform-option. I also think that people who play around with such specific scenarios as mine should know on their own what they need to pay attention to. Shame in me that I did not see it myself_before_asking my question. Nonetheless I will not delete the question in case s.b. else stumbles over similar problems. Dec 24 '20 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.