Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
sim-linux64?
#31
sim-linux64_120-2-2.zip ~10MByte

Könnt ja mal testen. Erstellt mit Mageia 6 ( Red Heat Basis ).

Midi dürfte aber wohl nicht gehen, weil am Ende was von no-midi.cc stand.

Fragt mich nicht warum die ~27 MByte groß ist. Hab die Src-Datei von SF runtergeladen und nur ./configure.sh und make ausgeführt.

Normal sind eigentlich um 5 MByte.
Zitieren
#32
Edit: Dieser Beitrag bezieht sich auf den vorletzten Beitrag von Wurzelgnom


(12-08-2017, Saturday-10:41:23 )Wurzelgnom schrieb: Und genau so findet man uU in der Paketverwaltung bei der Suche nach g++ nichts.
Das liegt daran dass g++ kein eigenes Paket ist, sondern als Teil der gcc (GNU compiler collection) daherkommt. Das ist insofern verwirrend als gcc eben gleichzeitig der Aufruf fuer den Gnu C-Compiler ist, waehrend g++ der Aufruf fuer den GNU C++ Compiler ist.

(12-08-2017, Saturday-10:41:23 )Wurzelgnom schrieb: Ich hab auch in den aktuellen Linuxen die SDL-Mixer nicht mehr gefunden in den Paketquellen. Auch ist teilweise nur noch SDL2 dabei.
Und der Versuch die 102.2.2 zu kompilieren scheitert kläglich, während die 112.3 und die 120.2.2 kompiliert wird. Hier fehlt aber scheinbar SDL1.2.
Dieses SDL Chaos ist in der Tat zum Verzweifeln!


(12-08-2017, Saturday-10:41:23 )Wurzelgnom schrieb: Bisher hab ich es nämlich nicht geschafft ein statisches Makeobj zu erstellen was auch auf dem Server funktioniert. Keine Ahnung was werniman damals zusammen gestellt hatte, aber seine funktionieren. Selbst nach einem Serverwechsel mit anderem Linux. Nur leider ist die damalige Installation nicht mehr vorhanden und er kann sich nicht erinnern wie er es damals gemacht hat.
Hmpf! Das ist natuerlich wirklich tragisch!

Eine interessante Aussage die ich bei etwas weiterer DuckDuckGo-Recherche zu "CentOS AND g++" fand, ist dass CentOS als Server-Distribution nicht wirklich eine optimale Entwicklungsumgebung ist, was sich unter anderem darin zeigt dass es offenbar reichlich Nutzer gibt, die auf dieser Distribution den g++ vermissen bzw ihn nicht finden. Tenor in den den Diskussionen ist eigentlich, zum entwickeln auf eine andere Distribution umzusteigen, deren compiler-Pakete etwas naeher an unserer Zeit sind. Ich kann das nicht kommentieren, finde es aber nicht unlogisch.

(12-08-2017, Saturday-10:41:23 )Wurzelgnom schrieb: Im Prinzip braucht man bei den Paketen nur 4 Versionen. Suse, RedHeat, Ubuntu und Debian. Alles andere ist mehr oder weniger davon abgeleitet. Bis auf Arch-Linux.
Fuer SuSE und RedHat benoetigt es RPM Pakete (.rpm), fuer Debian Derivate (damit auch fuer Ubuntu und Mint, etc) braucht es DEB Pakete (.deb).


(12-08-2017, Saturday-10:41:23 )makie schrieb: Selbst Compiliertes gehört eigentlich in /home/user/bin <- "user" Name des Benutzers
jedes andere eigne Verzeichnis geht eigentlich auch. Zu Not mir bash simutrans starten. Dann kann man sich sudo usw. sparen.
Das Kennzeichen für Ausführbar im Inhaltverzeichnis setzten (Execution Flag) Datei ausführbar machen chmod +x file
Was Du in Deinem Benutzerverzeichnis (/home/[user]) anstellst ist allein Dir ueberlassen, da gibt es eigentlich keine Regeln und um dort etwas auszufuehren benoetigst Du auch kein sudo oder root-Rechte, da es ja Dir gehoert. Bei mir landet selbstkompiliertes (wie Simutrans) zum beispiel in /home/[user]/Programme/... .

Wenn Du allerdings ein Kompilat systemweit installieren willst, also so dass es alle jetzigen und zukuenftigen Benutzer des Systems benutzen koennen, dann muss das Programm in /usr/local/..., /opt/... oder /var/... installiert werden, und da hat nur ein superuser (root) Schreibrechte. Deshalb sudo (bei Debian Derivaten). Dazu gibt es ja in simutrans.conf auch einen Schalter, der festlegt wo Deine Benutzerdateien gespeichert werden: Im simutrans-Programmverzeichnis (wenn Du das Programm unter /home/[user]/... installiert hast), oder in /home/[user]/.simutrans/ , also einem unsichtbaren Verzeichnis, wenn Simutrans systemweit installiert ist.

Wenn die make install Regel als target das Homeverzeichnis des jeweiligen Benutzers anvisiert und keine Standardpfade verwendet dann sollte make install auch ohne sudo gehen.

(12-08-2017, Saturday-13:14:41 )Wurzelgnom schrieb: sim-linux64_120-2-2.zip ~10MByte

Könnt ja mal testen. Erstellt mit Mageia 6 ( Red Heat Basis ).

Midi dürfte aber wohl nicht gehen, weil am Ende was von no-midi.cc stand.

Fragt mich nicht warum die ~27 MByte groß ist. Hab die Src-Datei von SF runtergeladen und nur ./configure.sh und make ausgeführt.

Normal sind eigentlich um 5 MByte.

Startet nicht:

Code:
sro@bregne14:~/Programme/simutrans-Wurzelgnom_12.08.2017$ ./sim &
[1] 4024
sro@bregne14:~/Programme/simutrans-Wurzelgnom_12.08.2017$ ./sim: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./sim)


Mein Kompilat von neulich (120.2.2, 64Bit) ist uebrigens auch nur 4.7 MB gross. Dieses Midi-Problem haengt ursaechlich wirklich mit dem Chaos zwischen SDL und SDL2 zusammen. Das ist zum Haare raufen.
Norwegen braucht mehr Einwohner! Gebt Bregneby einen neuen Buerger
Zitieren
#33
(12-08-2017, Saturday-13:27:43 )sro schrieb: ....
Wenn Du allerdings ein Kompilat systemweit installieren willst, also so dass es alle jetzigen und zukuenftigen Benutzer des Systems benutzen koennen, dann muss das Programm in /usr/local/..., /opt/... oder /var/... installiert werden, und da hat nur ein superuser (root) Schreibrechte. Deshalb sudo (bei Debian Derivaten). Dazu gibt es ja in simutrans.conf auch einen Schalter, der festlegt wo Deine Benutzerdateien gespeichert werden: Im simutrans-Programmverzeichnis (wenn Du das Programm unter /home/[user]/... installiert hast), oder in /home/[user]/.simutrans/ , also einem unsichtbaren Verzeichnis, wenn Simutrans systemweit installiert ist.
....

Der simuconf-Schalter ist eher dafür, wenn Simutrans portabel ( USB-Stick ) sein soll.

Selbst wenn Simutrans im Userverzeichnis ausgeführt wird ist das Home-Verzeichnis für die Daten nützlich. Denn wechselt man die Version muss man nicht immer alles rüber kopieren. Gerade dann wenn man eine neue Version parallel ausprobieren möchte bevor man voll umsteigt. Man muss halt nur drauf achten das es keine Überschneidung bei den Pfadnamen gibt.

Andererseits ist das die einzigste Möglichkeit verschiedene Versionen zu nutzen. Und da kommt dann wieder das Nightly-Problem zum tragen. Wenn man nämlich nur mal ein Nightly testen möchte gehen die Einstellungen der Standard-Version verloren, weil die Einstellungsdateien überschrieben werden.

Im Moment bin ich auf der Suche nach einem geeigneten Linux für einen Laptop ( Vista-Support ist ja ausgelaufen ) . Von daher probiere ich halt rum, was darauf geeignet ist von der Handhabung.
Zitieren
#34
Danke fuer den Hinweis!
Und Korrektur: Mein eigenes Kompilat hat auch 26.5 MB Dodgy 
Falls Du es testen moechtest: sim.zip
Norwegen braucht mehr Einwohner! Gebt Bregneby einen neuen Buerger
Zitieren
#35
Zu dem Fehler oben, da fehlt was in Deiner Installation.

siehe hier
___________________________________

Hab bei Mageia jetzt auch lib64sdl2_mixer-devel/lib64sdl2_mixer2.0_0 in den Paketquellen gefunden.

Hab nur keine Ahnung wo ich das passende Backend definiere.
___________________________________

Was die Dateigröße angeht, das liegt an den Debug-Optionen die von configure.sh gesetzt werden.

Kommentiert man die aus, dann bekommt man ne 4 MByte Datei erstellt.
Zitieren
#36
sim64_120-2-2_sdl2.zip ~2 MByte
sim64_120-2-2_sdl-mixer.zip ~2 MByte

erstellt mit Xubuntu 14.04.5 amd64
Zitieren
#37
(12-08-2017, Saturday-13:27:43 )sro schrieb: ...
(12-08-2017, Saturday-10:41:23 )Wurzelgnom schrieb: Bisher hab ich es nämlich nicht geschafft ein statisches Makeobj zu erstellen was auch auf dem Server funktioniert. Keine Ahnung was werniman damals zusammen gestellt hatte, aber seine funktionieren. Selbst nach einem Serverwechsel mit anderem Linux. Nur leider ist die damalige Installation nicht mehr vorhanden und er kann sich nicht erinnern wie er es damals gemacht hat.
Hmpf! Das ist natuerlich wirklich tragisch!
....

Nun hat es doch noch geklappt. Mit einem Xubuntu 14.04.5 amd64.

Die sind auch im 120.2.2-Thread verlinkt. Möglich das die auch bei anderen funktionieren.
Zitieren
#38
Idea Bingo!

sim64_120-2-2_sdl-mixer laeuft bei mir auf Anhieb mit Sound. Die Version mit SDL 2 laeuft ohne Sound.

Betriebssystem: Ubuntu 14.04 64Bit

Mein Vorgehen zur Installation fuer den Test:
  1. Neues Verzeichnis mit vollstaendigem 32-Bit Simutrans 120.2.2 aus Sourceforge angelegt.
  2. PAK128.German in neuester Version reinkopiert
  3. Die sim64_120-2-2_sdl-mixer aus Deinem Beitrag reinkopiert
  4. config/simutrans.conf: SingleUser Install =1 (um vorhandene Altinstallation und saves zu schonen)
  5. sim64_120-2-2_sdl-mixer ausgefuehrt. 
  6. Funzt!

Sieht so aus als haettest Du/haettet Ihr es geschafft! Die Tatsache dass fuer Linux_64Bit die SDL, und nicht die SDL2 benutzt werden muss deckt sich mit den Meldungen der Debian Maintainer, die ebenfalls SDL2 durch SDL-mixer ersetzt haben.

Ich gratuliere! Ihr seid die Besten  Big Grin Heart Vielen Dank!
Norwegen braucht mehr Einwohner! Gebt Bregneby einen neuen Buerger
Zitieren
#39
Muss Dich enttäuschen. Das die bei Dir läuft liegt daran das xubuntu 14.04.5 auf Ubuntu 14.04 beruht.

Also ich im Prinzip das selbe System hab wie Du.

Hinzu kommt, das Ubuntu 14.4 schon mehrere Jahre alt ist und demzufolge auch die Bestandteile älter sind. Es handelt sich aber wiederum um eine LTS-Version, weshalb die noch viel benutzt werden dürfte.

Also in wie weit das bei neueren/anderen Linuxen funktioniert steht in den Sternen und müsste jetzt getestet werden.

Und SDL2-Mixer ist noch nicht im Makefile definiert. Geben tut es das nämlich schon. Nur dafür hab ich zu wenig Kenntnisse um das einzupflegen.
Zitieren
#40
Bei Mageia 6 ist ein zusätzlicher Symlink nötig damit es läuf.

in usr/lib64
Code:
ln -s libbz2.so.1.0.6 libbz2.so.1.0

Midi scheint aber nicht zu gehen.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste