sim-linux64?

[prissi]

Der Simitransquellcode kann nach dem Runterladen gebaut werden mit configure (oder sollte es jedenfalls). Das ist Unixstandard. Mehr Standard geht nicht.

configure
make

fertig. make install scheitert, weil es das einfach zuviel "Standardverzeichnisse" gibt, die für Otto Normaluser nicht beschreibbar sind.

[Wurzelgnom]

Der Simitransquellcode kann nach dem Runterladen gebaut werden mit configure (oder sollte es jedenfalls). Das ist Unixstandard. Mehr Standard geht nicht.

configure
make

fertig. make install scheitert, weil es das einfach zuviel "Standardverzeichnisse" gibt, die für Otto Normaluser nicht beschreibbar sind.

Wenn aber die Quellen von libpng, zlib, bz2 und SDL/SDL2 gar nicht im System sind wie verhält sich das dann?

Selbst der gcc muss nicht unbedingt installiert sein bei einem nur Anwender System.

Musste mir unter Ubuntu/KaOS einiges zusammen suchen und dann auch Pfade anpassen damit überhaupt compiliert wurde.

Und ein statisches Makeobj was auf dem Server funktioniert hab ich bis heute auch noch nicht hin bekommen.

[prissi]

Der Linuxstandard schreibt vor, das gcc und diverse Entwicklerlibaries vorhanden sind. Aber meistens ignorieren Distro die LSD eh. Dann muss man eben die Simutransversion nehmen, die mitgeliefert wird, und eben auch nur die Standardpaks. Oder man verwendet Stream.

Ein Binary muss unter Linux n:mlich auch mit einer Version der DLL gelinkt sein, die auf dem System ist. Fuer Ubuntu muesse ein moeglichst neue sein, fuer Debian alte. Da kann man es auch nicht allen recht machen. Auch ein souce-rpm wird nicht von alle Distros genommen, die wollen dann deb oder noch was anderes.

Fuer konstruktive Vorschlaege bin ich dankbar, aber ausser statisch gelinkt gibt es nicht viel was bei Linux portabel ist.

[sro]

Prissi schrieb:

Der Simitransquellcode kann nach dem Runterladen gebaut werden mit configure (oder sollte es jedenfalls). Das ist Unixstandard. Mehr Standard geht nicht.

configure
make

fertig. make install scheitert, weil es das einfach zuviel "Standardverzeichnisse" gibt, die für Otto Normaluser nicht beschreibbar sind.

cd    [sourcecodeverzeichnis]
configure    (./configure, wenn nicht im Standardpfad)
make
sudo make install (auf Debian-artigen Linuxen)

dazu muesste allerdings eine Regel fuer "make install" definiert werden, sonst gibt's ne Fehlermeldung.

Das ist die Standardprozedur (Linux laesst Programminstallationen nur durch root bzw Superuser zu, alte Unix Tradition ;-) . Fuer Simutrans wuerde ich allerdings auch zu einem statisch gelinkten binary raten, auch wenn das mehr Platz in Anspruch nimmt. ABer der Wurzelgnom hat natuerlich recht: Wenn die libraries fehlen dann klappt das nicht. Man kann sie natuerlich nachinstallieren (bei Debian-artigen mittels "apt-get install [Paketname]"). Das ist nicht das was der "Otto-Normaluser" moechte, aber wer immer die neueste Version haben will, der muss da halt durch. Das andere Extrem sind die Repositories der grossen Distros, die zum Teil voellig veraltete Versionen beinhalten (z.B. Ubuntu 14.04 LST: Simutrans 113.x). Die Verfuegbarkeit einer statisch gelinkten Version direkt von Simutrans aus, wenigstens fuer neue Hauptnummern-Versionen, waere daher imho eine gute Ergaenzung zu den Versionen in den diversen Repos der einzelnen Distributionen.

Vielen Dank fuer den Hinweis auf die 120.2.2 im Debian-Repo, ich schaue mir das mal an. Ich habe gerade mal die 120.2.2 (auf 64Bit Ubuntu 14.04) kompiliert, (mit ./configure.sh als erstem Schritt). Dann das binary "sim" manuell in mein existierendes simutrans Verzeichnis kopiert und gestartet. Klappt tadellos, aber nach wie vor ohne Musik (SDL-Mixer2/SDL-Mixer Problem)

Die Linux Distributionen, insbesondere die halbkommerziellen (wie Ubuntu), machen in der Tat heute haeufig ihr eigenes Ding (und Canonical/Ubuntu sind damit auch gerade grandios vor die Wand gefahren). Die Tatsache dass es mindestens zwei vollstaendig unterschiedliche und inkompatible Systeme der Paketverwaltung (.deb und .rpm) gibt macht es fuer die Entwickler von Anwendungssoftware auch nicht einfacher.

[Wurzelgnom]

configure.sh scheint es aber auch erst seit den 120er Versionen zu geben.

Code:

[centos@localhost simutrans-src-120-1-3]$ ./configure.sh
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking how to run the C++ preprocessor... /lib/cpp
configure.sh: error: in `/home/centos/Desktop/simutrans-src-120-1-3':
configure.sh: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
[centos@localhost simutrans-src-120-1-3]$

Ich steh jetzt als Halblaie bei dieser Fehlermeldung im Regen.

Das Ganze  auf einem jungfreulichen CentOS 7 mit hinzugefügten Sourcen von zlib, libpng, bzip2 und SDL.

[prissi]

sudo fuer make install ist was relativ neues, und ist nur erforderlich wenn ich Standardpfade verwenden. Eben jene sind von der Distribution abhaengig, da kocht jeder sein eigenes Sueppchen. Somit kann es kein einfahces make install geben, sondern dass muss fuer jede Distrofamilie ein eigenes sein. (Mal abgesehen, dass das configure natuerlich auch auf BSD und Amiga geht).

Und ohne g++ wird simutrans nicht in der Lage sein, sich zu bauen, da es ein C++ Programm ist ... Wie gesagt, ich wuerde gerne auf Linuxpakete zur Verfuegung stellen, habe aber weder Zeit noch Musse mich da einzuarbeiten. Freiwillige vor.

[Wurzelgnom]

...
Und ohne g++ wird simutrans nicht in der Lage sein, sich zu bauen, da es ein C++ Programm ist ... Wie gesagt, ich wuerde gerne auf Linuxpakete zur Verfuegung stellen, habe aber weder Zeit noch Musse mich da einzuarbeiten. Freiwillige vor.

mmh

Also Simutrans ist in C++ geschrieben benötigt g++ und in den Paketquellen steht dafür Objektive-C support for GCC und Objektive-C++ support for GCC.

Eine Suche nach g++ fördert in den Paketquellen nichts zu Tage bei CentOS 7.

[sro]

Hmm, also das sind jetzt Dinge von denen ich nicht wirklich eine Ahnung habe. Aber g++ ist lediglich eine art von gcc compiler (gcc = "gnu compiler collection"). Wenn ich auf meinem Ubuntu 14.04(64 Bit) Notebook in der Shell "g++ -v" aufrufe, dann sieht das so aus...
-----------------------------------------------
sro@vaio-12:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) 
------------------------------------------------
d.h., bei mir wird g++ als vorhanden erkannt. 

"man g++" ist recht gespraechig, fuer mich aber Fachchinesisch. Zum Parameter "-v" sagt die manpage: "Print (on standard error output) the commands executed to run the stages of compilation.  Also print the version number of the compiler driver program and of the preprocessor and the compiler proper." 

Wenn bei Dir auf CentOS nix dazu kommt, dann stimmt evtl die gcc Installation bzw die (einige) Pfade dahin nicht, wuerde ich mal vermuten. In den Paketquellen gibt es "g++ nicht, weil es ein Teil von gcc ist.

Zum Thema gibt es massig Hits auf allen Suchmaschinen, vielleicht hilft What is the difference between g++ and gcc?, gefunden auf Stackoverflow.

Ich wuerde gern konkreter helfen, aber wie gesagt, davon habe ich nicht wirklich Plan.

Prissi, meinst Du dass bei den Standardpfaden jede Distri ihre eigene Idee von der Verwendung von /usr, /var und /opt hat? Das stimmt natuerlich, spielt aber imho keine Rolle, denn alle Distris sollten sowohl /usr/local, als auch /var und /opt anbieten, und das sind die Standardpfade fuer systemweite 3rd-Party Programminstallationen. Such Dir den aus den Du am liebsten magst. Darueber, was nun genau wo hingehoert gibt es wohl end- und fruchtlose Diskussionen zwischen den Gurus. Mit dem Ergebnis dass heute eigentlich nur noch allgemein respektiert wird, dass /usr und Unterverzeichnisse (ausser /usr/local) den Linux-Kernkomponenten vorbehalten ist und nicht fuer 3rd Party Kram verwendet werden soll. 
Ich hoffe das war jetzt kein Bullshit 

[makie]

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

Muß aber sagen ich hab da auch wenig Ahnung davon.Ich hab allerdings Simutrans schon aus Userverzeichnisen gestartet ohne Probleme.

[Wurzelgnom]

Ob g++ verfügbar ist beim gcc hängt schlicht davon ab, wie die Pakete gestaltet sind.

Die einen installieren schlicht gcc gleich komplett mit allem. Die anderen halt als extra Paket was man auch extra auswählen muss. Was man halt wissen muss.

Und die Namensgebung ist nicht immer intuitiv. ZBsp fördert die Suche nach SDL über alles nur Programme die es verwenden zu Tage.
Die Suche nach SDL2 findet dann die Dev-Pakete. SDL1 wiederum nichts weil nichts enthalten zu sein scheint.

Und genau so findet man uU in der Paketverwaltung bei der Suche nach g++ nichts.

Das es diverse Abfrageparameter gibt weis ich. Nur kenne ich die nicht. Wenn der Dateimanager dann nicht mal ne Dateisuche kennt ( Thunar ) wird es dann schon schwierig.

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.

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.

Weshalb es bei der Online-Dat nach wie vor nur Makeobj 50 ( Simutrans 0.102.0 ) gibt. Neben Makeobj 49 ( Simutrans 0.101.0 ) und Makeobj 44 ( Simutrans 0.99.08 ).

Was rpm-Pakete angeht, da stand vor paar Jahren mal ein Workshop in der c't. Muss mal schauen ob ich den wiederfinde.

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.