Wie kriege ich die Fehlermeldung "java: symbol lookup error: ..." weg?

[Mick P. F.]

Hallo Leute,

zunächst zur Laufzeit- und Entwicklungsumgebung:

• Ubuntu 22.04 64 bit
• Oracle Java 1.8.0_341

ich möchte die Backup-Software Areca-7.5 zum Laufen kriegen, die ich als Quell-Code vorliegen habe, und die zum größten Teil in Java geschrieben ist. Für die Benutzung der System-Bibliothek "ACL" wurde ein kleiner Teil dieser Software in C geschrieben (JNI).
Die Bibliothek "libacl" ist installiert, die Dateien liegen in "/usr/lib/x86_64-linux-gnu".
Beim Start der Software mit
j

java -Xmx1024m -Xms64m -cp :/home/mick/Projects/areca:/home/mick/Projects/areca/config:/home/mick/Projects/areca/translations:/home/mick/Projects/areca/lib/areca.jar:/home/mick/Projects/areca/lib/mail.jar:/home/mick/Projects/areca/lib/activation.jar:/home/mick/Projects/areca/lib/commons-net-1.4.1.jar:/home/mick/Projects/areca/lib/jakarta-oro-2.0.8.jar:/home/mick/Projects/areca/lib/jsch.jar:/home/mick/Projects/areca/lib/org.eclipse.core.commands_3.2.0.I20060605-1400.jar:/home/mick/Projects/areca/lib/org.eclipse.equinox.common_3.2.0.v20060603.jar:/home/mick/Projects/areca/lib/org.eclipse.jface_3.2.0.I20060605-1400.jar:/home/mick/Projects/areca/lib/org.eclipse.swt.gtk.linux.x86_64-4.2.jar:/home/mick/Projects/areca/lib/commons-codec-1.4.jar -Duser.dir=/home/mick/Projects/areca -Djava.library.path=/home/mick/Projects/areca/lib:/usr/lib/x86_64-linux-gnu:/usr/lib:/lib/x86_64-linux-gnu:/lib -Djava.system.class.loader=com.application.areca.impl.tools.ArecaClassLoader com.application.areca.launcher.gui.Launcher

bekomme ich die Fehlermeldung

java: symbol lookup error: /home/mick/Projects/areca/lib/libarecafs.so: undefined symbol: acl_get_file

Wie man in den Aufruf-Parametern von Java sieht, ist die Umgebungsvariable "java.library.path" korrekt gesetzt.
Der Java-Code

        System.loadLibrary("arecafs");
        System.loadLibrary("acl");

wird ausgeführt, das habe ich überprüft.

Wie kann ich diesen Fehler beseitigen?

Mit Dank im voraus
Michael

 

[KonradN]

Da solltest Du Dich ggf. an die Macher von dem Tool wenden.

Evtl. ist https://sourceforge.net/p/areca/bugs/ ein guter Anlaufpunkt.

Was man da z.B. teilweise findet sind Hinweise, dass man das 32 Bit Java statt einem 64 Bit Java verwenden soll oder so. Aber ich kenne das Tool nicht.

Was aber wichtig ist: Das ist ein Tool Problem und kein Java Problem.

 

[Robert Zenz]

Was man da z.B. teilweise findet sind Hinweise, dass man das 32 Bit Java statt einem 64 Bit Java verwenden soll oder so. Aber ich kenne das Tool nicht.

Das wird die Antwort sein vermute ich. Eventuell sind die nativen Teile alle als 32-Bit kompiliert und damit zaehlt deine 64-Bit Bibliothek natuerlich nicht.

Auszerdem gibt es den Import

#include <acl/libacl.h>

in der JNI Bruecke, aber laut man-page sollte es eher sys/acl.h sein, wenn ich das richtig sehe. Koennte gut sein dass sich da einiges am System veraendert hat und Acera da einfach nicht mehr am neuesten Stand ist um es "einfach so" auf aktuellen Linux-System laufen zu lassen. Du wirst da eventuell etwas mehr Zeit investieren muessen um das auf Stand zu bringen.

 

[Mick P. F.]

Ich habe alle Ursachen außerhalb der Java-Laufzeitumgebung (Symbols in der Datei "/usr/lib//usr/lib/x86_64-linux-gnu/libacl.so", 64-bit etc,) überprüft, es ist alles vorhanden. Der Code von areca ist in diesem Punkt einfach...
Im Forum von areca war ich längst, es bringt mich nicht weiter. In Google habe ich auch schon alles abgesucht und alle dort gefundenen Lösungen durchprobiert.
Im Forum von areca kann man zwar Anfragen erstellen, man kriegt aber schon seit Jahren keine Antworten. Die Software wird auch nicht weiter entwickelt bzw. nicht mehr bug-fixed, obwohl sie recht gut ist.

Mag sein, dass das Problem nicht in der Java-Laufzeitumgebung liegt, sondern in areca selbst, aber wo?

Ich habe gehofft, ich würde hier ein Paar Vorschläge zur Lösung des Problems zu bekommen...

 

[Mick P. F.]

ich habe eine reine 64 bit Umgebung von Linux, darauf achte ich sehr penibel.
In der JNI-"Brücke" steht

#include <sys/acl.h>

Ich bin gerne bereit, mehr Zeit zu investieren, wenn ich wüßte, mit was.
Meine Java-Kenntnisse sind relativ bescheiden, auf dem Stand von etwa vor 20 Jahren... Dafür sind meine C- und Linux-Kenntnisse sehr gut!

 

[KonradN]

Evtl. ist es ein Versuch wert, alles vom Source neu zu übersetzen. dann wird ja gegen die aktuellen Libraries gelinkt. Änderungen in den Abhängigkeiten führen dann zu Problemen bei der Übersetzung und da könnte man dann ansetzen.

Ansonsten bliebe nur der Versuch, ob man da alte Versionen der Abhängigkeiten nutzen kann - das wird aber nicht leicht. Und da geht es dann mehr um C/C++ als um Java, denn man muss sich die Libraries ansehen, die da vom JNI Code verwendet werden.

Ob sich das bei einer 7 Jahre alten Software überhaupt rentiert, ist dann auch eine Frage, die man sich stellen sollte. Wenn es um das zurück spielen von Backups gehen sollte, dann wäre eine Überlegung, auf einem System eine alte Ubuntu Version (ggf. in 32 Bit) zu installieren.

 

[Mick P. F.]

Ich benutze den Quell-Code, sprich, ich habe es komplett neu kompiliert! Ich musste das ANT-File "build.xml" sowie die Datei "areca_run.sh" anpassen, damit ich es kompileren konnte und damit es überhaupt läuft. Das hat mich zwar sehr viel weiter gebracht, aber nur bis zu diesem Punkt.
Ja, für mich lohnt es sich, Areca zum Laufen zu kriegen, sonst würde ich nicht so viel Zeit dafür investieren. Ich möchte den Befehl "tar" nicht mehr benutzen, aber letztendlich eine tar-Datei erzeugen. Cloud-Lösungen und andere Backup-Lösungen für Linux halte ich für meinen Fall entweder für "weit über das Ziel hinausgeschossen", viel zu umständlich (siehe bacula) oder sie sind Versager (sprich Laufzeitfehler etc.).

 

[KonradN]

Ok, was es sein könnte: Die libacl fehlt. Ursache kann die Reihenfolge der Argumente sein:

        <!-- Compile the JNI code -->
        <exec dir="${root}/jni" executable="gcc">
            <arg value="-c"/>
            <arg value="-fPIC"/>
            <arg value="-lacl"/>
            <arg value="com_myJava_file_metadata_posix_jni_wrapper_FileAccessWrapper.c"/>
            <arg value="-o"/>
            <arg value="com_myJava_file_metadata_posix_jni_wrapper_FileAccessWrapper.o"/>
        </exec>

Setze den -lacl Parameter mal an das Ende:

        <!-- Compile the JNI code -->
        <exec dir="${root}/jni" executable="gcc">
            <arg value="-c"/>
            <arg value="-fPIC"/>
            <arg value="com_myJava_file_metadata_posix_jni_wrapper_FileAccessWrapper.c"/>
            <arg value="-o"/>
            <arg value="com_myJava_file_metadata_posix_jni_wrapper_FileAccessWrapper.o"/>
            <arg value="-lacl"/>
        </exec>

(Evtl. auch mal vor das -o setzen. Ich bin da nicht so tief drin beim gcc.)

 

[Mick P. F.]

Hingegen bin ich in diesen Sache sehr tief drin... Entschuldige, wenn ich es etwas undiplomatisch ausdrücke!
Beim Kompileren zum Objekt vom Type "*.o" muss es überhaupt nicht angegeben werden, es ist überflüssig. Erst beim zweiten Befehl zum erzeugen der DLL ist es erforderlich. Aber auch da habe ich schon alles ausprobiert bzw. überprüft.
Die JNI-Brücke wird aufgerufen, aber der erste Aufruf der acl-Bibliothek innerhalb dieser "Brücke" bringt diesen Fehler, obwohl das Symbol "acl_get_file" in der Bibliothek vorhanden ist. Leider gibt es keine Möglichkeit, die acl-Bibliothek statisch einzubinden, da man ja eine DLL erzeugt.

 

[Mick P. F.]

Ha, ich hab's !!!
Konrad, dein Tipp hat mich auf eine Idee gebracht: Es sind tatsächlich die Kommandzeilen für gcc, allerdings ganz geringfügig anders gelagert, als du vermutet hast!

Danke für die Anregungen!

 

[Mick P. F.]

Wie kann ich diese Diskussion schliessen?

 

[mrBrown]

Wie kann ich diese Diskussion schliessen?

Gar nicht - einfach deine Lösung am Ende posten, dann sieht auch jeder, dass es gelöst ist 🙂