11 Mar 2021

LD_LIBRARY_PATH und BRICSCAD

Wenn man Bricscad unter Linux nach /opt/bricscad installiert hat, was eine Fingerübung ist, scheiteret man u. U. an libcommands.so: cannot open shared object file

Es ist jedoch einfach, das zu lösen. Es setzt natürlich voraus, dass man sich in die Bibliothek begibt, in diesem Fall das Linux Documentation Project.

https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Sofort fällt folgendes auf, wenn man ldd verwendet:

chrissie@fehmarn /opt/bricscad $ ldd bricscad
	linux-vdso.so.1 (0x00007ffd477b3000)
	libcommands.so => not found
	libTD_DbCore.so => not found
	libTD_Ge.so => not found
	libTD_Root.so => not found
	libTD_Alloc.so => not found
	libxerces-c-3.2.so => not found
[...]

Auch Physiker fragen sich jetzt, wie das sein kann. Bringt doch Bricscad diese Bibliotheken selbst mit? Warum findet er sie nicht?

Die Lösung ist der LD_LIBRARY_PATH. Linux sucht nicht überall nach Shared Objects, schon garnicht im gegenwärtigen Verzeichnis. Viel zu hoch ist das Risiko, dass ein Attacker ein .so unterschiebt.

In welchen Verzeichnisen nach .so-Dateien gesucht wird, steht in /etc/ld.so.conf

include ld.so.conf.d/*.conf
/usr/lib32/OpenCL/vendors/amd
/usr/lib64/OpenCL/vendors/amd
[...]

Nach Änderungen in dieser Datei muss man ldconfig aufrufen. Aber man will sicher nicht seine Pfade dauerhaft verstellen.

Die Lösung kann so aussehen:

chrissie@fehmarn ~ $ cd /opt/bricscad/
chrissie@fehmarn /opt/bricscad $ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH  ./bricscad

Natürlich packt man das in ein Start-Skript, in das man gegebenenfalls noch andere Einstellungen tut, und so steht dem Brics-CADen nix im Wege.