cargo test: Linking open62541 fails

[uklotzde]

  = note: /usr/bin/ld: cannot find -lopen62541: No such file or directory
          collect2: error: ld returned 1 exit status

error: could not compile `open62541` (lib test) due to previous error
warning: build failed, waiting for other jobs to finish...

Expectation

The corresponding version of open62541 used by open62541-sys should be linked statically instead of dynamically.

[sgoll]

Wo tritt das bei dir auf? Lokal auf dem Entwicklungsrechner?

[uklotzde]

Wo tritt das bei dir auf? Lokal auf dem Entwicklungsrechner?

Ja. Da die C-Lib als submodule eingebunden wird, hätte ich hier eigentlich statisches Linking erwartet.

[sgoll]

Das hätte ich auch erwartet. Ich habe open62541 auch nicht als globale Library installiert und sowohl auf dem MacBook als auch auf meinem Linux-Rechner wird statisch gelinkt. Seltsam.

Ich mache rustc-link-lib in build.rs in HMIProject/open62541-sys mal etwas expliziter.

[uklotzde]

Gleiches Problem tritt bereits in open62541-sys auf.

[uklotzde]

Lange her. Ich müsste aber irgendwo noch was rumliegen haben zum Vergleichen :sweat_smile:

[uklotzde]

Ok, gelöst. PR folgt.

[sgoll]

Tritt das Problem mit https://github.com/HMIProject/open62541-sys/commit/ccbf7879d61c8c7e770663079a80741848dd9ef6 immer noch auf?

[uklotzde]

Besser aber leider noch nicht ganz:

cargo test
    Updating git repository `https://github.com/HMIProject/open62541-sys.git`
   Compiling open62541-sys v1.3.9 (https://github.com/HMIProject/open62541-sys.git?branch=main#ccbf7879)
   Compiling open62541 v0.1.0 (/home/uk/slowtec/repos/hmi-project/open62541)
error: could not find native static library `open62541`, perhaps an -L flag is missing?

error: could not compile `open62541-sys` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...

[sgoll]

@uklotzde Kannst du eine Reproduktion machen, z.B. in einem Docker-Image? Ich kriege den Fehler auf meinem MacBook leider nicht nachgestellt, und in der GitHub-CI-Umgebung tritt er auch nicht auf?

[sgoll]

Okay, ich habe zumindest eine Reproduktion: https://github.com/HMIProject/open62541-sys/actions/runs/7210945670/job/19645219429#step:5:12

[uklotzde]

Ich habe einen Verdacht:

Die Library landet nicht in lib sondern per Default in lib64.

[sgoll]

Das würde dann die expliziten Pfadangaben aus #1 wieder interessant machen.

[sgoll]

Die explizite Angabe von lib allein (statt ggf. lib64) hat noch keine Besserung gebracht: https://github.com/HMIProject/open62541-sys/actions/runs/7211038607/job/19645531111#step:5:12

[sgoll]

Aber an sich ist das dynamische Linking in open62541-sys selbst doch noch in Ordnung, oder? Cargo weiß ja, wo die (shared) Bibliothek liegt. Nur am Ende, wenn alles zusammengebaut wird, kommt eine statische Binary raus, also nur der allerletzte Link-Schritt baut die (shared) Bibliothek mit dem Rest der Anwendung zu einer einzeln lauffähigen Binary. Diese hat dann keine externen Abhängigkeiten mehr.

Also war das Problem vielleicht tatsächlich nur der falsche Pfad lib64? Kannst du mit dem Stand von https://github.com/HMIProject/open62541-sys/commit/a0bd7ec7c65b3575de03561ba4f1dd1562a05127 bei dir noch einmal testen?

[uklotzde]

Mir fliegen hier jetzt auch jede Menge undefined reference s um die Ohren.

[sgoll]

D.h. deine Änderung aus #3 hilft nicht?

[uklotzde]

Nein, behebt nur den ersten Linker Fehler. Jetzt scheitert der Linker beim Resolve der Symbole.

[sgoll]

@uklotzde Kannst du eine Reproduktion machen, z.B. in einem Docker-Image? Ich kriege den Fehler auf meinem MacBook leider nicht nachgestellt, und in der GitHub-CI-Umgebung tritt er auch nicht auf?

🔝 ?

[sgoll]

Hier ein rudimentäres Dockerfile, mit dem ich gerade Tests für verschiedene Plattformen mache (der COPY-Pfad . meint dabei das lokal ausgecheckte open62541-sys-Repository):

FROM rust
RUN apt update
RUN apt install -y cmake clang
COPY .git /source/.git
RUN git clone /source /target
WORKDIR /target
RUN git submodule init
RUN git submodule update
RUN cargo test

Und dann mit docker build -t test --platform linux/x86_64 . laufen lassen (und natürlich ggf. die Plattform ersetzen, wenn lokal qemu/binfmt installiert ist).

[uklotzde]

Nach diversen Cleanups von Build-Verzeichnissen und Wechsel von meinem lokalen Pfad zurück auf den main-Branch vom GitHub-Repo läuft der Linker jetzt ohne Fehler durch.