News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Haiku 64bit: scenarios not working

Started by taosxx, June 20, 2015, 10:37:18 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

taosxx

Hi,

as you may remember, for years, there used to be a simutrans binary for Haiku/BeOS. Unfortunately, the latest revisions available as a compressed zip package from sourceforge run only on Haiku Alpha 4 but - probably since the introduction of package management - no longer on nightlies with package management. That's why I decided to try to write a recipe for haikuporter. This is a tool that downloads sourcecode, applies (if necessary) some haiku specific patches, compiles the code and puts everything in a neat little package ready to be installed on your haiku system (compare it to Gentoo Portage or Arch Linux's AUR). It worked quite well, both for 32 and 64 bit Haiku. The same is almost true for the two paksets I wrote recipes for - pak64 and pak128 (it downloads the already compiled zip archives not the source code). As far as I can tell everything works as expected on 32 bit systems, but the scenarios of pak128 don't seem to work on 64 bit: when trying to open a scenario, e.g. "swiss_mountains" all you see is an error message "Loading scenario script failed".

Is this something that also happens on other 64 bit systems or is this a problem only on Haiku 64 bit?

Ters

Simutrans doesn't really support being built as 64-bit executable. Being tailored for the 32-bit x86 architecture, it suffers from bad alignment and lack of optimization when the word size is changed. Although I've tried out 64-bit Simutrans in the past, and looked in to making it run at all, I have never tried out scenario scripts. There might be some assumptions in there about particular word sizes, such as pointer and integer being the same size, or even both 4 bytes. That might be true elsewhere in Simutrans as well, just that we haven't noticed, because sheer (un)luck prevents it from failing.

DrSuperGood

QuoteSimutrans doesn't really support being built as 64-bit executable.
Recent changes have tried to improve support for 64-bit builds. Performance is still worse than 32-bit but still moving towards the future having 64-bit support is something to aim for (even if they use the 32-bit builds).

I admit I never touched the scenario system when testing Windows 64-bit builds. Any particular example which crashes on "Haiku 64 bit" build?

prissi

A haiku build should be straightforward. The problem was rather getting GCC4 to work together with Allegro or SDL on Haiku (which why I gave up two years agon). I could compile a server, but I had trouble linking and backend. So I am happy to provider Haiku builds, if these trouble can be now overcome easily.

Having said that: That the scenarios are not working may be also connected with a specific version of GCC. When I was testing Haiku the last time, the GCC support was very much behind.

taos

#4
Quote from: DrSuperGood on June 20, 2015, 06:09:57 PM
I admit I never touched the scenario system when testing Windows 64-bit builds. Any particular example which crashes on "Haiku 64 bit" build?

It happens with all scenarios provided with pak128. It doesn't actually crash. It just shows an error message that can be closed, so that you go back to the game you played before trying to load a scenario. You can then load a saved game or just continue playing the game that's already running - you can just not load scanarios.




Quote from: prissi on June 20, 2015, 09:29:33 PM
Having said that: That the scenarios are not working may be also connected with a specific version of GCC. When I was testing Haiku the last time, the GCC support was very much behind.

The latest gcc4 package available for Haiku is gcc 4.8.4 from December 2014. It's the one used on pure GCC4 builds (e.g. x86_64) and hybrid builds (e.g. x86_gcc2 with secondary architecture x86 - that's the default also used for "stable" alpha revisions in order to have both binary compatibility with BeOS and access to more modern software requiring gcc4).

If you're interested in the (few) patches I had to use in order to make simutrans compile on recent nightlies (and play nice with haikuporter):
https://bitbucket.org/haikuports/haikuports/src/e1cefa27f6e007bf45a10c5e128769ccadcae094/games-simulation/simutrans/patches/simutrans-nightly.patchset?at=master (after the migration to GitHub: https://github.com/haikuports/haikuports/blob/81e676c333099357bdcd6da7b35ea79ab2437c9b/games-simulation/simutrans/patches/simutrans-nightly.patchset)

  • pthread is not a separate library in Haiku but included in libroot -> enables multithread
  • liblocale is nowadays no more than a link to libbe and only included for compatibility with BeOS (so not available for secondary architecture)
  • typedefs for uint32 and uint64 compete with definitions already in <SupportDefs.h>
  • minor: explicit setarch x86 wouldn't work on 64bit systems, choosing the correct compiler is handled by haikuporter automatically
There are still some issues (that don't prevent simutrans from compiling):

  • freetype2 seems available for Haiku but doesn't include what simutrans is looking for
  • sdl-config is available for Haiku but it seems that it is not found during configure step
Keep in mind that I'm not a programmer so I don't actually know what I'm doing. There are probably better solutions.




I think I got it working by first compiling makeobj in a way that makes it compatible with haikuporter and then building the whole pakset. Already tested for nightly pak64 pakset and I'm sure that this will also work for pak128 (I just don't have the time at the moment to adjust the recipe file, I'll do this in the evening).




Update: Yes, that works for pak128, too. I could open all scenarios on a Haiku x86_64 system. I'm going to open a pull request for the new recipes at haikuports.

taos

Pull requests have been merged in https://github.com/haikuports/haikuports/tree/master/ (haikuports recently migrated from Bitbucket to GitHub). Haikuporter can now generate pakset packages that include working scenarios for 64bit.

prissi

I could submit this also into the main repositiory, although it might generate a merge conflict then.

taos

Quote from: prissi on June 30, 2015, 09:39:06 PM
I could submit this also into the main repositiory, although it might generate a merge conflict then.

Are you referring to a merge conflict in simutrans when applying the patchsets for simutrans and makeobj (both are essentially the same)? Or a merge conflict when applying the patchsets in haikuporter after a change to the simutrans source code? If the patches got upstreamed it would only be necessary to remove one line in the recipes referring to "PATCHES" and create a new pull request at haikuports/haikuports.

I suppose that the patchsets could be applied without compromising building simutrans for other platforms (including pre-PM Haiku Alpha4). However, someone would have to check before applying them.
Regarding the format of the haikuporter patchsets, would it be better to fork aburch/simutrans on GitHub and send a pull request or maybe attach a "git format-patch" here? Or a patch for the svn repository?

Ters

Quote from: taos on July 01, 2015, 07:57:38 PM
Regarding the format of the haikuporter patchsets, would it be better to fork aburch/simutrans on GitHub and send a pull request or maybe attach a "git format-patch" here? Or a patch for the svn repository?

We use subversion, so whatever you do with Git is for yourself. Subversion patches are the way we accept changes, but it's possible prissi was thinking of just using the patches you already made and published. It even looks trivial enough to just do the changes manually.

taos

I've attached a "svn diff". I might be able to check this evening whether simutrans still compiles on Haiku Alpha4 after these changes (Alpha4 is 2.5 years old but still the latest "official" release).

prissi


taos

Thank you.

Haikuports recipes for simutrans-nightly and makeobj-nightly have been updated, patchsets have been removed.