Author Topic: Command line server build issues  (Read 1304 times)

0 Members and 1 Guest are viewing this topic.

Offline DrSuperGood

Command line server build issues
« on: December 10, 2017, 02:42:27 AM »
Quote
I have also noticed the posix issues with Windows builds of the command line server: the game will instantly quit when started, with no error message
It likely only effects Standard when building with MSVC. It seems MSVC POSIX link system does not support the windows only UTF-16 Unicode aware API, throwing link errors as the implementations cannot be found. This means my recent drive for Unicode awareness has broken the ability to build POSIX servers in MSVC.

When trying to build a simple windowless server from the other back ends apparently the graphics code tries to access mutexes it should not (no graphics so no mutexes) so causes a segmentation fault unless built single threaded. This might only apply to standard.

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4372
  • Total likes: 242
  • Languages: EN, DE, AT
Re: Command line server build issues
« Reply #1 on: December 10, 2017, 12:04:40 PM »
When trying to build a simple windowless server from the other back ends apparently the graphics code tries to access mutexes it should not (no graphics so no mutexes) so causes a segmentation fault unless built single threaded. This might only apply to standard.
I cannot reproduce this for standard (compiling on linux, multithreaded server, no graphics - works).
Parsley, sage, rosemary, and maggikraut.

Offline DrSuperGood

Re: Command line server build issues
« Reply #2 on: December 10, 2017, 05:56:34 PM »
Quote
I cannot reproduce this for standard (compiling on linux, multithreaded server, no graphics - works).
Try building a GDI backend windowless server for Windows. The windowless server usually uses the POSIX backend but that is no longer supported by MSVC as its POSIX link system is not aware of Windows Unicode support.

Offline TurfIt

Re: Command line server build issues
« Reply #3 on: December 10, 2017, 06:36:31 PM »
GDI and windowless make no sense. POSIX is the windowless (graphicless really) backend, and as a backend is mutually exclusive with GDI as a backend. Also, color depth 0 is only compatible with the POSIX backend.
MinGW still works for a Windows command line server.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 17011
  • Total likes: 554
  • Country: gb
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Command line server build issues
« Reply #4 on: December 10, 2017, 09:26:45 PM »
I have split this topic from that relating to performance when connecting to Simutrans-Extended servers, as this is quite a separate issue. May I ask whether this should be moved to the bug reports subforum as being a Standard issue?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: Command line server build issues
« Reply #5 on: December 13, 2017, 08:14:59 AM »
This can be moved to standard bugs.

One simply builds the POSIX back end as a Windows console application, not link it as POSIX application. Linking as a POSIX application does not work as the POSIX libraries do not support the Windows only Unicode API, something that is not made clear anywhere. I recently patched in a fix in allowing MSVC to build it, it was missing some macros and imports.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 17011
  • Total likes: 554
  • Country: gb
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Command line server build issues
« Reply #6 on: December 13, 2017, 11:26:22 AM »
Thank you for this - I have now incorporated the fix into Extended.

However, I am still unable to get a working command line server build in Extended: any attempt to build a command line server executable (simgraph9.cc included, simgraph16.cc excluded; simsys_posix.cc included, simsys_w.cc excluded) results in an executable that will quit instantly with no error on being started: it prints no messages to the command line, and does not trigger the very first line of simu_main() in the debugger. I am afraid that this is beyond my understanding.

The ability to build a command line server executable in Windows will make it much easier for me to look into the problem relating to Extended load times on the servers.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Ters

Re: Command line server build issues
« Reply #7 on: December 13, 2017, 03:57:01 PM »
MSVC has a POSIX build options that is different from a Windows console application? I wasn't aware that the Windows NT offered POSIX support except through various POSIX subsystems, the current one being the Ubuntu-thingy, which are quite distinct from the Windows subsystem normally used.

Offline DrSuperGood

Re: Command line server build issues
« Reply #8 on: December 13, 2017, 06:26:55 PM »
Quote
MSVC has a POSIX build options that is different from a Windows console application?
It is a linker option.

Offline Ters

Re: Command line server build issues
« Reply #9 on: December 13, 2017, 07:45:14 PM »
It must be meant for easy porting or something, not for Simutrans which has code for Windows already. Headless Simutrans on Windows can run as just a regular console application. It doesn't need some POSIX compatibility stuff.

Offline DrSuperGood

Re: Command line server build issues
« Reply #10 on: December 13, 2017, 07:52:15 PM »
Quote
Headless Simutrans on Windows can run as just a regular console application. It doesn't need some POSIX compatibility stuff.
The backend file should really be renamed to "simsys_cl" (command line) rather than "simsys_posix" to avoid confusion.

Offline Ters

Re: Command line server build issues
« Reply #11 on: December 13, 2017, 08:42:26 PM »
I think "console" would be more understandable than "cl". Although I guess one could run it fully detached as a service as well.