Compile issues with Windows 64-bit

[Junna]

I have trouble compiling (since a number of months ago) win64 version of the game (32 works still). It give 31 errors, LNK2005 and LNK2001, all referring to simsys_w.obj.

Error   1298   error LNK2005: main already defined in simsys_posix.obj   C:\simusrc 2\simsys_w.obj   Simutrans-Experimental
Error   1310   error LNK2005: "void __cdecl move_pointer(int,int)" (?move_pointer@@YAXHH@Z) already defined in simsys_posix.obj   C:\simusrc 2\simsys_w.obj

I assume I am missing some dependent library or include.

[jamespetts]

I have split this topic since this seemed to have nothing to do with industry connexion issues.

Is there a reason that you need a Windows 64-bit build? I use the 32-bit version on advice from the Standard developers (viz. that the code is optimised for the 32-bit version and cannot take advantage of the additional memory that 64-bit would theoretically allow in any event). I have not kept the 64-bit version up to date because of this.

[Junna]

Oh. No real reason, it just used to seem like it ran with a bit less lag than the 32bit, but that might have been circumstantial and unrelated to the build itself.

[jamespetts]

If anyone can demonstrate empirically that the 64-bit version performs better, I should be very interested indeed.

[TurfIt]

Error   1298   error LNK2005: main already defined in simsys_posix.obj   C:\simusrc 2\simsys_w.obj   Simutrans-Experimental
Error   1310   error LNK2005: "void __cdecl move_pointer(int,int)" (?move_pointer@@YAXHH@Z) already defined in simsys_posix.obj   C:\simusrc

You can't compile/link both the posix and GDI backends at the same time...

[DrSuperGood]

To elaborate what TurfIt said, you need to exclude the simsys_posix file from the build path so it is not compiled and linked. The simsys_w file is for the GDI backend which is one of the graphical backends. The simsys_posix file is for the command line (server) backend and requires that the entire project be set to POSIX. Like wise simsys_s and simsys_s2 are the SDL backends which also are mutually exclusive with simsys_w.

As for 64bit performance, it currently is less than with the 32bit build due to a number of factors. One factor is that Simutrans is reference/pointer heavy and using 64bit results in larger reference/pointer types which in turn need more memory bandwidth to process. Another factor is that the increase in pointer type size results in increases in object type sizes which in turn reduces the object capacity of the processor cache. Some of the code also incorrectly uses 32bit length types for pointer related manipulation instead of pointer length based types however such code could possibly be revised to be more correct. There has also been no effort made to specifically take advantage of 64bit features although the compiler will do a good job of using them when it can for overall speed increases.

[jamespetts]

Given that 64-bit versions are used extensively in Linux now (since the 32-bit versions will not work well there as in Windows), might it not be a good idea, I wonder, to give some thought to 64-bit optimisation?

[Vladki]

Do you have some spped test suite? I can try running it on linux 64/32 bit

[jamespetts]

I haven't a speed test suite, I am afraid. The best that I can manage is Linux profiling.

However, the problem with running the 32-bit Linux executable on a 64-bit Linux system is stability, not speed.

[DrSuperGood]

I thought Linux 64 would have no problem running 32 bit applications... Maybe the instability with 32bit on 64bit is a bug with Simutrans?

[jamespetts]

I thought Linux 64 would have no problem running 32 bit applications... Maybe the instability with 32bit on 64bit is a bug with Simutrans?

That is certainly possible, but I'd have no idea how to track that down.

[DrSuperGood]

That is certainly possible, but I'd have no idea how to track that down.

Well the basic idea would be to run a debug build and see where it eventually crashes. Even a non-debug build but with accompanying symbols could help limit down the scope of the crash. Or are you saying it is the OS itself that becomes unstable (a Linux bug)?

[jamespetts]

It didn't crash so much as demonstrate very weird behaviour in places that worked fine in the Windows 32-bit and Linux 64-bit. I cannot recall the details now as it was years ago that this occurred. I thought that this was a common issue with Linux?

[Vladki]

I thought that the only problem people had was the lack of 32-bit libs on 64-bit linux. Anyway I'll try running 32-bit simutrans on 64-bit linux