ZFX + Developia

Moin,

ich habe gerade ein nur moderat spannendes Problem mit Splatter auf Linux. Inzwischen kompilieren alle statisch gelinkten Bibliotheken durch und produzieren .a-Dateien. Die gebe ich dann im exe-erstellenden Projekt an. Die Kommandozeile sieht stark gekürzt in etwa so aus:
Sorry für die Länge, aber ich habe irgendwie das Gefühl, dass es daran liegt. Da fehlen auf jeden Fall noch externe Libs, wie z.B. FMod. Das Problem ist aber, dass das Linker nicht nur FMod-Symbole vermisst, sondern auch anscheinend wahllos Symbole anmeckert, die auf jeden Fall in den Libs vorkommen. Ich habe mir z.B. mit nm alle Symbole einer der .a-Dateien angeschaut und finde dort alle Sachen, die da sein sollten. Aber einige davon werden nicht angemeckert, andere Sachen dagegen bekomme ich mit "Undefined reference to..." um die Ohren gehauen. Das banale -lX11 z.B. wird verarbeitet, Vertipper bekomme ich mit FileNotFound vorgeworfen, aber jede X11-Funktion ist "Undefined Reference".

Und richtig seltsam wird es zwischendurch, wenn der Linker eine Funktion aus einer der mitgebauten Libs findet und linkt, aber eine statische Konstante aus derselben Klasse nicht findet. Also beispielhaft so:
Und der Linker verlinkt die Funktion Bla::TuWas() sauber und ordentlich, aber die darin verwendete Bla::Konstante findet er plötzlich nicht mehr. Spätestens an der Stelle bin ich einfach nur noch ratlos.

Hat irgendwer von euch eine Idee? Umgebung ist eine 32Bit-VM mit Ubuntu 14.10 und GCC 4.9.1 oder so.

Also ich hatte mal das Problem, dass es auf die Reihenfolge ankommt, mit der die Bibliotheken angegeben werden. Möglicherweise ist das auch dein Problem. Der Microsoft Linker kennt dieses Hindernis nicht.

Ja, der Gedanke kam mir auch. Zumindest mal die externem -lX11 und so ganz nach hinten schieben. Ich probiere aus und berichte, ob und was sich ändert.

Wenn ich alle -l-Libs ganz ans Ende stelle, kriege ich plötzlich 1400 anstatt 400 Undefined References. Und die meisten davon in boost_locale, was drei Zeilen weiter oben verlinkt wird. Tsk. Jetzt hab ich noch das fehlende -lGL drangehängt und bin auf genau eine Fehlermeldung runter, der sich über irgendeinen Segmentkonflikt beschwert. Hab mir leider die Fehlermeldung nicht kopiert, bevor ich einen Global Rebuild als Allheilmittel angeworfen hatte. Und der GCC ist leider so entsetzlich langsam, dass es noch ne Weile dauern wird, bis da neue Erkenntnisse rausfallen. Währenddessen geh ich aber zumindest schonmal FMod-Libs sammeln.

Nicht vergessen:
- nicht gcc/g++ bindet, sondern ld von den binutils
- Bibliotheken werden in der Reihenfolge verwendet wie angegeben. -lA -lB, wobei B Symbole aus A benoetigt, wird nicht gehen, nicht aufgeloeste symbole werden in den folgenden Bibliotheken gesucht, aber nicht rueckwaerts.
- Seit ld 2.22 (?) werden Bibliotheken auch nicht mehr per-default rekursiv durchsucht. Falls du nicht-statisch bindest ist u.U. folgendes hilfreich: -Wl,--no-as-needed -Wl,--copy-dt-needed-entries. (haengt davon ab wie die .so's gebaut wurden).

Jo, danach habe ich meine Libs jetzt auch umgestapelt. Ein paar Sachen fehlen immernoch, aber es geht voran.

Vielleicht hilft dir ja das hier weiter:
http://stackoverflow.com/questions/5651 ... ne-options

Danke. Ich habe inzwischen tatsächlich alles zusammen bis auf den Live-Switch zwischen Fullscreen und Windowed, den ich unter Linux noch nicht implementiert habe. Und es war tatsächlich ganz banal die Reihenfolge der Libs. Boost war nochmal ein Problem, weil ich das selbstgebaut habe und es beim Bauen irgendwo eine ICU gefunden hat, die einen Zacken älter war als die, die ich bereitgestellt hatte. Zum Glück reicht iconv und das eingebaute Locale-Zeugs unter Linux für ordentliche Zeichensatzkonvertierungen, und mehr brauch ich davon gar nicht. UTF16 zu UTF8 krieg ich grad noch alleine hin.

Dann hatte ich das Problem, dass ich hier und da ein paar Konfig-Defines vergessen hatte, so dass einige Libs eine andere API einer Lib gesehen hatten als das, womit die Lib eigentlich kompiliert wurde. Und ganz am Ende habe ich auch noch was über C++ gelernt. Meine eingangs genannte "Komische Konstante":
hatte eine "Undefined Reference to KONSTANTE" ausgelöst, was mich sehr verwundert hatte, weil drüber und drunter noch weitere solche Konstanten deklariert wurden, die kein Problem darstellten. Stellt sich aber heraus: eine Deklaration dieser Konstante ist keine Definition. Ich hätte wie bei einer nicht-konstanten statischen Variable noch in der cpp-Datei eine Definition nachreichen müssen. Und es ging nur deswegen bisher stressfrei, weil alle Compiler auch in der Debug-Version üblicherweise gleich den Zahlenwert verwenden, anstatt die konkrete Instanz der Konstante zu referenzieren. Obiger Funtkionsaufruf nahm aber seinen Parameter als Konst-Referenz, weswegen der GCC an der Stelle tatsächlich die echte Instanz verwenden wollte. Und sich dann natürlich beschwert hat, dass ich die nirgends definiert habe. Visual C++ hebt das aber nicht an, der kommt damit überall stressfrei klar.

Noch ein Strich auf der "GCC ist ein Klugscheißer"-Zählung. Oder eher ein Fall für eine Detailkorrektur am C++-Standard.