News:

SimuTranslator
Make Simutrans speak your language.

Why do you make it so hard for GNU/Linux users?

Started by PkK, September 26, 2013, 05:07:57 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

PkK

The download forum prominently features Installation instructions for Windows. It also has a compiled Linux binary, which might be useful to whoever has the exact same system configuration as the build machine.

Most GNU/Linux users these days run 64-bit systems, and cannot easily run your 32-bit executable.

Please provide source tarballs, information on how to get the source from the repository and quick instructions on building from source, as any project seriously targeting GNU/Linux users does.

Philipp

P.S.: All this would of course be useful to anyone wanting to compile from source for whatever reason, including people running other operating systems.


An_dz

Simutrans targets everybody, not only GNU/Linux. There's a space for anyone.

We may need to improve the documentation for how to compile online and where to get the sources.

Vladki

If you want to run 32-bit binary on 64-bit try installing 32-bit libraries. Use ldd command to find out which libraries are needed.

If you happen to run Debian, then you can try the packaged version. Just apt-get install simutrans. It's not the latest version however, but trivial to install. Maybe other distros have packages too.

Ters

I find there are two ways to install stuff on Linux: You either use the distro's package management system, or you do a non-standard installation. The former comes in many varieties, and the Simutrans community can't provide something for all. Each distro must provide this, which I've heard that several does. A non-standard installation is the same for every platform.

If you want to compile from source, you really should know what you're doing. I didn't have problems figuring that out.

Running Simutrans 64-bit is not supported, as many things are hardcoded for 32-bit data structures. So that's pretty much a "you're on your own" thing, which I was when I got it compiling and running a few years ago, though with less performance than my self compiled 32-bit executable on a comparable Windows machine. I haven't run Simutrans on my Linux box in over a year now, but a few others have managed to get a 64-bit Simutrans running from what I hear (the nightly server might even make executables).

prissi

There are source archieves on sourceforge for every stable, it is called simutrans-src-...zip

There is a configure script, and a readme too.

PkK

Quote from: prissi on September 26, 2013, 07:49:06 PM
There are source archieves on sourceforge for every stable, it is called simutrans-src-...zip

There is a configure script, and a readme too.

Stil I think it would be a good idea to make them more visible by libnking them from the forum in the same post that links to the binaries.

Philipp

gfurst

I plus one on this. I've recently tried a variety of simutrans versions and it was quite hard to do so.
I'm on a debian system so my first try was the easiest, but a couple of years behind the current version, it was still 111.
Secondly I tried the pre-compiled recent version which of course is 32-bit, this was not so hard to use, just installing 32bit libraries is enough, and its easy with multi-arch.
The last and hardest one was getting simutrans experimental, which has no pre-compiled version for linux, plus packed source file.
If not for @jamespett, I would be on my own to figure how to get the files and build it up.

I still think more documentation on building simutrans is required, specially since its about the best way to get something that really fits linux systems out there

sdog

It's not simutrans job to teach someone how to compile on linux. Anyone who can do that, is also capable (and used to do so) to click on the code link, go to sourceforge and get the sourcecode, read readme and makefile.

http://www.simutrans.com/en/develop#code
Quote
Simutrans is programmed in C++ programming language, and the current development stage source code can be obtained via subversion, git or zipped:

SVN: svn://tron.homeunix.org/simutrans/simutrans/ - Username: anon, No password
GIT: http://github.com/aburch/simutrans
ZIP/TGZ: http://github.com/aburch/simutrans/zipball/master

There are 64 bit builds of nightly versions on the server. However that's something we don't advertise so directly on the download page, as inexperienced users tend to download the latest, without having an idea that 'nightly' might also mean 'buggy'.


ps.:
I think naming the link to development 'contribute' is a misnomer, i'd look for 'develop...' on the page.

Ters

Quote from: gfurst on February 04, 2014, 04:56:22 PM
The last and hardest one was getting simutrans experimental, which has no pre-compiled version for linux, plus packed source file.
If not for @jamespett, I would be on my own to figure how to get the files and build it up.

Jamespetts is the founder and maintainer of Simutrans Experimental, so your criticizing and thanking the same person here, in case you didn't know.

But I find Simutrans quite easy to build on Linux. Sure, I'm a software developer by trade, but I have had troubles building more professional things than Simutrans. I don't have much faith that everybody should be able to compile software. Trying to compile Simutrans with mingw is much harder, but that's because mingw a neglected GCC host in general (Simutrans itself actually supports it reasonably well). However, I can see now that how to combine the base data files with the linked executable isn't apparent, but everything else appears to be covered in readme.txt.

Markohs

Simutrans nightlies have a gcc4 64 bit version as sdog said already, can't you use those? :)

http://simutrans-germany.com/~nightly/simutrans/en.html

prissi

If there are more wizards with configure scripts out there, a more simple linux source packed could be done. However, if you have no idea, how to build stuff then using the distributed version is the best choice.

Ters

There is a question of how well a fully automatic *nix build system would work for Simutrans. Even that relatively simple makefile we have often end up out of date when developers using MSVS forget to update it when adding/moving/deleting files. Manual steps are the same for everybody.

prissi

I though we are only discussing distribution of the stable, not the nightly?

Spacethingy

Quote from: PkK on September 26, 2013, 05:07:57 PMPlease provide source tarballs, information on how to get the source from the repository and quick instructions on building from source, as any project seriously targeting GNU/Linux users does.

For an open source game, the sources are kinda hidden on the download site, especially in comparison to other open source programs' sites. A fair bit Google/wiki searching is required to find them.
Life is like a Simutrans transformer:

You only get one of them, and you can't have it on a slope.

prissi

There is a readme and in the files section the sources of the stable.

So where do you suggest to put the sources (and which)?

sdog

#15
Quote from: Spacethingy on February 05, 2014, 10:53:37 AM
For an open source game, the sources are kinda hidden on the download site, especially in comparison to other open source programs' sites. A fair bit Google/wiki searching is required to find them.
The first three google hits for simutrans are when i search anonymously (no google profile):
simutrans on sourceforge
simutrans on wikipedia
simutans.com

Hit number five is simutrans on github. Simutrans com is most likely the least likely first point someone using linux would be visiting?


Edit:
I don't want to say we don't need to improve things, but "making it hard for linux users" is exaggerating it greatly. Perhaps it could be a bit clearer on the simutrans.com page where the sourcecode is. Contribute is neither unusual nor inadequate, but perhaps putting a link named 'source code' to the corresponding page 'code', which is already under 'contribute' into the 'download' tab might be a good idea. Even if it would be redundant.

Markohs

This can be solved adding in www.simutrans.com a sub-tab named "Get source code" to the "Download" menu. Or just expanding the "download" with more versions, I'd add linux 32-bit and 64-bit versions, with no dynamic libraries if possible, a MacOS X and a "Sourcecode" link to the github mirror or a .zip with the release code.

But this is just a suggestion, ofc. :)

gfurst

I have in my mind to do a comprehensive guide to build simutrans on linux, with the possibility of setting a local git repository.
I had to learn this because of simutrans-experimental, which at the moment is not able to distribute linux versions.
The nightly as mentioned above, is normally not suitable due to the possibility of really buggy and unfinished code, I'd think...
Oh, and its quite late now, but I'll definitely do the guide tomorrow.

prissi

For stable the official source (including all translations!) is on sourceforge. The svn (or the git mirror) contains only dummy texts.

The problem is rather to get the development tools for the many different platforms (and working and non-working gcc versions).

You typically need:
gcc-base (either 3.4.5 or try the latest)
g++
libc-devel
libSDL-devel
libpng-devel
bzlib2-devel (is usually under a strange name, which deviates from distributions to distribution)

If you want midi you need timidi and freepat, if memory serves me right.

Yona-TYT


I like the idea of a repository for simutrans.

Install simutrans using "yum install simutrans" would be very nice.. ;)

kierongreen

apt-get install simutrans works in debian and ubuntu - the problem is keeping the repositories up to date!

Yona-TYT

Quote from: kierongreen on February 06, 2014, 11:06:15 PM
apt-get install simutrans works in debian and ubuntu

Yes, but does not work in fedora. ::'(

Quote from: kierongreen on February 06, 2014, 11:06:15 PMthe problem is keeping the repositories up to date!

And who's in charge here? ???

kierongreen

Who is in charge of repositories? Distributions tend to have their own central repositories which developers can add packages to, however there are numerous hurdles to go through - not only do you have to package it in the right format, you have to show that your package won't conflict with others in the distribution. Some of those hurdles can be bypassed by having our own repositories, but then people would have to add these as a source. Either way, it needs someone who is willing to produce packages. This has been done in the past for Debian, however those are out of date currently.

sdog

One recommendation to comercial game designers is not to go that road. Rather distribute statically linked binary packages. Keeping packages for a few distributions up to date requires to be up to date with all those packages.

For FOSS it is of course easier. as someone involved with the distro might do it.
The original maintainer for simutrans' Debian package is Ansgar Burchardt. Now it's a bit behind 111.2
In Ubuntu it's the "MOTU Developers" which is a project to keep ubuntus non-canonical repositories up-to-date.

For Arch linux the maintainer is Balló György. He's pretty fast by the way with updates, last time i've noticed a new simutrans version in Arch's package manager pacman before i saw it on the forum. Balló György maitains 127 other packages as well, so it's not just a simutrans thing.*

An official Fedora package is sadly not possible, since they don't consider the Artistic License 1.0 as compatible [1].
Vilvoh and Ansgar have been in touch with the maintainer of OpenTTD on Fedora [2].

[1] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Bad_Licenses
[2] http://freegamer.blogspot.ca/2009/08/example-of-why-license-matters.html


*I've seen him on google+, shall i thank him for maintaining the package on behalf of simutrans?

prissi

Ansgar dates up quite frequently, but debian tends to do not allow for frequent updates.

How difficult is it to statically link the SDL?

And then there is still the 32 vs. 64 bit issue on Linux (and not to mention arm and PowerPC, where Debian is also there).

Ters

I don't think I've ever heard of statically linking SDL. Since it's 1.x is LGPL, I think the only legal way to do it is to license the entire product (in this case Simutrans) as LPGL (or GPL) as well. SDL 2.x uses a less restrictive license in that regard.

kierongreen

Debian installs simutrans fine on both arm and x86...

sdog

A pure 64 bit setup, ie no multilib, seems to be rare on desktops (that are also used for playing games). Perhaps a very clear list of dependencies might help?

Icculus (commercial porter to Linux):
"In a perfect world you want to link against C runtime and nothing else. Ship your own copy of SDL2 with your program and let it solve the rest."
He also claimed differences between distributions are a non existing problem.
https://icculus.org/SteamDevDays/SteamDevDays2014-LinuxPorting.pdf

I suppose for commercial projects larger downloads are much less if a problem than support.




prissi

Last time checked multilib was not working for the nightlies, or we or else we would not get regular error reports. libz and even libstdc were an issue (since GCC 4.x series), sometimes they are only LSD and GCC 3.4.5 and sometimes they were most recent gcc 4.x in 32 bit version.

Debian has build for almost any recent architekture, including MIPS. Aiming for the latest Unbutu on x64 only is relatively easy. But even in those cases static SDL will fail, if the sound system is a little bit more exotic.

sdog

#29
I have a pure 64 bit system here, since i don't play on this machine. Thus it's good for trying IA-32 simutrans binaries.

$file simutrans
simutrans: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=b0a596e4295c0e9a618061722835c3fc952f46ec, stripped


$file sim-gcc4
sim-gcc4: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

$ ./sim-gcc4
zsh: no such file or directory: ./sim-gcc4


On Ubuntu: install the ia32-libs package

Under arch:
Add multilib repository, by uncommenting it in /etc/pacman.conf, then update database with # pacman -Sy
get 32 bit glibc  # pacman -S lib32-glibc
Now the binary can be started, but it fails:

./sim-gcc4
./sim-gcc4: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

playing this game until all dependencies are met we find requirements for libz, bz2, sdl
#pacman -S lib32-zlib lib32-bzip2

But then comes sdl mixer, which is not in the official multilib repository (Arch specific). This is not a problem in ubuntu as far as i know. Arch's inofficial AUR repositories provide it, where one can easily build it for oneself (which i don't do at this point, as i only test something.)

Quote
Last time checked multilib was not working for the nightlies, or we or else we would not get regular error reports. libz and even libstdc were an issue (since GCC 4.x series), sometimes they are only LSD and GCC 3.4.5 and sometimes they were most recent gcc 4.x in 32 bit version.
I don't think i follow you here completely. What was the problem  here exaclty. Versions of the multilib/32bit libraries or their unavailability for certain distirbutions. (libz and libstdc are so fundamental, any multilib environment must have them in some form?)


ps.:
the repository in arch provides a 64 bit binary of the latest stable simutrans:

file /usr/bin/simutrans
/usr/bin/simutrans: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=1ed601c5616200c64ef952eeed1cf91c7663f853, stripped


pps.:
getting rid of multilib again on this machine, i've seen the dependencies of the three libraries installed before. Which were installed automatically byt the package manager:

sudo pacman -R  lib32-sdl lib32-zlib lib32-bzip2 lib32-glibc lib32-libxau lib32-libxdmcp  lib32-libxcb  lib32-libx11 lib32-libxext  lib32-libxrender

prissi

You know that the poeple who have problems with simutrans on linux are those who do not know how to use a command line (like ./simutrans on debian/ubuntu/... ), and also not the one who will easily find out how to install multilib.

Ters

It is my impression that installing things on Linux without help from a package manager requires some expertise. I think it might be part of, or a consequence of, the open source philosophy that dependencies should be installed seperately. Reasons might be license issues, the Filesystem Hierarchy Standard, and/or the idea that users should have the power to select which versions of the libraries to install. I know Blender is/was frowned upon by Gentoo for including dependencies.

On Windows, including dependencies is more common. However, this is often done by bundling a redistributable installation program, which won't install anything if an equal or newer version is already installed. On Linux, this responsability is usually given to the package manager, which varies between distros.

sdog

I've posted it for reference. Anyone who doesn't use the CLI wouldn't get arch installed in the first place.

Users who don't know how to use the command line, and don't have anyone doing their maintenance, are must likely only using a few distributions.

Most certainly Ubuntu. But what else? Fedora?

Suse and Red Hat are business distributions, not do likely used for games. Debian is perhaps an unlikely choice for beginners.


Mandriva/Mangeia?

Mint gets packages from Ubuntu, we're there.


Getting multilib is one of the first things one does, to get flash plugins working. There are plenty of explanations in the net. You can assume that nearly all have done this step. Exceptions are: (a) just installed and absolutely no clue. (b) use at workplato (c) nerd who has good reason not to

We can politely point (a) to a tutorial when they ask. Don't have to care about b and d.

@Ters: Of course simians ought not to bundle. Commercial just have pdifferent requirements.

Gentoo compiles everything from scratch, no binary distribution.  They frown on anything that's not gcc compilable code.

Ters

Quote from: sdog on February 08, 2014, 05:01:05 PM
Gentoo compiles everything from scratch, no binary distribution.  They frown on anything that's not gcc compilable code.

Blender actually has the dependencies bundled in the source code, so Gentoo had to hack its build system to remove them. Simutrans has done similar bundling with squirrel.

Yona-TYT

QuoteThe OSI has "superseded" the license, recommending strongly that all users move to Artistic 2.0


Why do not change to Artistic 2.0?