Einbinden der libbass.so

[Garfield]

Ich habe die aktuelle bass24-linux.zip herunter geladen und wollte zum Test einen kleinen Player schreiben. Dazu habe ich die bass.pas in den Projektordner kopiert und die libbass.so in den Unterordner "lib" sowie den Ordner "lib" in den Projekteinstellungen unter Compilereinstellungen, Pfade, Bibliotheken (-FI) eingetragen. Dann habe ich die bass nur in die uses der umain.pas eingetragen und wollte sehen was passiert: Das Projekt wird kompiliert und die Ausführung mit der Fehlermeldung "Execution stopped with exit-code 127 ($007F)" abgebrochen. Das heißt, dass etwas nicht gefunden wurde.

Dann habe ich die libbass.so entfernt und der Kompiliervorgang wird mit der Nachricht "Warning: linker: /usr/bin/ld: -lbass kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden" abgebrochen.

Die Bibliothek wurde gefunden, aber der Fehler 127 sagt das Gegenteil. Muss ich die libbass.so jetzt zwingend nach "/usr/lib" verschieben oder gibt es noch eine Einstellung um das zu vermeiden?

[Mathias]

Ich habe die aktuelle bass24-linux.zip herunter geladen und wollte zum Test einen kleinen Player schreiben.

Ich wollte dem gerade nachgehen, Normalerweise kann man das -l Problem so lösen.

Code: Alles auswählen

sudo apt install libxxx-dev

Da habe ich gesehen, das die ein kommerzielles Programm ist. Um solches mache ich einen riessen Bogen.
Brauchst du zwingend bass, oder reicht dir auch eine andere Player-lib ?
Sonst könnte ich die gstreamer empfehlen.

[theo]

Geht es denn, mit der Lib in /usr/lib oder /usr/lib64?
S.a. LD_LIBRARY_PATH

[Garfield]

@Matthias

Eine libbass-dev gibt es nicht. In dem Downloadarchiv ist nur die libbass.so. In den Beispielen, welche ich gefunden hatte, lag die libbass.so im Projektordner. Die Bass ist kommerziell aber "BASS is free for non-commercial use."

Zwingend ist die bass nicht. Ich hatte sie nur vor Jahren unter Windows benutzt.

@theo

Wenn ich die libbass.so nach /usr/lib kopiere funktioniert es. Das wollte ich eigentlich vermeiden.

Dann sehe ich mir mal gstreamer an.

[theo]

Wenn ich die libbass.so nach /usr/lib kopiere funktioniert es. Das wollte ich eigentlich vermeiden.

Warum?
Wie angedeutet, kann man ein Startscript machen und dort den Pfad mit LD_LIBRARY_PATH setzen, wenn man unbedingt will.
https://www.geeksforgeeks.org/linux-uni ... -in-linux/
https://www.hpc.dtu.dk/?page_id=1180

[Garfield]

Warum?

Falls ich die Quelltexte mal weitergebe, soll es sofort funktionieren.

[Garfield]

https://www.geeksforgeeks.org/linux-uni ... -in-linux/

Ich habe das jetzt ausprobiert. Leider hat es nicht funktioniert. Das heißt, die Variable wurde richtig gesetzt, aber Lazarus bringt weiter den Fehler 127.

[theo]

Ich habe das jetzt ausprobiert. Leider hat es nicht funktioniert. Das heißt, die Variable wurde richtig gesetzt, aber Lazarus bringt weiter den Fehler 127.

Während der Entwicklung würde ich das sowieso nicht machen, bei der Weitergabe sollte es aber funktionieren.

[Warf]

Unter Linux ist es normalerweise nicht so das man Bibliotheken direkt mit der Anwendung mitliefert. Das ist ein Windows Ding. Die Idee bei Linux ist das man die Bibliotheken durch die Zentrale Paketverwaltung installiert. Wenn das keine Option ist gibt es den LD_LIBRARY_PATH oder containerization. Je nachdem was dir lieber ist.

Am einfachsten installierst du dir aber einfach die libbass über den Paketmanager und wenn du den Source Code weiter gibst schreibst du einfach libbass als dependency hinzu.

Das ist vor allem auch relevant da im gegensatz zu Windows Linux (bzw. genauer die LibC) nicht ABI Stabil ist. Deine Libbass die auf deinem Linux problemlos funktioniert, kann auf einem anderen Linux system gar nicht erst starten, weil es gegen eine andere LibC ABI bindet.
Damit verschiebt sich die Anforderung für die Dependencies vom Entwickler an den Nutzer. Ein Linux Nutzer muss selbst wissen wie er an die richtige Dependency für sein system kommt. Ein Arch Nutzer kann keine Dependencies für einen Debian Nutzer bereitstellen weils sehr oft einfach von den versionen und ABIs nicht passt.
Daher hat man normalerweise 3 Möglichkeiten:
1. Dependency angeben und der Nutzer mus schauen wie er dran kommt
2. Containerization
3. Bibliothek sources mitliefern und dann als Teil des Buildprozesses deiner Anwendung mitbauen

Für das dritte muss die Anwendung natürlich open source sein.

[Garfield]

Anscheinend habe ich noch einiges zu lernen. Es ist das zweite Mal, dass ich mit Bibliotheken unter Linux zu tun habe. Die erste war die libSane, für welche ein Developerpaket gab. Bei der libBass gibt es nur die libbass.so. LD_LIBRATY_PATH hat leider nicht funktioniert.

Die dritte Option geht nicht, da die Bass kommerziell und nicht offen ist. Die zweite kenne ich nicht und die erste sollte kein Problem sein.

Apt kann mit der libbass.so nichts anfangen. Mal sehen, ob ich da noch etwas herausfinden kann.

[Garfield]

Zu LD_LIBRARY_PATH. Ich hatte es so gemacht:

Code: Alles auswählen

nano ~/.bashrc

Am Ende der Datei habe ich eingefügt:

Code: Alles auswählen

export LD_LIBRARY_PATH=/home/fran/lib

Dann kam

Code: Alles auswählen

source ~/.bashrc

und mit

Code: Alles auswählen

echo $LD_LIBRARY_PATH

wurde der richtige Pfad wird angezeigt.

Code: Alles auswählen

/home/fran/lib

Die Datei ist

Code: Alles auswählen

/home/fran/lib/libbass.so

Wenn ich den Pfad in den Projekteinstellungen - Compilereinstellungen - Pfade unter Bibliotheken (-FI) eintrage, wird die Datei gefunden. Aber der Fehler 127 kommt trotzdem.

[Garfield]

Im Projektordner lagen ein paar *.res. Die hatte ich gelöscht. Jetzt habe ich eine link1689943.res.

Code: Alles auswählen

SEARCH_DIR("/usr/lib/x86_64-linux-gnu/")
SEARCH_DIR("/lib64/")
SEARCH_DIR("/lib/")
SEARCH_DIR("/usr/lib64/")
SEARCH_DIR("/usr/lib/")
SEARCH_DIR("/home/fran/lib/")
SEARCH_DIR("/usr/lib/gcc/x86_64-linux-gnu/13/")
SEARCH_DIR("./")
...

Da ist auch der Pfad aus der LD_LIBRARY_PATH drin.

[Warf]

Bei LD_LIBRARY_PATH musst du nicht die .so angeben sondern den Suchordner. Das ganze muss dann gesetzt sein durch den Startprozess. Am einfachsten ist du machst dir in deinem Programm die folgende Aufteilung:

Code: Alles auswählen

<ProjektDir>/runApplication.sh
<ProjektDir>/bin/Application
<ProjektDir>/lib/libXYZ.so
...

Mit einer runApplication.sh die das folgende macht:

Code: Alles auswählen

#!/bin/bash
# Holt den Pfad wo die runApplication.sh liegt (https://stackoverflow.com/questions/59895/how-do-i-get-the-directory-where-a-bash-script-is-located-from-within-the-script)
SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )

# Setzen des LD_LIBRARY_PATH sodass Bibliotheken aus lib gefunden werden
export LD_LIBRARY_PATH=$SCRIPT_DIR/lib:$LD_LIBRARY_PATH

# Optional: Setze das Script verzeichnis als Arbeitsverzeichnis
# cd "$SCRIPT_DIR"

# bin/Application ausführen und dabei alle Argumente übergeben
exec "$SCRIPT_DIR"/bin/Application $@

Solang dur über die runApplication.sh startest sollte es dann Funktionieren

[Mathias]

Was noch eine Alternative wäre, da libbass.so sowieso nicht bei ubuntu dabei ist, die lib dynamisch mit der unit dynlibs einbinden.
Dann kannst du deine *.so mit deinem Project mitliefern, und der Anwender muss sich dann nciht darum kümmern, das irgendwie die libbass auf sein System kommt.

[Garfield]

So wie es aussieht, wird die libbass.so gefunden. Denn wenn sie fehlt oder umbenannt wird, kommt die Nachricht, dass sie nicht gefunden wurde. Wenn ich alle Funktionen in der bass.pas auskommentiere, gibt es beim Kompilieren keinen Fehler. Sowie eine Funktion drin ist, kommt die 127. Als wenn die Einsprungpunkte nicht gefunden werden. Nehme ich eine andere libbass.so, bekomme ich die Nachricht, dass diese inkompatibel ist.

@Warf

Vielen herzlichen Dank. In Lazarus kommt der Error 127. Im Double Commander passiert gar nichts, wenn das Programm ausgeführt werden soll. Und mit Deinem Script startet das Programm. Jetzt muss ich nur noch den Code einfügen.

Nachtrag: Habe eine Demo genommen und ausprobiert. Lazarus bricht mit 127 ab und mit dem Script läuft es.

@Matthias

An dynamische Einbindung hatte ich auch schon gedacht. Unter Windows hatte ich das gemacht. Die unit dynlibs sagt mir noch nichts. Muss ich mal gucken.