Spielespezial: Kompilieren von TheDarkMod unter Linux und FreeBSD / Lauffähigkeit unter FreeBSD

[medV2]

So jetzt habt ihr mich irgendwie auch angefixt mit "Bauen wir mal unnötigerweiße altes Zeug"

Also wir reden hier ja die ganze Zeit vom Head, also der DevVersion, die hat wohl generell ihre Macken. Ich habe jetzt probiert auf einem Rocky9 (denke da ist die Chance für den FBSD Linuxulator rl9 am größten) das letzte Release (https://svn.thedarkmod.com/publicsvn/darkmod_src/branches/release212) zu kompilieren. Das geht ->

dnf groupinstall "development tools"
dnf groupinstall "Server with GUI" --allowerasing
dnf config-manager --enable devel
dnf in subversion cmake libX11-devel libXxf86vm-devel libXext-devel xorg-x11-server-devel libstdc++-static

Achtung, das ist nicht minimalistisch, ich hab einfach möglichst viel draufgeworfen da ich mich möglichst wenig mit Abhängigkeiten rumschlagen wollte.


Der Compilevorgang läuft zumindest durch. Binary startet auch, aber schließt gleich wieder, da es keine Assets findet. Die bekommt man wohl nur über den Installer - und das ist ewig langsam. Mal gucken


edit: Ach falls es jemand nachstellen will: Das src-Verzeichnis muss "darkmod" heißen, das steht wohl irgendwo hardcoded ...

 

[medV2]

So, Assets sind geladen und es startet mit dem selbst gebauten Binary. Sowohl unter Fedora als auch Rocky9. Unter FreeBSD kann ichs jetzt erstmal nicht testen, da hab ich keien Desktopmaschine zur verfügung.

 

[cabriofahrer]

Debian-Abkömmlinge wie Ubuntu paketieren Entwicklungsdateien wie Bibliotheken und Header in eigene Pakete. Dir fehlen zumindest die kompletten X.org-Bibliotheken.

Also ich habe sudo apt install xorg fluxbox gkrellmgemacht, bin dann mit startx /usr/bin/fluxbox in Fluxbox rein und trotzdem noch das Gleiche. Verstehe ich jetzt nicht:

 

[medV2]

Nimm das Release.

 

[cabriofahrer]

Nimm das Release.

So, gerade ausprobiert, aber genau das Gleiche. WTF???

 

[midnight]

Du benoetigst vermutlich noch den Source Code von X11. K.a. wie der unter Ubuntu heisst. Evtl. libx11-dev oder so.

 

[pit234a]

also, mich hat nun der Esel noch nicht geküsst und diese Antwort ist möglicherweise sehr dumm, aber im verlauf der Diskussion sah ich die Seite:
darkmod_downloads und da wiederum ein https://update.thedarkmod.com/zipsync/tdm_installer.linux64.zip das ich einfach mal, laut Anleitung, in einen Ordner ~./darkmod in einer alten Ubuntu 18.04 VM entpackte und aufgerufen habe (vielleicht leider als root?).
Dieses Install-Script macht quasi "alles", was zuvor besprochen wurde. Es wählt einen Zweig, lädt die Sourcen (per svn), entpackt "richtig" und installiert dann. Während dieses Ablaufs erscheinen an manchen Stellen Fenster, in denen man eine Auswahl treffen kann. Ich habe nur die Vorauswahl benutzt und in meiner VM offenbar auch eine sehr langsame Internet-Verbindung gehabt. Die Installation dauerte sehr lange und ich habe nur gelegentlich einen Blick darauf geworfen.
Zum Ende wurde gefragt, ob ein Desktop-Icon erstellt werden soll, wozu ich mal ja sagte und dann erklärt bekam, dass root keinen Desktop hat. Tatsächlich hat nicht nur root keinen Desktop auf diesem System, aber womöglich hätte ein .desktop-Eintrag noch spezielle Start-Optionen hinzu gefügt. So startete ich einfach (siehe Beschreibung im Ersten Link oben) als User das thedarkmod.x64 in ~./darkmod und es erschien eine Grafik im Fullscreen-Mode, wo links abwechselnd finstere Gestalten in mittelalterlichem Outfit erschienen und rechts ein Menü in englischer Sprache dargestellt wurde. Allerdings konnte ich dieses Menü nicht benutzen, weder Tastatur noch Maus erreichten es.
Die alte VM hat definitiv Schwierigkeiten mit dem Host zu interagieren. Deshalb und weil mich die Sache eh nicht so wirklich interessierte, schloss ich die Anwendung und kümmerte mich nicht weiter darum und habe irgendwie auch keinen Drang, hier weiter zu machen.

Auf den Thread-Verlauf bezogen scheint mir aber dieses Install-Script für Linux eine weitere und womöglich recht bequeme Möglichkeit zu sein, zum Ziel zu kommen.

 

[midnight]

Ich kann meinen obigen Beitrag nicht mehr editieren. Hast Du alle Abhaengigkeiten installiert, die hier angegeben sind?

https://github.com/stgatilov/darkmod_src/blob/trunk/COMPILING.txt

  sudo apt-get install subversion               //svnversion: not found
  sudo apt-get install mesa-common-dev          //no such file: "Gl/gl.h"
  sudo apt-get install libxxf86vm-dev           //no such file: "X11/extensions/xf86vmode.h"
  sudo apt-get install libopenal-dev            //no such file: "AL/al.h"
  sudo apt-get install libxext-dev              //no such file: "X11/extensions/Xext.h"
  sudo snap install cmake                       //we need a recent version of CMake, so install from snap instead of apt

Fuer 32-bit zusaetzlich noch

  sudo apt-get install g++-multilib             //no such file: 'sys/cdefs.h'
  sudo apt-get install libx11-dev:i386          //cannot find "-lX11"
  sudo apt-get install libxxf86vm-dev:i386      //cannot find "-lXxf86vm"
  sudo apt-get install libopenal-dev:i386       //cannot find "-lopenal"
  sudo apt-get install libxext-dev:i386         //cannot find "-lXext"

 

[medV2]

So, gerade ausprobiert, aber genau das Gleiche. WTF???

Mhmm komisch, ich hatte jedenfalls die gleichen Fehler (oder zumindest einige davon) mit der Dev-Version, und mit der Release-Version waren die dann weg.
Vielleicht fehlt dir wirklich noch irgend eine X Abhängigkeit wie @midnight schon geschrieben hat. Ev. probierst dus einfach unter Rocky9, da wissen wir, das es prinzipiell funktioniert - und unter BSD läuft es ja dann sowieso auch mit der rl9 Umgebung.

also, mich hat nun der Esel noch nicht geküsst und diese Antwort ist möglicherweise sehr dumm, aber im verlauf der Diskussion sah ich die Seite:
darkmod_downloads und da wiederum ein https://update.thedarkmod.com/zipsync/tdm_installer.linux64.zip das ich einfach mal, laut Anleitung, in einen Ordner ~./darkmod in einer alten Ubuntu 18.04 VM entpackte und aufgerufen habe (vielleicht leider als root?).
Dieses Install-Script macht quasi "alles", was zuvor besprochen wurde. Es wählt einen Zweig, lädt die Sourcen (per svn), entpackt "richtig" und installiert dann. Während dieses Ablaufs erscheinen an manchen Stellen Fenster, in denen man eine Auswahl treffen kann. Ich habe nur die Vorauswahl benutzt und in meiner VM offenbar auch eine sehr langsame Internet-Verbindung gehabt. Die Installation dauerte sehr lange und ich habe nur gelegentlich einen Blick darauf geworfen.
Zum Ende wurde gefragt, ob ein Desktop-Icon erstellt werden soll, wozu ich mal ja sagte und dann erklärt bekam, dass root keinen Desktop hat. Tatsächlich hat nicht nur root keinen Desktop auf diesem System, aber womöglich hätte ein .desktop-Eintrag noch spezielle Start-Optionen hinzu gefügt. So startete ich einfach (siehe Beschreibung im Ersten Link oben) als User das thedarkmod.x64 in ~./darkmod und es erschien eine Grafik im Fullscreen-Mode, wo links abwechselnd finstere Gestalten in mittelalterlichem Outfit erschienen und rechts ein Menü in englischer Sprache dargestellt wurde. Allerdings konnte ich dieses Menü nicht benutzen, weder Tastatur noch Maus erreichten es.
Die alte VM hat definitiv Schwierigkeiten mit dem Host zu interagieren. Deshalb und weil mich die Sache eh nicht so wirklich interessierte, schloss ich die Anwendung und kümmerte mich nicht weiter darum und habe irgendwie auch keinen Drang, hier weiter zu machen.

Auf den Thread-Verlauf bezogen scheint mir aber dieses Install-Script für Linux eine weitere und womöglich recht bequeme Möglichkeit zu sein, zum Ziel zu kommen.

Wir versuchen ja das Ding zu Compilieren, möglichst unter FreeBSD, oder so, dass es unter FreeBSD möglichst lauffähig ist. Der Installer macht das nicht, der lädt ein fertiges Binary.
Das man das ganze einfach unter wine spielen könnte, haben wir hier ja auch schon festegestellt, wenns nur darum ginge.

 

[cabriofahrer]

Du benoetigst vermutlich noch den Source Code von X11. K.a. wie der unter Ubuntu heisst. Evtl. libx11-dev oder so.

Ist installiert:

Vielleicht fehlt dir wirklich noch irgend eine X Abhängigkeit wie @midnight schon geschrieben hat.

Dass irgendetwas fehlt, ist offensichtlich, aber nicht libx11-dev. Offenbar hat der Ersteller der Anleitung in COMPILING.txt irgendetwas vergessen.

Mhmm komisch, ich hatte jedenfalls die gleichen Fehler (oder zumindest einige davon) mit der Dev-Version, und mit der Release-Version waren die dann weg.

Wenn Du Release-Version sagst, meinst Du dann auch 16.04 LTS?

Ev. probierst dus einfach unter Rocky9, da wissen wir, das es prinzipiell funktioniert - und unter BSD läuft es ja dann sowieso auch mit der rl9 Umgebung.

Also hast Du das jetzt konkret getestet, das unter Rocky9 Linux kompilierte Binary dann unter FreeBSD mit einer rl9 Umgebung zum Laufen zu bringen? Weiter oben hattest Du das ja schon mal erwähnt, das war aber noch eine Mutmaßung. Ich werde jetzt an meinem Hauptrechner nicht die c7-Umgebung deinstallieren und durch rl9 ersetzen, da einige Dinge damit sicher laufen, vor allem ETQW und jetzt auch UT2004, was ich aufgrund dieses Threads dann auch installiert habe. Ferner haben einige ports wie linux-doom3 und linux-quake4 noch c7 als Abhängigkeit.
Deswegen bin ich im Moment eher daran interessiert, das noch mit Ubuntu 16.04 hinzukriegen. Wir müssen also zunächst herausfinden, was genau dem Ubuntu 16.04 fehlt, um das Binary zu kompilieren.
Unabhängig davon würde ich gerne mal rl9 testen, aber auf dem Laptop. Vorher müsste ich da aber noch ein Upgrade machen und dazu habe ich jetzt gerade keine Zeit.

 

[medV2]

Wenn Du Release-Version sagst, meinst Du dann auch 16.04 LTS?

Nein, ich meine das Release von TDM. Also nicht den trunk auschecken,sondern releases. Wie oben von mir geschrieben.

Also hast Du das jetzt konkret getestet, das unter Rocky9 Linux kompilierte Binary dann unter FreeBSD mit einer rl9 Umgebung zum Laufen zu bringen?

Nein noch nicht. Aber dass ein ubuntu Binary unter c7 funktioniert, steht ja auch nicht fest.

Weiter oben hattest Du das ja schon mal erwähnt, das war aber noch eine Mutmaßung. Ich werde jetzt an meinem Hauptrechner nicht die c7-Umgebung deinstallieren und durch rl9 ersetzen, da einige Dinge damit sicher laufen, vor allem ETQW und jetzt auch UT2004, was ich aufgrund dieses Threads dann auch installiert habe. Ferner haben einige ports wie linux-doom3 und linux-quake4 noch c7 als Abhängigkeit.
Deswegen bin ich im Moment eher daran interessiert, das noch mit Ubuntu 16.04 hinzukriegen. Wir müssen also zunächst herausfinden, was genau dem Ubuntu 16.04 fehlt, um das Binary zu kompilieren.
Unabhängig davon würde ich gerne mal rl9 testen, aber auf dem Laptop. Vorher müsste ich da aber noch ein Upgrade machen und dazu habe ich jetzt gerade keine Zeit.

c7 wird nicht mehr supported, früher oder später musst du da sowieso umstellen

 

[pit234a]

Der Installer macht das nicht, der lädt ein fertiges Binary.

so weit ich das nebenbei beobachtet habe, macht der Installer das nicht.
Sondern, er öffnet zunächst einen Dialog, wo man entscheiden kann, welcher Branch mittels SVN ins Startverzeichnis geladen wird. Per Default war hier nicht @head eingestellt, sondern, ich denke, die gleiche Version, wie von dir benutzt, irgendwas 2.1 oder so, ohne genau hingesehen zu haben.
Danach sammelt der Installer wieder Oprionen, die sich in einem Fenster anklicken lassen und erstellen (kompiliert) dann das Binary entsprechend.

Ich denke, dass dies zumindest die Gefahr von Typos auf der Kommandozeile reduziert und auch mal zeigen kann, ob überhaupt was geht. Nacharbeit und Verbesserung natürlich nicht ausgeschlossen.

Deswegen bin ich im Moment eher daran interessiert, das noch mit Ubuntu 16.04 hinzukriegen.

warum?
Ist doch egal, welches Ubuntu das nun macht, oder?
So weit ich das sehe, brauchst du nicht die Server-Version eines Ubuntu, bzw musst du die dann entsprechend aufmotzen, um auch alles in X zu bekommen. Geht vielleicht dann doch einfacher mit einer Desktop-Version, die schon alles mitbringt.
Du willst das Spiel ja auch nicht von der Kommandozeile spielen und brauchst also eh unbedingt einen Desktop dafür.

 

[cabriofahrer]

Nein, ich meine das Release von TDM. Also nicht den trunk auschecken,sondern releases. Wie oben von mir geschrieben.

Autsch, das hatte ich leider nicht richtig verstanden, ich hatte nur #99 gesehen, #96 war mir entgangen. Also OK dann erstmal
svn checkout https://svn.thedarkmod.com/publicsvn/darkmod_src/branches/release212 --depth=infinity .
Hat funktioniert, der Kompiliervorgang lief durch!

Nein noch nicht. Aber dass ein ubuntu Binary unter c7 funktioniert, steht ja auch nicht fest.

Jetzt leider schon: Den darkmod folder dann von der VM per sftp zum FreeBSD Host rüberkopiert (musste vorher openssh nich installieren, bei der Ubuntu-Server Version konnte man ihn bei der Installation direkt anklicken, auch interessant...) und hier das Resultat:

Also, das mit Ubuntu16.04 kompilierte Binary will GLIBC_2.18, Linux c7 hat aber nur 2.17.

c7 wird nicht mehr supported, früher oder später musst du da sowieso umstellen

Das werde ich dann wohl auch, wenn ich den Test auf dem Notebook vorher gemacht habe.

warum?
Ist doch egal, welches Ubuntu das nun macht, oder?
So weit ich das sehe, brauchst du nicht die Server-Version eines Ubuntu, bzw musst du die dann entsprechend aufmotzen, um auch alles in X zu bekommen. Geht vielleicht dann doch einfacher mit einer Desktop-Version, die schon alles mitbringt.
Du willst das Spiel ja auch nicht von der Kommandozeile spielen und brauchst also eh unbedingt einen Desktop dafür.

Nein, die Hoffnung war, dass ein unter 16.04 kompiliertes Binary vielleicht noch eine glibc-Version hat, die noch unter c7 läuft. Ist aber leider nicht der Fall. D.h. bei jeder höheren Version von Ubuntu wäre das noch weniger der Fall.
Wenn ich das Missverständnis mit dem Release nicht gehabt hätte, hätte ich mir die Installation von der Ubuntu Desktop Version sparen können. Die Server Version war mir wesenlich lieber, hat schneller gebootet, hatte mehr Speicherplatz auf der virtuellen Festplatte und hat wie schon gesagt ssh gleich mitgebracht.
Und Sinn der Übung war ja nicht, das unter Ubuntu kompilierte Binary unter dem Ubuntu (wie gesagt, nur eine VM) auszuführen, sondern zu sehen, ob es unter FreeBSD mit c7 ausführbar ist. Jetzt wissen wir, dass leider nicht.

 

[Alexco]

Wenn Du nicht in der FreeBSD Linux-Umgebung direkt kompilieren möchtest, könntest Du auch einfach versuchen glibc statisch zu linken

gcc -static -static-libgcc -static-libstdc++

Gibt es da ein Configure Script? Dann kann man das über CFLAGS ja mit einbauen.

 

[cabriofahrer]

Wenn Du nicht in der FreeBSD Linux-Umgebung direkt kompilieren möchtest, könntest Du auch einfach versuchen glibc statisch zu linken

Ich verstehe Deine Aussage leider nicht ganz. Willst Du etwa sagen, dass es überhaupt möglich wäre, direkt in die Linux-Umgebung zu wechseln und dann darin zu kompilieren? Das kann doch gar nicht gehen, zumindest hat die Linux-Umgebung keinen Paketmanager, so dass man eventuell dazu benötigte Pakete noch installieren könnte. Den Vorschlag mit dem "statisch verlinken" verstehe ich auch nicht: Was genau wird womit verlinkt?

Gibt es da ein Configure Script? Dann kann man das über CFLAGS ja mit einbauen.

Auf den ersten Blick nicht:

 

[midnight]

Willst Du etwa sagen, dass es überhaupt möglich wäre, direkt in die Linux-Umgebung zu wechseln und dann darin zu kompilieren?

Unter Ubuntu geht das jedenfalls. Nach diesem Hotwo hatte ich "damals" Google Chrome installiert. Dort wechselt man via chroot in die Ubuntu-Umgebung und kann ganz normal die Pakete mit apt installieren.

https://forums.freebsd.org/threads/...-google-chrome-linux-binary-on-freebsd.77559/

Ob das noch immer so geht und ob dir das ueberhaupt bei deinem Problem hilft, weiss ich allerdings nicht.

 

[Andy_m4]

Ob das noch immer so geht

Gehen tut das vermutlich immer noch.
Allerdings würde ich nicht nach /compat/linux installieren, sondern mir ein anderes Verzeichnis nehmen (/compat/ubuntu ?), um nicht mit existierenden Ports (insbesondere c7 bzw. rl9) zu kollidieren (worauf die Anleitung auch hinweist).

 

[medV2]

Meine Herren, GLIBC lässt sich kaum statisch kompilieren.

 

[Alexco]

Natürlich lässt sich das statisch kompilieren. Anders lässt sich der Paketmanager/Distrowahnsinn auch kaum noch handhaben, wenn man für Linux kommerzielle Binaries anbieten möchte.

 

[medV2]

Natürlich lässt sich das statisch kompilieren. Anders lässt sich der Paketmanager/Distrowahnsinn auch kaum noch handhaben, wenn man für Linux kommerzielle Binaries anbieten möchte.

Dafür gibt's flatpak und snap

 

[Alexco]

Genau, statt zwöfunddrölfzig Paketmanager und Ökosysteme supporte ich einfach noch 2 weitere, deren Akzeptanz bei den Linuxern knapp über der Grasnarbe ist.
Nö, lieber statisch linken und ein Installerskript dabei. Macht Linus auch so

 

[medV2]

Genau, statt zwöfunddrölfzig Paketmanager und Ökosysteme supporte ich einfach noch 2 weitere, deren Akzeptanz bei den Linuxern knapp über der Grasnarbe ist.
Nö, lieber statisch linken und ein Installerskript dabei. Macht Linus auch so

Nein statt zwölfunddrölfzig musst du nur mehr einen supporten. Zur Akzeptanz sagt die Nutzungsstatistik von Flatpak auch was anderes. Und wie schon gesagt - die glibc kann man nicht immer statisch linken.

 

[Andy_m4]

Nö, lieber statisch linken und ein Installerskript dabei. Macht Linus auch so

Mit dem Kernel oder wie?

 

[Alexco]

Ich weiß langsam echt nicht, ob ich lachen oder weinen soll. Der Herr Torvalds hat auch eine eigene Software, für die er tatsächlich auch vorkompilierte Pakete anbietet. Komischerweise eben nicht für Linux, weil das Paketmanagement "broken by design" ist. Es gibt da auch genug Diskussionen und Videos dazu, einfach mal im großen Netz suchen...

 

[Columbo0815]

So langsam sollten wir dann doch wieder zurück zum eigentlich Thema kommen.