Author Topic: Cross-compiling: Linux to Windows  (Read 9410 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Cross-compiling: Linux to Windows
« on: November 28, 2016, 01:33:38 AM »
I am in the process of setting up nightly builds for Simutrans-Experimental, using my Linux virtual server. I have managed to get it to work so far to produce Linux binaries and the paksets (see here), but I am having some trouble working out how to cross-compile for Windows, and I should be grateful for any help.

I have managed to download mingw-64 for Linux (apparently, this package includes both 32-bit and 64-bit cross-compiling build tools), but I cannot work out how to use them. All the tutorials that I can find are specific to pre-existing projects (e.g. how to cross-compile emacs), and rely on pre-written makefiles which, I assume, have already been configured to make use of mingw on Linux.

What I cannot find is:

(1) how to configure the makefile to use the mingw cross-compiler when a particular flag is set in the config file; and
(2) how to tell make to use something other than config.default (so that I can use a shell script to run Linux build and then a Windows build in the same code directory without having to maintain two separate directory structures just for different config.default files).

I should be very grateful indeed for any information on this. Thank you.
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 TurfIt

Re: Cross-compiling: Linux to Windows
« Reply #1 on: November 28, 2016, 02:31:07 AM »
(1) Why? Seems needlessly complicated. Normally just override the defaults with environment vars and stick your cross toolchain in the path before invoking make. e.g.
Code: [Select]
export CC=x86_64-w64-mingw32-gcc
export CXX=x86_64-w64-mingw32-g++
export PATH="/usr/x86_64-w64-mingw32/bin:$PATH"
(2) Env vars again. If using e.g. config.mingw, then set CFG=mingw. See first line of the Makefile...

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #2 on: November 28, 2016, 02:44:18 AM »
Thank you very much for that. I am rather new to cross-compiling or indeed doing anything other than basic building with the makefile; can you assist, therefore, as to what commands that I will actually need to issue in order to set up and use these environment variables to cross-compile? I presume that the code extract above is intended to go into the path, if not already there?
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #3 on: November 28, 2016, 06:12:52 AM »
(1) Why? Seems needlessly complicated. Normally just override the defaults with environment vars and stick your cross toolchain in the path before invoking make. e.g.
Code: [Select]
export CC=x86_64-w64-mingw32-gcc
export CXX=x86_64-w64-mingw32-g++
export PATH="/usr/x86_64-w64-mingw32/bin:$PATH"
(2) Env vars again. If using e.g. config.mingw, then set CFG=mingw. See first line of the Makefile...

In my experience, modifying PATH is not necessary. And I set CC and CXX in config.mingw (or whatever I call the relevant config.template copy). Then it's just a matter of CFG=mingw make to build Simutrans. Things may be different with the "new" autoconf(-like) set-up.

One also need to set up the dependencies (bzip and zlib if memory serves me right, optionally SDL) for cross-compilation. I don't remember how I did that, and it may be distro specific.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #4 on: November 28, 2016, 12:31:47 PM »
I did try simply setting the OS to mingw and running make, but that did not work.
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #5 on: November 28, 2016, 04:53:10 PM »
I did try simply setting the OS to mingw and running make, but that did not work.

If you are referring to OSTYPE, neither of us claimed that would be enough. (In fact, none of us even mentioned it, perhaps because we found it to be an obvious thing.) Otherwise, I have no idea what you mean by "setting the OS to mingw".

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #6 on: November 29, 2016, 09:13:55 PM »
Apologies for being unclear previously: I was using a smartphone on a train; yes, I did just change the OSTYPE to mingw (after having installed the cross-compiler). It failed with an error to the effect that it did not recognise "mingw" or something of the sort (I cannot recall the exact words now; I can check if this is important). What is not clear to me is how to instruct make to invoke, not the normal Linux G++, but the MinGW version, as I believe that, when I attempted to change it just by modifying the OSTYPE string, it did not do this.

You refer to a config.mingw file: do I understand this to be a file similar to config.default that provides the settings for a mingw build, whereas config.default provides the settings for the default Linux build? For some reason that I cannot fathom, I am having enormous difficulty in finding documentation on how to use make in this way. Do you happen to know of any?

Likewise, when you refer to "set[ting] CC and CXX in config.mingw", can you elaborate on what you mean by that? All the settings in config.default that I can identify are BACKEND, OSTYPE, DEBUG, OPTIMISE, PROFILE, VERBOSE, WITH_REVISION, MULTI_THREAD, WIN32_CONSOLE, BUILDDIR, MAKEOBJ_PROGDIR, NETTOOL_PROGDIR, PROGDIR and FLAGS. Are there other things that can be set, or do I need to set a specific flag?

Apologies for the somewhat basic level of these questions, but I am afraid that I have never cross-compiled before. Thank you very much for your help so far.
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #7 on: November 29, 2016, 09:23:36 PM »
you can write something like

CC=x86_64-w64-mingw32-gcc
CXX=x86_64-w64-mingw32-g++

into your config.default

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #8 on: November 30, 2016, 12:10:48 AM »
Thank you for that. How would I tell makeobj to use a config.mingw instead of config.default, or is the only way of doing this by renaming the files?
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 Vladki

Re: Cross-compiling: Linux to Windows
« Reply #9 on: November 30, 2016, 12:18:02 AM »
env CFG=whatever make

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #10 on: November 30, 2016, 12:30:47 AM »
That is very helpful, thank you.

Edit: I have made progress, but I am still having great difficulty. For the main executable, I am getting a compile error when trying to compile the line:

Code: [Select]
pthread_cleanup_pop(1);

The error given is:

Code: [Select]
error: second operand to the conditional operator is of type âvoidâ, but the third operand is neither a throw-expression nor of type âvoidâ
  pthread_cleanup_pop(1);

I do not understand why this line of code is generating an error, as pthread_cleanup_pop is a standard part of the pthreads library.

I can compile nettool without error (although I have not tried to run it), but when compiling makeobj, I get a linker error:

Code: [Select]
/usr/bin/i686-w64-mingw32-ld: cannot find -lz

This is despite me having zlib-devel installed:

Code: [Select]

root@438242:/usr/share/games/nightly/simutrans-experimental/makeobj# locate libz
/lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libz.so.1.2.8
/usr/lib/x86_64-linux-gnu/libz.a
/usr/lib/x86_64-linux-gnu/libz.so
/usr/lib32/libz.so.1
/usr/lib32/libz.so.1.2.8
/usr/src/linux-headers-4.4.0-45/zfs/lib/libzfs
/usr/src/linux-headers-4.4.0-45/zfs/lib/libzfs_core
/usr/src/linux-headers-4.4.0-45/zfs/lib/libzpool
/usr/src/linux-headers-4.4.0-45/zfs/lib/libzfs/Makefile.in
/usr/src/linux-headers-4.4.0-45/zfs/lib/libzfs_core/Makefile.in
/usr/src/linux-headers-4.4.0-45/zfs/lib/libzpool/Makefile.in
/usr/src/linux-headers-4.4.0-47/zfs/lib/libzfs
/usr/src/linux-headers-4.4.0-47/zfs/lib/libzfs_core
/usr/src/linux-headers-4.4.0-47/zfs/lib/libzpool
/usr/src/linux-headers-4.4.0-47/zfs/lib/libzfs/Makefile.in
/usr/src/linux-headers-4.4.0-47/zfs/lib/libzfs_core/Makefile.in
/usr/src/linux-headers-4.4.0-47/zfs/lib/libzpool/Makefile.in
/usr/x86_64-w64-mingw32/lib/libzoneoc.a

My config.mingw file so far looks like this:

Code: [Select]
#BACKEND = allegro
#BACKEND = gdi
#BACKEND = opengl
BACKEND = sdl
#BACKEND = sdl2
#BACKEND = mixer_sdl
#BACKEND = posix

#COLOUR_DEPTH = 0
COLOUR_DEPTH = 16

#OSTYPE = amiga
#OSTYPE = beos
#OSTYPE = cygwin
#OSTYPE = freebsd
#OSTYPE = haiku
#OSTYPE = linux
OSTYPE = mingw
#OSTYPE = mac

#DEBUG = 3    # Level 1-3, higher number means more debug-friendly, see Makefile
OPTIMISE = 1 # Add umpteen optimisation flags
#PROFILE = 1  # Enable profiling
#PROFILE = 2  # Enable profiling with optimisation flags, can be used with `OPTIMISE = 1'

#WITH_REVISION = 1 # adds the revision from svn; required for networkgames
# if you do not use SVN, add -DREVISION="1234" to the FLAGS below

#WIN32_CONSOLE = 1 # adds a console for windows debugging

MULTI_THREAD = 1 # Enable multithreading

# Define these as empty strings, if you don't have the respective config program
#ALLEGRO_CONFIG = allegro-config
#PNG_CONFIG     = pkg-config libpng
SDL_CONFIG     = sdl-config
#SDL2_CONFIG    = sdl2-config

#VERBOSE = 1

# The following useful conditional compilation flags exist
#
# Needed to compile:
# USE_C: no assembler for copying (required for not using GCC on x86)
# SIM_BIG_ENDIAN: MUST be set for PPC/Motorola byte order! (old mac, amiga)
# NO_INTPTR_T: must be set if intptr_t is not available
#
# Changing appearance:
# USE_SOFTPOINTER: emulate mouse pointer (set automatically in Makefile)
#
# Useful for debugging:
# DEBUG_ROUTES: show routing calculation information in minimap
# SHOW_FORE_GRUND: show which objects are drawn as foreground
# DEBUG_FLUSH_BUFFER: show the dirty areas on the screen
# USE_VALGRIND_MEMCHECK: make valgrind-memcheck aware of the memory allocation stuff in dataobj/freelist
# SYSLOG: send debug output to syslog
#
# Following flags alter game engine (and are off for standard builds)
# OTTD_LIKE: Enables half height tiles and crossconnects all industries
# AUTOMATIC_BRIDGES and AUTOMATIC_TUNNELS: will be built also for player
# AUTOJOIN_PUBLIC: stations next to a public stop will be joined to it
# USE_DIFFERENT_WIND: different airplane approach directions over the map
# DESTINATION_CITYCARS: Citycars can have a destination (enabled automatically - cannot be disabled)
#
# In order to use the flags, add a line like this: (-Dxxx)
# FLAGS = -DUSE_C

# Output directories:
#
# use this put objects file in same directory, where the sources are (not recommended):
# ... otherwise defaults to 'build/default')
#
# BUILDDIR = $(shell pwd)
#
# use this to specifiy the target directory for the executable:
# .. otherwise defaults to BUILDDIR
#
# MAKEOBJ_PROGDIR = $(shell pwd)
# NETTOOL_PROGDIR = $(shell pwd)
# PROGDIR  = $(shell pwd)

FLAGS = -fno-delete-null-pointer-checks -fno-strict-aliasing -std=c++11 -march=i686 -I/usr/share/games/nightly/simutrans-experimental/utils/openttd/ -I/usr/share/games/simutrans-experimental
# -I/usr/local/include -I/usr/include

LDFLAGE='-L/usr/lib32 -R/usr/lib32'

CC=i686-w64-mingw32-gcc
CXX=i686-w64-mingw32-g++

Any assistance with these issues would be much appreciated. Thank you all very much for your help so far.
« Last Edit: November 30, 2016, 01:39:18 AM by jamespetts »
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #11 on: November 30, 2016, 06:51:24 AM »
Code: [Select]
/usr/bin/i686-w64-mingw32-ld: cannot find -lz

This is despite me having zlib-devel installed:

I must have terrible communication skills. As I have already written: You must also have the dependencies for cross-compilation. Having zlib installed for Linux does not do any good when you are compiling for Windows. How this is done depends on what kind of Linux system you have, which you have not stated as far as I can see. (Well, I guess there is a generic solution, but bypassing the package manager makes it a pain to uninstall it later.)

Offline Vladki

Re: Cross-compiling: Linux to Windows
« Reply #12 on: November 30, 2016, 07:49:58 AM »
And perhaps doing make clean before compiling with different config should be done

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #13 on: November 30, 2016, 12:45:30 PM »
Thank you both for your replies, and apologies if I had not understood correctly earlier. I had searched extensively for solutions to the issue online specifically including the "mingw" keyword, and all of them referred to having zlib installed in the usual way.

To answer your question, the server runs Ubuntu 16.04 (presumably in a VM). Are the correct libraries to be found in the OpenTTD files?

I have already tried make clean, which has not helped (I think that this is automatic when switching configurations in any event).

Does anyone have any idea about the pthreads 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 Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #14 on: November 30, 2016, 04:14:03 PM »
For my x86_64-w64-mingw32 (on Windows, in case that matters), pthread_cleanup_pop is defined as

Code: (pthread.h) [Select]
#define pthread_cleanup_pop(E)\
    (*pthread_getclean() = _pthread_cup.next, ((E) ? (_pthread_cup.func((pthread_once_t *)_pthread_cup.arg)) : (void)0));}

That third argument is as void as it gets. Maybe this is broken in some other version. Or it's dragging in pthread for the wrong environment.

By the way, x86_64-w64-mingw32 means you are compiling 64-bit Windows executables. If you have both toolchains installed, and you want to target 32-bit Windows users as well, you must swap this out with i686-w64-mingw32.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #15 on: November 30, 2016, 09:37:07 PM »
Thank you for your reply. I am looking into the pthread issue, and I have noticed another include file error that may be causing that, which I am investigating.

In the meantime, I still cannot fathom what specific file that I need in the directory to which I point with the -L flag in config.mingw. I have pointed it to a directory containing zlibstat.lib and zdll.lib, and still get the same error. Those files (and all the others in that directory) come from the win32 subdirectory of the OpenTTD downloaded files.

As to 64 vs. 32 bit executables, I have modified the settings thus in config.mingw:

Code: [Select]

CC=i686-w64-mingw32-gcc
CXX=i686-w64-mingw32-g++

so as to get a 32-bit output.
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #16 on: November 30, 2016, 09:54:18 PM »
I think you may need also 64 bit libraries for the linking. So you need the same lib files as for your MSVC compiling. Look into the folder with the compiler. Close to it there should be also a lib and include folder. Specify these with -L and -I under LDFLAGS and CCFLAGS should point to the correct include and library folders.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #17 on: November 30, 2016, 10:57:09 PM »
If things are done correctly, no -L or -I should be required, because the correct files will be installed in the i686-w64-mingw32/x86_64-w64-mingw32 (or just mingw32 for the original mingw32) directories under /usr. This was very easy to do on Gentoo, probably because it installs things by building them from source, so installing cross-compile libraries is just a matter of building them with the cross-compiler. However, it took me a while to figure out the magic command(s) to run. While Googling cross-compilation gives lots of results, they are mostly just repeats of each other with a mix of sub-optimal solutions. I wouldn't be surprised if there is a good solution for Ubuntu, at least for such common libraries as zlib.

Offline TurfIt

Re: Cross-compiling: Linux to Windows
« Reply #18 on: November 30, 2016, 11:10:06 PM »
Latest devel-new-2 compile fails for me with the same pthread error.
I have
Code: [Select]
#define pthread_cleanup_pop(E)\
    (*pthread_getclean() = _pthread_cup.next, (E?_pthread_cup.func((pthread_once_t *)_pthread_cup.arg):0));}
Changing this to match Ters and then it compiles.

In the meantime, I still cannot fathom what specific file that I need in the directory to which I point with the -L flag in config.mingw.
-L flag. Why? Easier to just install the libs after you build them into the same prefix as you built the cross compiler with...
Just look at the output from gcc -v  to see where it's looking as configured.
Code: [Select]
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-5.3.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --with-gxx-include-dir=/mingw32/include/c++/5.3.0
...


I have pointed it to a directory containing zlibstat.lib and zdll.lib, and still get the same error. Those files (and all the others in that directory) come from the win32 subdirectory of the OpenTTD downloaded files.
eh?  .lib?  WTF sort of screwed up Unix system you running? Please don't say you're using GNU ld to link a Microsoft library...
OpenTTD? This is Simutrans forum.


Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #19 on: November 30, 2016, 11:23:25 PM »
Prissi

Since I am building for Win32, I do not think that I need 64-bit libraries, do I? I have already copied the files that I have in my Windows include and library directories to folders pointed to with -I and -L flags in the FLAGS= setting in config.mingw.

However, I am coming upon a problem of some complexity. If I do not add /usr/include manually by an -I/usr/include flag, I get the error that it cannot find iconv.h. The only copy of iconv.h is in /usr/include. However, when I include /usr/include, the version of pthread.h in there conflicts with the version that seems to be included by default with mingw in its own mingw include folder (which is included automatically without a flag), and the compiler then generates great numbers of error messages about redefinitions.

I did try copying just iconv.h from /usr/include to the Open TTD include directory, but had no success there, as I then had multiple compiler errors for things that were in turn referenced from iconv.h.

I am not sure what to do about this. Any help would be appreciated.

TurfIt

May I ask what compiler that you are using in which you are getting the pthread error? The thing that you are recommending to be changed is in a file supplied as part of the pthread module itself: it is not a Simutrans file. Is there an issue of incompatible pthreads versions, I wonder?

As to the libraries, may I ask what you mean when you refer to installing something into a prefix? gcc -v will surely give information about the Linux GCC/G++ compiler, rather than mingw? It has its own library and include directories, albeit ones that omit zlib (but have pthreads).

For reference, I get:

Code: [Select]

root@438242:/usr/share/games/nightly/simutrans-experimental/makeobj# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --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-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-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 --enable-multilib --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 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

As to the libraries, it seems that I need to understand better how libraries work given your comments. Do I infer from what you wrote that, even when cross-compiling for Windows, files with a .lib extension are not suitable for use with GCC? I presume from this that there is another sort of library file that is suitable, but I am not sure what sort of library file that it might be or where to get it.

In dealing with libraries in the past, I have, for Windows, downloaded the library files (usually with a .lib extension), put them in a folder, and told Visual Studio to find libraries in that folder. For Linux, I have just installed the relevant libxxx packages with apt (e.g. "apt-get install libpng-dev"), and the system itself has taken care of the files themselves and where they go, so I have never had to deal with the details of the files before.

For cross-compiling, I am not clear on what I need. Do I need Windows libraries (given that I am building for Windows), Linux libraries (given that I am building on Linux), or some sort of special cross-compile libraries (in which case, where can I find those)?

Please forgive me if this is a silly question: I am afraid that I have never tried any sort of cross-compiling before, so this is all new to me and the available documentation seems very scant.

In relation to Open TTD, the instructions for compiling Simutrans do specify using a lot of the libraries for Open TTD (especially zlib and libpng or their Windows equivalents), at least for Windows, and downloading the set of OpenTTD libraries is an explicit instruction on the "how to compile Simutrans" stickied post. Prissi said to use the same libraries on Linux for cross-compiling as I was using in Windows, which is why I copied the contents of the Open TTD libraries/include files folder.

Thank you all very much for your help so far.
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 TurfIt

Re: Cross-compiling: Linux to Windows
« Reply #20 on: December 01, 2016, 12:58:59 AM »
I'm using whatever version of MinGW-w64 comes with MSYS2 that I installed ~12 months ago. (nice if these things were versioned better....)
The pthread.h that came with appears faulty - same as the one you have. Ters has one that's better - no idea if his is newer and fixed, or older and ours got broke. If I change the macro to match Ters version, your code compiles.

With 'gcc -v', I thought obviously you would invoke your cross compiler, not native Ubuntu one. if 'i686-w64-mingw32-gcc' is it, then run that.

MSVC libraries are not compatible with GCC.  'Windows' != MSVC.

For cross-compiling, yes, you need cross-compile libraries. You need them built with the cross-compile tool chain. Most likely that means building them from source, using the cross compile, and ensuring the install into the cross tool chain directories - not the native machine ones. That appears to be possibly /usr/i686-w64-mingw32/{include/lib/etc...}, but the config printout from GCC should show you. I presume your cross came from some package manager, then maybe they have some cross libraries packaged too, but you'll most likely be building from scratch.

At no point do you want your Ubuntu include or lib dirs being used by the cross compiler. re: your iconv.h problem. If you have a dependency on libiconv, then you need it built with the cross toolchain and installed for those tools, same as all the other libraries.

I would suggest you take anything OTTD and delete it. And delete anything you've copied over from a Windows machine - like .libs. And delete anything you may have copied from Ubuntu into the MinGW paths. i.e. Probably start over.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #21 on: December 01, 2016, 06:37:37 AM »
If I do not add /usr/include manually by an -I/usr/include flag, I get the error that it cannot find iconv.h.

Get the system include directory the @#%& off your include path! Whatever your problem is, that is NOT the solution when cross-compiling!

MSVC libraries are not compatible with GCC.  'Windows' != MSVC.

For plain C, I seem to remember that .lib files can be used by GCC. They may have to specified explicitly, though. I don't think a normal -l will not find them. One can however link directly against the DLL (again, only plain C). I don't remember if -l will work in that case. (C++ uses different name mangling, which is why C++ libraries can't be shared by MSC++ and GCC.)

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4247
  • Total likes: 175
  • Helpful: 149
  • Languages: EN, DE, AT
Re: Cross-compiling: Linux to Windows
« Reply #22 on: December 01, 2016, 07:38:34 AM »
I use this http://mxe.cc/ for cross-compiling. It is very easy to install and configure.
Parsley, sage, rosemary, and maggikraut.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #23 on: December 01, 2016, 09:59:58 PM »
The also mention that Debian (and derived Ubuntu) needs

apt-get install g++-multilib libc6-dev-i386 libtool-bin

Without multilib you cannot link a 32 bit library with a 64 bit executable.

Ang mingw does fine with lib files. At least on windows, because even a DLL requires a .lib (or .a) file to link for the interface.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #24 on: December 02, 2016, 07:10:45 AM »
Without multilib you cannot link a 32 bit library with a 64 bit executable.

I thought that

  • multilib was for running 32-bit programs on 64-bit Linux, and has nothing to do with cross-compilation for Windows
  • It didn't link 32-bit libraries with 64-bit executables (nor vice versa), but provided 32-bit libraries for 32-bit applications on a 64-bit system and/or allowed 32-bit libraries to work with a 64-bit kernel

Ang mingw does fine with lib files. At least on windows, because even a DLL requires a .lib (or .a) file to link for the interface.

I seem to remember learning that it is possible to link using the DLL only in some limited cases, probably functions exported by name. The DLL should contain all information needed for that, as it's the same GetProcAddress needs. Exporting by ordinal was a thing of the previous century, and global variables are "bad" anyway.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #25 on: December 11, 2016, 10:40:11 PM »
Thank you very much for all your help, and apologies for not having replied sooner: I have been spending a great deal of time making multi-threading for passenger generation work in network mode.

Returning to where we left off, I see that there is some inconsistency in the responses as to whether I need to compile special cross-compile versions of the libraries, or whether I can use Windows .lib files.

However, before I can get to the stage of linking the code, I need to be able to compile it. The iconv.h issue is a compiling rather than a linking issue: i.e., a missing header file. Would I need to find a special cross-compile version of this header file? That would not make a great deal of sense, as this is source code. However, the iconv.h problem remains: there is no iconv.h file in the MinGW include directory, and I cannot use the iconv.h file in the Linux system include directory for the reasons given above.

Does anyone have any idea of what version of iconv.h that I might need, where I might find this version, whether it has further dependencies, and where I might find those?

Edit: I think that I have managed to find a suitable iconv.h here.

Edit 2: However, I now get a rather odd error when I try to run make:

Code: [Select]
===> LD  build/mingw/simutrans-experimental
build/mingw/simres.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/mingw/simutrans-experimental' failed
make: *** [build/mingw/simutrans-experimental] Error 1
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 TurfIt

Re: Cross-compiling: Linux to Windows
« Reply #26 on: December 11, 2016, 11:46:15 PM »
Edit: I think that I have managed to find a suitable iconv.h here.
How on earth did you end up there. Search for iconv or libiconv and first result: https://www.gnu.org/software/libiconv/
As with any other libraries you're missing, get them directly from the authors, and build/install them with the cross tools.


Edit 2: However, I now get a rather odd error when I try to run make:
Perhaps using Ubunutu ld rather than MinGW ld?  check paths...
I presume Ubunutu doesn't have a windres, but if it does, again make sure you invoke the MinGW version.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #27 on: December 12, 2016, 06:35:37 AM »
Perhaps using Ubunutu ld rather than MinGW ld?  check paths...
I presume Ubunutu doesn't have a windres, but if it does, again make sure you invoke the MinGW version.

Simutrans doesn't call ld directly, so it must be using the wrong compiler altogether in that case, or that compiler is internally inconsistent.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #28 on: December 12, 2016, 10:23:01 AM »
LD is the linker, is it not? This is called by make, surely, whenever anything is compiled? I assume that this must be the MinGW version of the linker. It would make no sense if the native Linux linker were called on a cross-compile build. How would one even go about changing which linker is used?
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #29 on: December 12, 2016, 04:14:03 PM »
Same as using CC/CXX for compiler only using LD.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #30 on: December 12, 2016, 04:14:09 PM »
LD is the linker, is it not? This is called by make, surely, whenever anything is compiled?

Yes, ld is the linker, but it is not, usually, called by make. Instead, make calls the main GCC program (gcc for C or g++ for C++), which in turn calls the preprocessor, compiler, assembler and/or linker depending on what input files it is given. Calling ld directly requires a bunch of parameters that the front-end adds for us.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #31 on: December 13, 2016, 12:49:01 AM »
Yes, ld is the linker, but it is not, usually, called by make. Instead, make calls the main GCC program (gcc for C or g++ for C++), which in turn calls the preprocessor, compiler, assembler and/or linker depending on what input files it is given. Calling ld directly requires a bunch of parameters that the front-end adds for us.

That makes sense - but would not that mean in turn that it is very unlikely indeed that the problem is the wrong linker being called?
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #32 on: December 13, 2016, 06:27:54 AM »
If you run objdump -f build/mingw/simres.o, what does it say? And what does objdump -f build/mingw/simmain.o say?

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #33 on: December 18, 2016, 09:32:54 AM »
Sorry for the delay. Output from objdump -f build/mingw/simres.o

Code: [Select]
file format pe-x86-64
architecture: i386:x86-64, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x0000000000000000

Output from  objdump -f build/mingw/simmain.o

Code: [Select]

build/mingw/simmain.o:     file format pe-i386
architecture: i386, flags 0x00000039:
HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x00000000

Does this help? Thank you very much for your assistance so far.
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #34 on: December 18, 2016, 09:45:34 AM »
simres.o has been built for 64-bit Windows and simmain.o has been built for 32-bit Windows. So both are cross-compiled, but you have still been mixing toolchains. I guess WINDRES must be set in config.<whatever> just like CC and CXX. It should be set to <prefix>-windres where prefix will be the same as used in <prefix>-g++. I'm a bit surprised it even found a windres without this being set.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #35 on: December 18, 2016, 11:09:14 AM »
Thank you very much for that: that is most helpful. The problem apparently was a bug in MinGW causing windres to default to 64-bit: I had to apply the fix here to make it work.

I now get this error on trying to build/link:

Code: [Select]
===> RES simres.rc
===> LD  build/mingw/simutrans-experimental
/usr/bin/i686-w64-mingw32-ld: cannot find -lpthreadGC2
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/mingw/simutrans-experimental' failed
make: *** [build/mingw/simutrans-experimental] Error 1

Edit: I have managed to fix that by replacing -lpthreadGC2 with -lpthread, but I now get this large set of linker errors:

Code: [Select]
===> LD  build/mingw/simutrans-experimental
build/mingw/besch/reader/image_reader.o:image_reader.cc:(.text+0x1bf): undefined reference to `adler32'
build/mingw/besch/reader/image_reader.o:image_reader.cc:(.text+0x1d8): undefined reference to `adler32'
build/mingw/boden/grund.o:grund.cc:(.text+0x9c6a): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/boden/grund.o:grund.cc:(.text+0xb91e): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x2398): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x24ab): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x25bc): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x43dc): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x43fc): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x46f2): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x4972): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/boden/wege/weg.o:weg.cc:(.text+0x5002): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0x49): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0x75): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0x96): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0xb3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0x16b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0x18e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/freelist.o:freelist.cc:(.text+0x19b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x28): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x77): undefined reference to `BZ2_bzWrite@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x87): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xad): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xee): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x11e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x12b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x138): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x147): undefined reference to `_imp__pthread_cond_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x190): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1e0): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x206): undefined reference to `gzwrite'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x23a): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x272): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3b2): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3c8): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3df): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3ec): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x40c): undefined reference to `_imp__pthread_join'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x412): undefined reference to `_imp__pthread_mutex_destroy'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x431): undefined reference to `_imp__pthread_barrier_destroy'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x46d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4f0): undefined reference to `_imp__pthread_barrier_init'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4f6): undefined reference to `_imp__pthread_mutex_init'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x52f): undefined reference to `_imp__pthread_attr_init'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x540): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x567): undefined reference to `_imp__pthread_create'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x570): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5c1): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5e2): undefined reference to `gzeof'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5f6): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x60f): undefined reference to `gzeof'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x62b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x75e): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x7dd): undefined reference to `gzwrite'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x80e): undefined reference to `BZ2_bzWrite@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x8be): undefined reference to `BZ2_bzReadClose@8'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x95d): undefined reference to `gzerror'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x986): undefined reference to `gzclose'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xa15): undefined reference to `BZ2_bzWriteClose@20'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xada): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xaf8): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xb0f): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xb1c): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xb44): undefined reference to `_imp__pthread_join'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xb4a): undefined reference to `_imp__pthread_mutex_destroy'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xb69): undefined reference to `_imp__pthread_barrier_destroy'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xc0b): undefined reference to `gzerror'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xc2f): undefined reference to `gzclose'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xcf6): undefined reference to `BZ2_bzReadClose@8'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xd61): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xdfd): undefined reference to `BZ2_bzWriteClose@20'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xeb4): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xedb): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xf0d): undefined reference to `BZ2_bzWrite@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0xf38): undefined reference to `gzwrite'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1019): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1026): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x104b): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1058): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x10ed): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x116e): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x11bd): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1243): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1250): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1275): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1282): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1363): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1370): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1395): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x13a2): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1458): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x14ad): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x14ed): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x151d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1537): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x15c2): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x15ee): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1617): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1647): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1704): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1711): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1736): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1743): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x184f): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x185c): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1881): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x188e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x197b): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1a67): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1aa1): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1acf): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1b4c): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1c24): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1c31): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1c56): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1c63): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1d53): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1d60): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1d85): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1d92): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1e98): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1eb9): undefined reference to `gzeof'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1ecb): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1f43): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1f50): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1f74): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1f50): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1f74): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x1f81): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2099): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x20f9): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x212d): undefined reference to `gzeof'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x21ab): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2207): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2251): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x228d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x22bd): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2384): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2391): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x23b6): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x23c3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2465): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x249d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x25c0): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2717): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2724): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2751): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x275e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x27cd): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2802): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x282c): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2948): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x296b): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2978): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x29a5): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x29b2): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2a41): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2aa3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2bf7): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2c20): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2c2d): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2c5a): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2c67): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2d39): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2d93): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x2f82): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x30ce): undefined reference to `BZ2_bzWrite@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x30f9): undefined reference to `gzwrite'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x310f): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x32f3): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3317): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3324): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3351): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x335e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x34b9): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3517): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x363d): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x366d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x367a): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x36a7): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x36b4): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x373d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3788): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x38d8): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x38e5): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3912): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x391f): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x398d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x39c2): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x39ec): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3b2c): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3b5d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3b6a): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3b97): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3ba4): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3c6d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3cb8): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3e4a): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x3ff2): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4045): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4052): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4077): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4084): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x42d3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4454): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4461): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4486): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4493): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x45cd): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x46ce): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4918): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4d94): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4da1): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4dce): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4ddb): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4e5d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4ec0): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x4ef2): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5097): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x50a4): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x50c9): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x50d6): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x516d): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x51b5): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x51c2): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x51e6): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x51f3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x52f8): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5305): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x532a): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5337): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x542c): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x54fe): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x557f): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x55b2): undefined reference to `gzread'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x55e1): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x564b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x569a): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x56e1): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5a26): undefined reference to `gzopen'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5a4e): undefined reference to `gzgets'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5bc4): undefined reference to `BZ2_bzReadOpen@24'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x5e95): undefined reference to `BZ2_bzRead@16'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x6113): undefined reference to `BZ2_bzWriteOpen@20'
build/mingw/dataobj/loadsave.o:loadsave.cc:(.text+0x641e): undefined reference to `gzopen'
build/mingw/dataobj/powernet.o:powernet.cc:(.text+0xee): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/powernet.o:powernet.cc:(.text+0x121): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/powernet.o:powernet.cc:(.text+0x20f): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/powernet.o:powernet.cc:(.text+0x249): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/dataobj/powernet.o:powernet.cc:(.text+0x2d5): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/dataobj/powernet.o:powernet.cc:(.text+0x30e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/bruecke.o:bruecke.cc:(.text+0x6f7): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/bruecke.o:bruecke.cc:(.text+0x80b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/bruecke.o:bruecke.cc:(.text+0x6f7): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/bruecke.o:bruecke.cc:(.text+0x80b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/bruecke.o:bruecke.cc:(.text+0x163c): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/bruecke.o:bruecke.cc:(.text+0x165c): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/crossing.o:crossing.cc:(.text+0x4b2): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/crossing.o:crossing.cc:(.text+0x4cc): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/crossing.o:crossing.cc:(.text+0x957): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/crossing.o:crossing.cc:(.text+0x97c): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/crossing.o:crossing.cc:(.text+0xcc0): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/crossing.o:crossing.cc:(.text+0xcda): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/crossing.o:crossing.cc:(.text$_ZN10crossing_t12check_seasonEb[__ZN10crossing_t12check_seasonEb]+0x3b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/crossing.o:crossing.cc:(.text$_ZN10crossing_t12check_seasonEb[__ZN10crossing_t12check_seasonEb]+0x55): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x194): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x19a): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x1cd): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x1d3): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x249): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x269): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x2002): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x2041): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x2061): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/gebaeude.o:gebaeude.cc:(.text+0x208f): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/label.o:label.cc:(.text+0x426): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/label.o:label.cc:(.text+0x4d5): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/leitung2.o:leitung2.cc:(.text+0x22eb): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/leitung2.o:leitung2.cc:(.text+0x2308): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/leitung2.o:leitung2.cc:(.text+0x25cf): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/leitung2.o:leitung2.cc:(.text+0x260b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/leitung2.o:leitung2.cc:(.text+0x282f): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/leitung2.o:leitung2.cc:(.text+0x286b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/roadsign.o:roadsign.cc:(.text+0x1325): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/obj/roadsign.o:roadsign.cc:(.text+0x1525): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/obj/roadsign.o:roadsign.cc:(.text+0x168d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/obj/tunnel.o:tunnel.cc:(.text+0x842): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/tunnel.o:tunnel.cc:(.text+0xbb9): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/wayobj.o:wayobj.cc:(.text+0x1d92): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/obj/wayobj.o:wayobj.cc:(.text+0x1e30): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/obj/wayobj.o:wayobj.cc:(.text+0x2033): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x2e8d): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x2edf): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x2f37): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x2f7a): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x3986): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x3d5e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x3d9b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x1214b): undefined reference to `_imp__pthread_mutex_init'
build/mingw/display/simgraph16.o:simgraph16.cc:(.text+0x126eb): undefined reference to `_imp__pthread_mutex_destroy'
build/mingw/display/simview.o:simview.cc:(.text+0x4d9): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simview.o:simview.cc:(.text+0x4e2): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/display/simview.o:simview.cc:(.text+0x4ee): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simview.o:simview.cc:(.text+0x703): undefined reference to `_imp__pthread_cond_wait'
build/mingw/display/simview.o:simview.cc:(.text+0xa41): undefined reference to `_imp__pthread_cond_wait'
build/mingw/display/simview.o:simview.cc:(.text+0xa9a): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simview.o:simview.cc:(.text+0xaa3): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/display/simview.o:simview.cc:(.text+0xaaf): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simview.o:simview.cc:(.text+0xac7): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/display/simview.o:simview.cc:(.text+0x12f2): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simview.o:simview.cc:(.text+0x1306): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/display/simview.o:simview.cc:(.text+0x1313): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simview.o:simview.cc:(.text+0x13d4): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simview.o:simview.cc:(.text+0x14f9): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/display/simview.o:simview.cc:(.text+0x1584): undefined reference to `_imp__pthread_cond_wait'
build/mingw/display/simview.o:simview.cc:(.text+0x164a): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/display/simview.o:simview.cc:(.text+0x1657): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/display/simview.o:simview.cc:(.text+0x168b): undefined reference to `_imp__pthread_cond_broadcast'
build/mingw/display/simview.o:simview.cc:(.text+0x1697): undefined reference to `_imp__pthread_cond_wait'
build/mingw/display/simview.o:simview.cc:(.text+0x19d6): undefined reference to `_imp__pthread_attr_init'
build/mingw/display/simview.o:simview.cc:(.text+0x19e7): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/display/simview.o:simview.cc:(.text+0x19f4): undefined reference to `_imp__pthread_barrier_init'
build/mingw/display/simview.o:simview.cc:(.text+0x1a70): undefined reference to `_imp__pthread_create'
build/mingw/display/simview.o:simview.cc:(.text+0x1b50): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/display/simview.o:simview.cc:(.text+0x211b): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/player/simplay.o:simplay.cc:(.text+0x20b4): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x20e8): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x379e): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x37d5): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3828): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x385f): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3bba): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3bf1): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3c3b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3c72): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3cb7): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3cef): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3ed1): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/player/simplay.o:simplay.cc:(.text+0x3f08): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0x1f53): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0x7bbf): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0x7c19): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0x9d45): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0x9d85): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xa26f): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xa2a3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xa5f5): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xa635): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xbef5): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xeabe): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xeb6a): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xec26): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simconvoi.o:simconvoi.cc:(.text+0xecf4): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xc6f0): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xc75f): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xc873): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xc880): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xcbc6): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xd620): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xd640): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simhalt.o:simhalt.cc:(.text+0xd829): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simtool.o:simtool.cc:(.text+0x8a99): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x3e): undefined reference to `_imp__sem_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x7f): undefined reference to `_imp__sem_post'
build/mingw/simworld.o:simworld.cc:(.text+0xac): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0xc3): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x31d): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0x332): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x36d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x397): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x3a3): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x3a9): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x437): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x454): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x534): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0xbb3): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0xbbc): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0xbc2): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0xbc8): undefined reference to `_imp__pthread_cond_signal'
build/mingw/simworld.o:simworld.cc:(.text+0xc58): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0xbc8): undefined reference to `_imp__pthread_cond_signal'
build/mingw/simworld.o:simworld.cc:(.text+0xc58): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0x1513): undefined reference to `_imp__pthread_attr_init'
build/mingw/simworld.o:simworld.cc:(.text+0x1524): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/simworld.o:simworld.cc:(.text+0x1531): undefined reference to `_imp__pthread_barrier_init'
build/mingw/simworld.o:simworld.cc:(.text+0x158c): undefined reference to `_imp__pthread_create'
build/mingw/simworld.o:simworld.cc:(.text+0x15b4): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x15ba): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x1743): undefined reference to `_imp__sem_init'
build/mingw/simworld.o:simworld.cc:(.text+0x1772): undefined reference to `_imp__pthread_attr_init'
build/mingw/simworld.o:simworld.cc:(.text+0x1783): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/simworld.o:simworld.cc:(.text+0x1790): undefined reference to `_imp__pthread_barrier_init'
build/mingw/simworld.o:simworld.cc:(.text+0x17eb): undefined reference to `_imp__pthread_create'
build/mingw/simworld.o:simworld.cc:(.text+0x1817): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x181d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x185c): undefined reference to `_imp__sem_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x1914): undefined reference to `_imp__ptw32_push_cleanup'
build/mingw/simworld.o:simworld.cc:(.text+0x1925): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x198b): undefined reference to `_imp__ptw32_pop_cleanup'
build/mingw/simworld.o:simworld.cc:(.text+0x1998): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0x19ec): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x1ab9): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x1ac6): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x1ae6): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x1b00): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0x31bf): undefined reference to `_imp__sem_init'
build/mingw/simworld.o:simworld.cc:(.text+0x3274): undefined reference to `_imp__pthread_attr_init'
build/mingw/simworld.o:simworld.cc:(.text+0x3285): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/simworld.o:simworld.cc:(.text+0x3292): undefined reference to `_imp__pthread_barrier_init'
build/mingw/simworld.o:simworld.cc:(.text+0x32ed): undefined reference to `_imp__pthread_create'
build/mingw/simworld.o:simworld.cc:(.text+0x3319): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x331f): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x33a2): undefined reference to `_imp__sem_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x551c): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x5532): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x5551): undefined reference to `_imp__pthread_cond_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x555e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x557d): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x5583): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x55a2): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x5712): undefined reference to `_imp__pthread_attr_init'
build/mingw/simworld.o:simworld.cc:(.text+0x5727): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/simworld.o:simworld.cc:(.text+0x5731): undefined reference to `_imp__pthread_barrier_init'
build/mingw/simworld.o:simworld.cc:(.text+0x57ce): undefined reference to `_imp__pthread_create'
build/mingw/simworld.o:simworld.cc:(.text+0x5cf4): undefined reference to `_imp__pthread_create'
build/mingw/simworld.o:simworld.cc:(.text+0x5f67): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x5f6d): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x5fa7): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x5fc6): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x5fd7): undefined reference to `_imp__pthread_join'
build/mingw/simworld.o:simworld.cc:(.text+0x6100): undefined reference to `_imp__pthread_barrier_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x6158): undefined reference to `_imp__pthread_join'
build/mingw/simworld.o:simworld.cc:(.text+0x1184a): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x11880): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x1260b): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x127a5): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x127cf): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x12d42): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x13962): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x13ad1): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x13b8e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x13dfc): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x13e32): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x14280): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x1429e): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x142b0): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x142ce): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x14629): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x14762): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x1476f): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x1479b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x147a8): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x147c7): undefined reference to `_imp__pthread_exit'
build/mingw/simworld.o:simworld.cc:(.text+0x2bc28): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x2bc4d): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x2cb39): undefined reference to `_imp__pthread_attr_init'
build/mingw/simworld.o:simworld.cc:(.text+0x2cb50): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/simworld.o:simworld.cc:(.text+0x2cb6f): undefined reference to `_imp__pthread_barrier_init'
build/mingw/simworld.o:simworld.cc:(.text+0x2cbfb): undefined reference to `_imp__pthread_create'
build/mingw/simworld.o:simworld.cc:(.text+0x2cc4c): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/simworld.o:simworld.cc:(.text+0x2cc51): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x2d12e): undefined reference to `_imp__pthread_cond_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x2d13b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x307d4): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x307f8): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x3177a): undefined reference to `_imp__pthread_cond_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x31787): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x32e20): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x32e3b): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x33023): undefined reference to `_imp__pthread_cond_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x33030): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x33242): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x332da): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simworld.o:simworld.cc:(.text+0x332fc): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x3413c): undefined reference to `_imp__pthread_cond_wait'
build/mingw/simworld.o:simworld.cc:(.text+0x34141): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simworld.o:simworld.cc:(.text+0x34255): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x8): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xe): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x14): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x52): undefined reference to `SDL_UnlockSurface'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x5f): undefined reference to `SDL_Flip'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x6c): undefined reference to `SDL_LockSurface'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x9c): undefined reference to `SDL_PollEvent'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xbc): undefined reference to `SDL_WaitEvent'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xc8): undefined reference to `SDL_PollEvent'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x217): undefined reference to `SDL_GetModState'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x24b): undefined reference to `SDL_GetModState'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x28e): undefined reference to `SDL_GetMouseState'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x2cd): undefined reference to `SDL_GetModState'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x310): undefined reference to `SDL_GetMouseState'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x5d0): undefined reference to `SDL_Init'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x5ef): undefined reference to `SDL_Quit'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x612): undefined reference to `SDL_GetError'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x644): undefined reference to `SDL_GetVideoInfo'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x687): undefined reference to `_imp__pthread_barrier_init'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x690): undefined reference to `_imp__pthread_attr_init'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x6a1): undefined reference to `_imp__pthread_attr_setdetachstate'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x6c9): undefined reference to `_imp__pthread_create'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x6dc): undefined reference to `_imp__pthread_attr_destroy'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x73c): undefined reference to `SDL_putenv'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x75b): undefined reference to `SDL_SetVideoMode'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x76c): undefined reference to `SDL_putenv'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x783): undefined reference to `SDL_GetVideoInfo'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x795): undefined reference to `SDL_VideoDriverName'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x847): undefined reference to `SDL_EnableUNICODE'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x85b): undefined reference to `SDL_EnableKeyRepeat'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x847): undefined reference to `SDL_EnableUNICODE'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x85b): undefined reference to `SDL_EnableKeyRepeat'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x86f): undefined reference to `SDL_WM_SetCaption'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x87b): undefined reference to `SDL_ShowCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x880): undefined reference to `SDL_GetCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x8b9): undefined reference to `SDL_CreateCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x8f2): undefined reference to `SDL_CreateCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x903): undefined reference to `SDL_ShowCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x951): undefined reference to `SDL_GetError'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x98c): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x999): undefined reference to `SDL_FreeCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x9a6): undefined reference to `SDL_FreeCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0x9c7): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xa20): undefined reference to `SDL_SetVideoMode'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xa65): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xa89): undefined reference to `SDL_UnlockSurface'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xade): undefined reference to `SDL_LockSurface'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xb1a): undefined reference to `SDL_MapRGB'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xb3c): undefined reference to `_imp__pthread_mutex_lock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xb5c): undefined reference to `_imp__pthread_mutex_unlock'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xb69): undefined reference to `_imp__pthread_barrier_wait'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xbd7): undefined reference to `SDL_UpdateRect'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xc9c): undefined reference to `SDL_RWFromFile'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xca3): undefined reference to `SDL_GetVideoSurface'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xcb7): undefined reference to `SDL_SaveBMP_RW'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xc03): undefined reference to `SDL_WarpMouse'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xc27): undefined reference to `SDL_SetCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xd17): undefined reference to `SDL_SetCursor'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xd21): undefined reference to `SDL_PumpEvents'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xd31): undefined reference to `SDL_GetTicks'
build/mingw/simsys_s.o:simsys_s.cc:(.text+0xd41): undefined reference to `SDL_Delay'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0xe1): undefined reference to `SDL_MixAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x10e): undefined reference to `SDL_MixAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x13e): undefined reference to `SDL_MixAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x16e): undefined reference to `SDL_MixAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x1b2): undefined reference to `SDL_InitSubSystem'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x202): undefined reference to `SDL_OpenAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x227): undefined reference to `SDL_CloseAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x233): undefined reference to `SDL_QuitSubSystem'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x279): undefined reference to `SDL_PauseAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x2a4): undefined reference to `SDL_QuitSubSystem'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x2e5): undefined reference to `SDL_RWFromFile'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x30d): undefined reference to `SDL_LoadWAV_RW'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x35a): undefined reference to `SDL_BuildAudioCVT'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x39f): undefined reference to `SDL_FreeWAV'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x3a7): undefined reference to `SDL_ConvertAudio'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x409): undefined reference to `SDL_FreeWAV'
build/mingw/sound/sdl_sound.o:sdl_sound.cc:(.text+0x441): undefined reference to `SDL_GetError'
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/mingw/simutrans-experimental' failed
make: *** [build/mingw/simutrans-experimental] Error 1
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 TurfIt

Re: Cross-compiling: Linux to Windows
« Reply #36 on: December 18, 2016, 07:39:13 PM »
If your cross is setup the same as the MSYS2 version on Windows, -lpthreadGC2 can simply be removed, now builtin.
For the rest, you didn't install the dependent libraries - bzip2, zlib, SDL... One wonders how it even compiled without the headers even...

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #37 on: December 18, 2016, 08:34:22 PM »
The headers are definitely there and the libraries are installed - but I suspect that they are not cross-compile specific libraries, which might be the issue. The trouble is that I am not sure how to build a cross-compile specific version of pthreads, bzlib, zlib, libpng, etc.; Simutrans already has a mingw setup and a specific setting in the config.template so that I can make a config.mingw quite easily, but I do not know how this might be accomplished with these libraries (and the libraries on which, in turn, those libraries depend, potentially ad infinitum thereafter).
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #38 on: December 18, 2016, 09:29:25 PM »
If you just dump files found at random, you are playing roulette.

bzip and zlib are fundamental libraries and don't depend on anything but the C runtime. libpng might depend on zlib, I don't remember, and possibly only needed for makeobj. I would advise building with the GDI backend, so that you don't need SDL, at least for a first try.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #39 on: December 18, 2016, 11:39:52 PM »
Thank you for the suggestion of switching to a GDI build. I have done that. Instead of the very lengthy output that I get above, I only get these linker errors when I try to compile it:

Code: [Select]
===> RES simres.rc
===> LD  build/mingw/simutrans-experimental
/usr/bin/i686-w64-mingw32-ld: cannot find -lbz2
/usr/bin/i686-w64-mingw32-ld: cannot find -lz
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/mingw/simutrans-experimental' failed
make: *** [build/mingw/simutrans-experimental] Error 1

This looks like a problem with the libz and bzlib libraries. Has anyone any idea how to cross-compile those or find cross-compile compatible binary versions of them?
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 jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #40 on: January 14, 2017, 03:19:49 PM »
I have now managed to compile cross-compiled versions of bzlib and zlib and these now appear to link correctly. However, I am now getting linker errors relating to pthreads - not the sort of linker error that I should expect if a cross-compile version of pthreads was missing entirely, but this error:

Code: [Select]

root@438242:/usr/share/games/nightly/simutrans-experimental# env CFG=mingw make -j5
===> LD  build/mingw/simutrans-experimental
build/mingw/simworld.o:simworld.cc:(.text+0x1914): undefined reference to `_imp__ptw32_push_cleanup'
build/mingw/simworld.o:simworld.cc:(.text+0x198b): undefined reference to `_imp__ptw32_pop_cleanup'
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/mingw/simutrans-experimental' failed
make: *** [build/mingw/simutrans-experimental] Error 1

This seems to be a problem relating to the old cleanup push/pop functions that gave compile errors some time ago. I wonder whether the pthreads library is out of date?

Edit: I have attempted, but failed, to compile pthreads using mingw: the step of applying the patch documented here fails with error messages that give no information whatsoever as to the nature of the problem. Obtaining an alternative binary for mingw and putting that in the relevant library directory makes no difference to the original failure. I really do not know how to make any progress from here - the nature of the problem is totally obscure. Any help would be very much appreciated indeed.
« Last Edit: January 14, 2017, 04:22:57 PM by jamespetts »
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #41 on: January 14, 2017, 09:23:14 PM »
Some builds of mingw64 come with pthreads included, to make std::thread work. For some reason, my Windows install of mingw64 (from MSYS2) is a pthread build, while my Linux install (from the distro repo) is a w32thread build (it does have three pthread headers, though, but no lib).

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #42 on: January 14, 2017, 09:24:50 PM »
Yes, indeed, it does have pthreads included - but it does not work as it seems to be different from the standard version in weird ways.
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 Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4247
  • Total likes: 175
  • Helpful: 149
  • Languages: EN, DE, AT
Re: Cross-compiling: Linux to Windows
« Reply #43 on: January 15, 2017, 10:23:22 AM »
I use this http://mxe.cc/ for cross-compiling. It is very easy to install and configure.

Let me advocate again this cross-compiling tool based on mingw. It handles all the libraries for you. After installing, all I had to do was to call
Code: [Select]
make gcc bzip2 zlib pthreads
in mxe directory to install required libraries. Then create a symlink from libpthread.a to libpthreadGC2.a, create a new config.* for simutrans compiling. Then fire up make to compile simutrans. It cannot be easier than this.
Parsley, sage, rosemary, and maggikraut.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #44 on: January 16, 2017, 12:14:22 AM »
Thank you for that suggestion. I have just tried installing/building MXE, but unfortunately, the process fails with the following errors:

Code: [Select]
Failed to build package hyperscan for target i686-w64-mingw32.static!
------------------------------------------------------------
-- Configuring incomplete, errors occurred!
See also "/usr/share/mxe/mxe/tmp-hyperscan-i686-w64-mingw32.static/hyperscan-4.3.2.build/CMakeFiles/CMakeOutput.log".
See also "/usr/share/mxe/mxe/tmp-hyperscan-i686-w64-mingw32.static/hyperscan-4.3.2.build/CMakeFiles/CMakeError.log".
Makefile:598: recipe for target 'build-only-hyperscan_i686-w64-mingw32.static' failed
make[1]: *** [build-only-hyperscan_i686-w64-mingw32.static] Error 1
make[1]: Leaving directory '/usr/share/mxe/mxe'
real    0m18.328s
user    0m10.812s
sys     0m1.136s
------------------------------------------------------------
[log]      /usr/share/mxe/mxe/log/hyperscan_i686-w64-mingw32.static

Makefile:598: recipe for target '/usr/share/mxe/mxe/usr/i686-w64-mingw32.static/installed/hyperscan' failed
make: *** [/usr/share/mxe/mxe/usr/i686-w64-mingw32.static/installed/hyperscan] Error 1
make: *** Waiting for unfinished jobs....
[done]      jansson                  i686-w64-mingw32.static                               4496 KiB       0m25.129s
[done]      hdf-eos5                 i686-w64-mingw32.static                               34212 KiB      0m49.089s
[done]      id3lib                   i686-w64-mingw32.static                               12856 KiB      0m41.650s
[done]      json_spirit              i686-w64-mingw32.static                               38356 KiB      1m40.389s
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 jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #45 on: February 01, 2017, 12:35:21 AM »
I have had another go at making this work by modifying the code so as no longer to use pthread_cleanup_push and pthread_cleanup_pop. I am now able to get it to compile and link.

However, the resulting executable (here) fails to run with the error:

Code: [Select]
The application was unable to start correctly (0xc000007b). Click OK to close the application.

The size of the executable is 7,708kb, suggesting that the problem is that, despite the linker command having succeeded, it has not linked all of its libraries. My config.mingw file is as follows:

Code: [Select]
#
# to compile:
# copy this file to config.default and adjust the settings
#

#BACKEND = allegro
BACKEND = gdi
#BACKEND = opengl
#BACKEND = sdl
#BACKEND = sdl2
#BACKEND = mixer_sdl
#BACKEND = posix

#COLOUR_DEPTH = 0
COLOUR_DEPTH = 16

#OSTYPE = amiga
#OSTYPE = beos
#OSTYPE = cygwin
#OSTYPE = freebsd
#OSTYPE = haiku
#OSTYPE = linux
OSTYPE = mingw
#OSTYPE = mac

#DEBUG = 3    # Level 1-3, higher number means more debug-friendly, see Makefile
OPTIMISE = 3  # Add umpteen optimisation flags
#PROFILE = 1  # Enable profiling
#PROFILE = 2  # Enable profiling with optimisation flags, can be used with `OPTIMISE = 1'

WITH_REVISION = 1 # adds the revision from svn; required for networkgames
# if you do not use SVN, add -DREVISION="1234" to the FLAGS below

#WIN32_CONSOLE = 1 # adds a console for windows debugging

MULTI_THREAD = 1 # Enable multithreading

# Define these as empty strings, if you don't have the respective config program
#ALLEGRO_CONFIG = allegro-config
#PNG_CONFIG     = pkg-config libpng
SDL_CONFIG     = sdl-config
#SDL2_CONFIG    = sdl2-config

#VERBOSE = 1

# The following useful conditional compilation flags exist
#
# Needed to compile:
# USE_C: no assembler for copying (required for not using GCC on x86)
# SIM_BIG_ENDIAN: MUST be set for PPC/Motorola byte order! (old mac, amiga)
# NO_INTPTR_T: must be set if intptr_t is not available
#
# Changing appearance:
# USE_SOFTPOINTER: emulate mouse pointer (set automatically in Makefile)
#
# Useful for debugging:
# DEBUG_ROUTES: show routing calculation information in minimap
# SHOW_FORE_GRUND: show which objects are drawn as foreground
# DEBUG_FLUSH_BUFFER: show the dirty areas on the screen
# USE_VALGRIND_MEMCHECK: make valgrind-memcheck aware of the memory allocation stuff in dataobj/freelist
# SYSLOG: send debug output to syslog
#
# Following flags alter game engine (and are off for standard builds)
# OTTD_LIKE: Enables half height tiles and crossconnects all industries
# AUTOMATIC_BRIDGES and AUTOMATIC_TUNNELS: will be built also for player
# AUTOJOIN_PUBLIC: stations next to a public stop will be joined to it
# USE_DIFFERENT_WIND: different airplane approach directions over the map
# DESTINATION_CITYCARS: Citycars can have a destination (enabled automatically - cannot be disabled)
#
# In order to use the flags, add a line like this: (-Dxxx)
# FLAGS = -DUSE_C

# Output directories:
#
# use this put objects file in same directory, where the sources are (not recommended):
# ... otherwise defaults to 'build/default')
#
# BUILDDIR = $(shell pwd)
#
# use this to specifiy the target directory for the executable:
# .. otherwise defaults to BUILDDIR
#
# MAKEOBJ_PROGDIR = $(shell pwd)
# NETTOOL_PROGDIR = $(shell pwd)
# PROGDIR  = $(shell pwd)

FLAGS = -fno-delete-null-pointer-checks -fno-strict-aliasing -std=c++11 -L/usr/share/games/nightly/simutrans-experimental/utils/openttd/lib -I/usr/share/games/nightly/simutrans-experimental/utils/openttd/ -L/root/zlib-source/zlib-1.2.10/zlib-1.2.10 -L/root/bzip2-1.0.6

LDFLAGS = -L/usr/share/games/nightly/simutrans-experimental/utils/openttd/lib -L/root/bzip2-1.0.6

# -I/usr/lib/gcc/i686-w64-mingw32/5.3-win32/include/c++/parallel/

# -I/usr/lib/gcc/i686-w64-mingw32/5.3-win32/include/c++/parallel/

# -I/usr/share/games/nightly/simutrans-experimental/utils/openttd/

CC=i686-w64-mingw32-gcc
CXX=i686-w64-mingw32-g++

Am I missing something - do I need to be even more explicit somewhere/somehow about what libraries to link than I already have been? Any assistance would be much appreciated.

Edit: The same occurs when specifying SDL2 in the config.mingw option. Do I need to specify the SDL libraries manually...?
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 HaydenRead

Re: Cross-compiling: Linux to Windows
« Reply #46 on: February 01, 2017, 03:21:47 AM »
First thing I notice is you have
BACKEND = gdi

And

SDL_CONFIG = sdl_config

Not sure if this would create a problem, but surely SDL_CONFIG line should be commented out if using gdi

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #47 on: February 01, 2017, 06:34:33 AM »
First thing I notice is you have
BACKEND = gdi

And

SDL_CONFIG = sdl_config

Not sure if this would create a problem, but surely SDL_CONFIG line should be commented out if using gdi

No, that's not needed. In fact, they are there to override the defaults, but in this case, they are just overridden to the same value. And if anything, it would have cause more libraries to be linked, not less.

Edit: The same occurs when specifying SDL2 in the config.mingw option. Do I need to specify the SDL libraries manually...?

If sdl-config is not working, then you have to do that. Or rather, the makefile does have defaults that worked for me, but on the condition that SDL_CONFIG is set to empty (which is different from not set at all).

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #48 on: February 01, 2017, 08:14:39 AM »
Empty as in SDL_CONFIG     =

....?
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 An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2592
  • Total likes: 289
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Cross-compiling: Linux to Windows
« Reply #49 on: February 01, 2017, 02:46:46 PM »
Or commented with #

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #50 on: February 01, 2017, 02:56:46 PM »
Should the #be before or after the SDL_CONFIG?
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #51 on: February 01, 2017, 09:18:01 PM »
Or commented with #

No, that would trigger the default value, which is not nothing.

Offline Vladki

Re: Cross-compiling: Linux to Windows
« Reply #52 on: February 01, 2017, 10:03:48 PM »
Should the #be before or after the SDL_CONFIG?
Before.




Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #53 on: February 02, 2017, 12:20:22 AM »
Thank you for that: I am afraid that setting SDL_CONFIG = [blank] and SDL2_CONFIG = [blank] does not help: even after make clean, the executable still fails to run with the same error.
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 fam621

Re: Cross-compiling: Linux to Windows
« Reply #54 on: February 03, 2017, 10:11:59 PM »
It keeps crashing James.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #55 on: February 04, 2017, 12:37:10 AM »
Do you mean the cross-compiled build on the Bridgewater-Brunel server? If so, I am aware of the fact that it does not work at all: as you will see from the posts above, I have not been able to make cross-compiling work yet.

You will need to use the builds provided by Ves for the time being.
« Last Edit: February 04, 2017, 12:56:09 AM by jamespetts »
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #56 on: February 04, 2017, 09:19:43 AM »
Do you have 32 bit GDI cross compiling libraries by chance but linking with 64 bit def?

Also 16 bit video modes are no longer officially supported on window 10 for fullscreen, so fullscreen may crash there (although it asks whether changing resolution succeeded or failed).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #57 on: February 04, 2017, 09:31:39 AM »
Also 16 bit video modes are no longer officially supported on window 10 for fullscreen, so fullscreen may crash there (although it asks whether changing resolution succeeded or failed).

Windows 10 appears to fake it somehow. When I press Alt+Tab while playing older games on Windows 10, the rest of the system is still running in full color. On Windows 7 and earlier, everything else was also running in the same color depth as the game, causing things to look very ugly if the game used 8-bit graphics. Screen resolution is however changed for real.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #58 on: February 04, 2017, 12:52:16 PM »
I do not think that I have set up any cross-compile GDI libraries (but I am producing a 32-bit executable, not a 64-bit executable, so it would need to be a 32-bit set of libraries). Do I need to set up these libraries manually (i.e., do they not come with MinGW)?

As to Windows 10, I am using Windows 7, so Windows 10 compatibility cannot be the issue. Further, I always run Simutrans in windowed mode not full-screen, so this cannot be the issue either.

Thank you both for your replies, however: this is most helpful. It would be extremely useful to get cross-compiling set up.
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #59 on: February 04, 2017, 01:20:46 PM »
I think you produce 64 bit binaries with your compiler, at least that is my interpretation of -w64- in your compiler CC names. That will obviously crash on a 32 bit system.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #60 on: February 04, 2017, 01:37:04 PM »
I think you produce 64 bit binaries with your compiler, at least that is my interpretation of -w64- in your compiler CC names. That will obviously crash on a 32 bit system.

My system is not a 64-bit system but a 32-bit system, but 64-bit Windows 7 can of course run 32-bit binaries.  From what I understand, the i686 indicates a 32-bit build whereas replacing that with x86_64 would produce a 64-bit binary. Those are the commands that I have been advised to use in any event.
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #61 on: February 04, 2017, 01:49:52 PM »
I think you produce 64 bit binaries with your compiler, at least that is my interpretation of -w64- in your compiler CC names. That will obviously crash on a 32 bit system.

i686-w64-mingw32 is for 32-bit and x86_64-w64-mingw32 is for 64-bit. Both are from the mingw-w64 project. The original mingw32-project just calls the target mingw32, and only does 32-bit.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #62 on: February 04, 2017, 08:56:59 PM »
Further experimentation has shown that the problem was that it was somehow referring to the wrong .dll files. Putting some specific .dll files in my simutrans directory allows it to run. I worked this out after installing msys2 on Windows and trying to build it in that way, getting the same error message: a search for that error message with "msys2" gave me an explanation of what caues it, which allowed me to fix it.

However, the cross-compiled executable is still faulty. Although it will now start, attempting to load a saved game will crash it. Since this is a crash exclusive to the cross-compiled version, I cannot readily run it in a debugger to see where the problem occurs, so it is difficult to track this down.

I wonder whether the problem might be that some of the .dlls (which I took from the msys2 installation) might somehow be incompatible with the cross-compile build?

In any event, I have uploaded the .dlls in a .zip file to my server (I think that they are all open source) so that anyone downloading the cross-compile build (here) can at least try it.

Edit: The crash problem occurs when loading a network game, suggesting that the problem is not with bzlib.
« Last Edit: February 04, 2017, 09:18:28 PM by jamespetts »
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 TurfIt

Re: Cross-compiling: Linux to Windows
« Reply #63 on: February 04, 2017, 09:08:49 PM »
Try a fully static build? Attached is my makefile changes for Standard to build it static.

As long as it's built with debugging symbols, where you've built it shouldn't affect the ability to run it in the debugger.
I really don't know how you expect things to work when you grab a library from here, a header from over there, ohh here's a dll, let's use this.... At least grab the dlls from the cross.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #64 on: February 04, 2017, 09:45:29 PM »
Thank you for that. I have attempted that (I had to add conditional statements to the makefile so that the fully static build only applied to a MinGW build). This appears to improve things for MinGW on Windows: the file size is only a little larger (8,828kB) and yet it now runs without any of the extra .dlls in the directory.

The cross-compiled version does not work so well: it gives an error message complaining about a missing pthreadGC2-w32.dll when trying to start it. I already have a pthreadGC2.dll file in the same directory (and renaming it to pthreadGC2-w32.dll makes no difference to the error message, so it is obviously actually a different file in substance). This appears to suggest that the cross-compiler is working with a different pthread implementation, and that it is not statically linking pthread.
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #65 on: February 04, 2017, 11:32:52 PM »
I remember struggling with a pthread dll dependency once, even though I wasn't using threads at all. Unfortunately, I don't remember what the situation was. Since DLL get messages about threads starting and stopping, maybe a DLL is required for some functionality.

My mingw64 built Simutrans doesn't require any non-Windows DLLs, despite me having done almost he opposite of TurfIt when it comes to LDFLAGS. Which is a bit odd, because I've usually been unable to force static linking of everything that isn't Windows.

I really don't know how you expect things to work when you grab a library from here, a header from over there, ohh here's a dll, let's use this.... At least grab the dlls from the cross.
I already have a pthreadGC2.dll file in the same directory (and renaming it to pthreadGC2-w32.dll makes no difference to the error message, so it is obviously actually a different file in substance).

Please pay attention to what we're telling you when you ask for help.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #66 on: February 04, 2017, 11:36:07 PM »
I did read what was written; but the intention of that experiment was to test to see whether the issue really was just a file naming clash or whether it was more substantive.

Is there a way of getting the right version of the relevant .dll, does anyone know?
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #67 on: February 05, 2017, 02:20:22 AM »
You need exactly the same pthread DLL which you program was built for. These DLL are not compatible between different versions. However, in principle one might now do with the native pthread for mingw. Not tested though.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #68 on: February 05, 2017, 01:29:52 PM »
Thank you for that. I have tried without success to make pthread link statically (re-compiling, it produces a file of identical size which produces the identical error). To do this, I followed the advice here of changing -lpthread to -static -lpthread in the makefile. Can anyone assist with how to link pthread statically to circumvent this problem?

I do not know how to identify the correct .dll for the cross-compile version of MinGW - the version with msys2 is clearly not correct, and there does not appear to be a specific cross-compile version. Do I need to build the .dll from sources using the cross-compile toolchain? Surely a pre-compiled version must exist somewhere?
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #69 on: February 05, 2017, 01:49:08 PM »
I do not know how to identify the correct .dll for the cross-compile version of MinGW - the version with msys2 is clearly not correct, and there does not appear to be a specific cross-compile version. Do I need to build the .dll from sources using the cross-compile toolchain? Surely a pre-compiled version must exist somewhere?

As TurfIt tried to tell you, it is included with the cross compiler. There seems to be some difference between my MSYS2 mingw64 and my mingw64 cross-compiler as to where it puts its DLLs. The former puts them in bin, the other programs in there does after all require them, while the latter puts them in a deeply nested subdirectory of lib (/usr/lib/gcc/i686-w64-mingw32/4.9.4). My cross-compiler does not have pthread-support, however. If you have installed pthread separately, the DLL is also provided by that installation. In that case, it may be that it does not support static linking.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #70 on: February 05, 2017, 11:20:53 PM »
Some research suggests that static linking pthread is difficult.

However, I am afraid that I cannot find pthreadGC2-w32.dll anywhere on my installation: it is not in the directory mentioned (my version is different, so my actual directory is /usr/lib/gcc/i686-w64-mingw32/5.3-win32 or /usr/lib/gcc/i686-w64-mingw32/5.3-posix: I am not sure which is correct, but, in any event,  pthreadGC2-w32.dll is in neither of them), and "locate pthreadGC2-w32.dll" produces no results.

Edit: On a slightly different point, gdb tells me that the crashes that seem to occur when loading games with the MinGW compiled versions appear to occur in the destructor for marker_t (although GDB still crashes when I try to get a full backtrace). It complains of a segmentation fault. The only code in the destructor to marker_t is delete [] bits - it is really not clear what could be causing this.

Edit 2: Running this with the Visual Studio debugger, I get lots of calls to the destructor to marker_t when "bits" is a null value, but this causes no error in that case.

Edit 3: Running Dr. Memory gives me some more details on this issue:

Code: [Select]

Error #1: UNADDRESSABLE ACCESS: reading 0x00000000-0x00000004 4 byte(s)
# 0 marker_t::~marker_t                        [dataobj/marker.cc:44]
# 1 (anonymous namespace)::run                 [bauer/../simworld.h:2652]
# 2 _pthread_cleanup_dest.part.6               [bauer/brueckenbauer.cc:1396]
# 3 pthread_exit                               [bauer/brueckenbauer.cc:1396]
# 4 pthread_create_wrapper                     [bauer/brueckenbauer.cc:1396]
# 5 msvcrt.dll!_endthreadex
# 6 msvcrt.dll!_endthreadex
# 7 KERNEL32.dll!BaseThreadInitThunk          +0x11     (0x7573336a <KERNEL32.dll+0x1336a>)
Note: @0:12:10.819 in thread 18036
Note: instruction: mov    (%eax) -> %eax

Edit 4: Neither modifying the code thus:

Code: [Select]
arker_t::~marker_t()
{
    if (bits)
    {
        delete[] bits;
    }
    else
    {
        dbg->warning("marker_t::~marker_t()", "Calling destructor on a marker with NULL bits");
    }
}

nor even commenting out "delete[] bits'" has any effect on these crashes, and GDB still persistently crashes when I try to run this (although it is noted that the crash occurs on a thread other than the main thread; I do not know how well that GDB copes with multi-threading).

The crash occurs only when loading a game after a game has already been loaded (including demo.sve), and is intermittent (i.e. sometimes does not occur).

What seems to happen is that marker_t::the_instance, which I have made thread local so as to work with multi-threading, is deleted when threads are destroyed (as the threads for, e.g. convoy route finding, etc. are on loading a new map), and it is at this point that ~marker_t::() is called and fails. I can only assume that this is a double free error given the symptoms described above, but it is not at all clear how or why this is happening or why this only happens in MinGW builds. I wonder whether there is some error in the implementation of thread_local in MinGW builds or a version of the pthreads dll file that is linked with it?
« Last Edit: February 06, 2017, 01:47:31 AM by jamespetts »
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #71 on: February 06, 2017, 06:44:47 AM »
Some research suggests that static linking pthread is difficult.

However, I am afraid that I cannot find pthreadGC2-w32.dll anywhere on my installation: it is not in the directory mentioned (my version is different, so my actual directory is /usr/lib/gcc/i686-w64-mingw32/5.3-win32 or /usr/lib/gcc/i686-w64-mingw32/5.3-posix: I am not sure which is correct, but, in any event,  pthreadGC2-w32.dll is in neither of them), and "locate pthreadGC2-w32.dll" produces no results.

Seems like you have both threading models installed. pthreads should come with the posix one, but I'm not sure what is actually used when both are present. Furthermore, the pthread that comes with my mingw64 calls its dll libwinpthread-1.dll. So maybe you have installed pthread separately as well.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #72 on: February 06, 2017, 09:11:58 AM »
Pthread is of course installed independently from MinGW on the server in order to compile the Linux binaries, but presumably this would not put an extra subdirectory into the MinGW directory?

In any event, libwinpthread-1.dll is not in the /usr/lib/gcc/i686-w64-mingw32/5.3-win32 or the /usr/lib/gcc/i686-w64-mingw32/5.3-posix directories, either.

Edit: Returning to the crash problem, as this seems to be the issue of real importance (the earlier crashes with the cross-compiled version before I switched to static linking are very likely to be the same as the issue that I am having now with the Windows-built MinGW builds): altering the code in marker.cc to:

Code: [Select]
marker_t::~marker_t()
{
    if (this)
    {
        delete[] bits;
    }
}

now produces this, different crash:

Code: [Select]
Dr. Memory version 1.11.0 build 2 built on Aug 29 2016 02:42:07
Dr. Memory results for pid 16740: "simutrans-experimental.exe"
Application cmdline: "C:\msys32\home\James\simutrans\simutrans-experimental\build\default\simutrans-experimental.exe"
Recorded 115 suppression(s) from default C:\Program Files (x86)\Dr. Memory\bin\suppress-default.txt

Error #1: UNADDRESSABLE ACCESS: reading 0x000004bc-0x000004c0 4 byte(s)
# 0 slist_tpl<>::clear                                  [dataobj/../boden/../tpl/slist_tpl.h:359]
# 1 slist_tpl<>::~slist_tpl                             [dataobj/../boden/../tpl/slist_tpl.h:155]
# 2 hashtable_tpl<>::~hashtable_tpl                     [dataobj/../boden/../tpl/hashtable_tpl.h:17]
# 3 ptrhashtable_tpl<>::~ptrhashtable_tpl               [dataobj/../tpl/ptrhashtable_tpl.h:49]
# 4 marker_t::~marker_t                                 [dataobj/marker.cc:42]
# 5 (anonymous namespace)::run                          [bauer/../simworld.h:2652]
# 6 _pthread_cleanup_dest.part.6                        [bauer/brueckenbauer.cc:1396]
# 7 pthread_exit                                        [bauer/brueckenbauer.cc:1396]
# 8 pthread_create_wrapper                              [bauer/brueckenbauer.cc:1396]
# 9 msvcrt.dll!_endthreadex
#10 msvcrt.dll!_endthreadex
#11 KERNEL32.dll!BaseThreadInitThunk                   +0x11     (0x7573336a <KERNEL32.dll+0x1336a>)
Note: @0:01:07.681 in thread 4928
Note: instruction: mov    (%eax) -> %eax

Thus, the problem still appears to occur when marker_t::the_instance is deleted, but the crash bizarrely seems to occur in entirely unrelated parts of the code (a ptrhashtable, presumably ptrhashtable_tpl <const grund_t *, bool> more as declared in marker.h - I assume that the other collection classes are used as part of ptrhashtable_tpl).

Does anyone have any idea why this might be happening (and why only in MinGW builds)? This looks as though it might be some sort of double deletion of marker_t::the_instance (a thread_local variable), but it is how clear how this could be happening or why it does not occur in Visual Studio builds or Linux GCC builds.
 
Edit 2: It occurs to me that these errors are strongly indicative of an error with either the compiler or the pthread library: marker_t::the_instance is a static, thread_local variable, not created with the new keyword: surely, the C++ standard is violated if it is even possible to have a segmentation fault/access violation on the automatic deletion of such an object on the termination of a thread?

Edit 3: It looks as though somebody else is having a similar problem, but there is no solution in that Stack Overflow thread for it.

Edit 4: The output of g++ -v is

Code: [Select]
$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys32\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 6.3.0 (Rev1, Built by MSYS2 project)
« Last Edit: February 06, 2017, 10:20:54 AM by jamespetts »
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #73 on: February 06, 2017, 10:23:12 AM »
Something with an instance (which is a static) cannot really be thread local. But the marker on gihub is anyway not.

It may be that the marker is used by a thread while you delete it. (A variable will not be deleted at the end of a thread. Only if this is a local one.) Also route search does no go well wih thread, because then the order of vehicles arriving at a crossing/stop is random and no network games can stay in sync. (Only on single CPU systems the threads maybe  sequencial and thus in the same order.)

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #74 on: February 06, 2017, 10:31:20 AM »
Thank you for your thoughts on this. It is hard to see how the marker could be being used by the thread during deletion, since the destructor is called from the thread termination routine (# 6 _pthread_cleanup_dest.part.6 ), so the thread in question is already terminating at this point.

As to multi-threading the convoy route searching, this has been done in a particular way to prevent desyncs: the route search has been separated from a convoy's normal step and put into a special thread step. Each thread handles a fraction of the convoys in the game such that between them they all call each convoy's thread step. Only convoys in the ROUTING state have any action called on them in the thread step: in this state, they just find their route, but they then switch to a new ROUTE_JUST_FOUND state, and then perform all of the immediate post-routing actions on the next single-threaded step. This has been tested on my 4-core machine with a large and well developed saved game, and it stays in sync overnight. This system might well be helpful in Standard, too, especially in maps with lots of ships.
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #75 on: February 06, 2017, 12:28:15 PM »
Still, what prevent a route search finishing faster on one machine (i.e. found winthin the next step() ) while it takes two steps() on a slower machine, especially on small servers. That is why route searches are in the step on the standard in the first place. Those things will surface on slow versus fast machines, and probably requiring a lot of ships or other convois, so the routing task is fully occupied. Or like find_route, which must assume the reservations are the same on each machine. Here the sync_steps are important, if your really do this asynchronous.

In route 222 you call welt->unmarkiere_all, which does not look very thread local. SO I assume there is one routing task with an fifo, calculation routes sequetially?

Also, the routing in standard is safe to assume that the world is there static, i.e. unchanged in every moment. Otherwise the bridge (or tunnel) the search is currently on, can be deleted, or the sea has raised, leaving an invalid ground ptr in the NODE search array.

And finally, the initialising of the NODE arrays may take as much time as most route searches. I am not sure this is worth the hassle. Did you do profiling before? Here is an old one (my mingw is currently not compiling) http://forum.simutrans.com/index.php?topic=3166.msg33899#msg33899 where routing of convois did not even reached into the 0.5% range. And that was with lots of convois (about 500 on a 256x256 map)

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #76 on: February 06, 2017, 03:46:55 PM »
I think that you are looking at the code on the master branch, which is the old 11.32 release build from 2013, before multi-threading was implemented. The multi-threaded code is on the devel-new-2 branch, and there is no call to unmarkiere_alle(), whereas there is at line 222 of route.cc on the master branch.

The routing does not run across steps: in other words, calc_route() will not return until a complete route has been found. (I thought that this is how it worked in Standard, too). This means that it is not possible for one vehicle to find a route in a different step on one machine than on another. The thread_step() method is called just before the single threaded step() method and called on the same schedule as step() rather than sync_step(). The idea is that multiple convoys can use the route search simultaneously in parallel to find their routes, reducing the time that the rest of the program has to wait for the route searching of all the convoys that need it in a given step to complete. The route finding is not run concurrently with any function that could change the state of the world (e.g. player interaction). There are some instances of route searching still called from the main thread, such as those used with choose signals, and these run single threadedly.

As to performance, the NODE arrays are only initialised once per thread per loading of a game or creating a new map: a pool of dedicated threads for route searching is retained for the duration of the running of a single saved game/map and they work on an array of convoys indexed by a thread number given to them on thread creation so that they each work on only a subset of convoys but between them complete the route searching for all convoys that need it. The task of assigning convoys to different thread arrays is handled in a single-threaded part of the code (and is much quicker than the route searching: it does not show up as significant on profiling).

On the subject of profiling, performance profiling is not an easy way of finding the real-world performance improvement from multi-threading, as it can only report the percentage of CPU time used by any given method: this, of course, does not change if methods are spread across multiple threads (and therefore multiple CPUs) even if performance is improved by the sharing of the load. However, the idea of multi-threading the convoy route searching in the first place came from profiling showing that, in some cases at least, it takes a significant amount of CPU time (I suspect that ships and road vehicles take much  more CPU load in routing than rail and similar vehicles). I have run the Visual Studio profiler, which does indeed confirm that threads other than the main thread are now taking the bulk of the CPU load relating to convoy route searching. Also, I tested it with one particular map, which was most unresponsive without multi-threading of the convoy route searching, but which became noticeably more responsive when the multi-threading code for this was enabled.
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #77 on: February 06, 2017, 06:00:36 PM »
Pthread is of course installed independently from MinGW on the server in order to compile the Linux binaries, but presumably this would not put an extra subdirectory into the MinGW directory?

In any event, libwinpthread-1.dll is not in the /usr/lib/gcc/i686-w64-mingw32/5.3-win32 or the /usr/lib/gcc/i686-w64-mingw32/5.3-posix directories, either.

Edit 4: The output of g++ -v is

Code: [Select]
$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys32\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 6.3.0 (Rev1, Built by MSYS2 project)

Can you provide the same for the cross-compiler?

Code: [Select]
marker_t::~marker_t()
{
    if (this)
    {
        delete[] bits;
    }
}

That if is unnecessary. delete does such a check implicitly.

marker_t::the_instance is a static, thread_local variable, not created with the new keyword: surely, the C++ standard is violated if it is even possible to have a segmentation fault/access violation on the automatic deletion of such an object on the termination of a thread?

marker_t in standard Simutrans doesn't have any guards against copying it, so while the marker_t instance may be thread local, maybe the bits inside it has been inadvertently shared?

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #78 on: February 06, 2017, 09:47:09 PM »
Thank you for your reply: that is most helpful. The output of the command for the cross-compiler is:

Code: [Select]
# i686-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/5.3-win32/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++ --enable-lto --with-plugin-ld --enable-threads=win32 --program-suffix=-win32 --program-prefix=i686-w64-mingw32- --target=i686-w64-mingw32 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld --disable-libatomic
Thread model: win32
gcc version 5.3.1 20160211 (GCC)

I see that the "thread model" is different: win32 for the cross-compiler compared to posix for the Windows version of MinGW with Msys.

As to marker_t's destructor, I did work out in the end that the if(this) achieved nothing that is not implicit in any event.

In relation to copying marker_t, I have not, I do not think, done anything in particular with marker_t in Experimental, other than make it thread local, that is not already done in Standard. I have not much altered vehicle routing - at least the fundamentals of it, although I have added checks for things such as bridges for which the convoy is too heavy and added an alternative to standard relaxation of the route for the private car destination checker in which it will continue to find all possible destinations from the starting point, but neither of those should affect marker_t - this would also not explain why it would work on a native Linux GCC and a Visual Studio build on Windows but not on a MinGW build, which is most odd.

I am wondering whether the following might help: assuming this to be a MinGW or pthreads error, to replace the thread_local declaration for marker_t with an array of marker_t objects indexed by a unique number assigned to each thread: although this number itself is thread local, it already exists for other purposes (indexing the array of convoys to process in any given step) and does not fail; in any event, this would be an inherent type and would not have a destructor. Does this seem sane?
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #79 on: February 07, 2017, 03:32:45 AM »
I think that you are looking at the code on the master branch, which is the old 11.32 release build from 2013, before multi-threading was implemented. The multi-threaded code is on the devel-new-2 branch, and there is no call to unmarkiere_alle(), whereas there is at line 222 of route.cc on the master branch.
That is confusing; you have tags for releases for that purpose. But thanks for the hint.

Quote
The routing does not run across steps: in other words, calc_route() will not return until a complete route has been found. (I thought that this is how it worked in Standard, too). This means that it is not possible for one vehicle to find a route in a different step on one machine than on another. The thread_step() method is called just before the single threaded step() method and called on the same schedule as step() rather than sync_step(). The idea is that multiple convoys can use the route search simultaneously in parallel to find their routes, reducing the time that the rest of the program has to wait for the route searching of all the convoys that need it in a given step to complete. The route finding is not run concurrently with any function that could change the state of the world (e.g. player interaction). There are some instances of route searching still called from the main thread, such as those used with choose signals, and these run single threadedly.

Then you will get almost nothing from threading. Instead the overhead from threading likely make any threaded  route search slower than single threaded searches (starting a new thread and scheduling etc. for typical routes of less than 100 tiles assumed.) If you are worried about ships, I would rather introduced caching of routes and only recalculate them when water was added/removed, and share routes across lines. So a route has to be recalculated only once per line (for ships and airplanes).

But then, I never found route search very high on the profiling list, so I never worked on that. Especially after Dwachs improved ship route finder.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #80 on: February 07, 2017, 07:05:05 AM »
I see that the "thread model" is different: win32 for the cross-compiler compared to posix for the Windows version of MinGW with Msys.

That is the same as I have. MSYS2 comes with a compiler suite that is based on and includes (some variant of) pthreads. This is to support the multithread features in C++11. However, the cross-compiler does not include pthreads, so the multithreading features in the C++ library are either missing or weakened.

The routing does not run across steps: in other words, calc_route() will not return until a complete route has been found. (I thought that this is how it worked in Standard, too). This means that it is not possible for one vehicle to find a route in a different step on one machine than on another.

I seem to remember noticing that route calculation will only run for a certain number of tiles per step. That means that calc_route() may return before a route has been found, but it will take the same number of steps on all machines, keeping them in sync. But it has been long since I've looked into routing, and even then it was only briefly. (My contributions have been in the code interacting with the OS.)

Then you will get almost nothing from threading. Instead the overhead from threading likely make any threaded  route search slower than single threaded searches (starting a new thread and scheduling etc. for typical routes of less than 100 tiles assumed.) If you are worried about ships, I would rather introduced caching of routes and only recalculate them when water was added/removed, and share routes across lines. So a route has to be recalculated only once per line (for ships and airplanes).

The typical solution is to have a pool of threads standing by, so that you don't have to start new threads all the time. Doesn't the multithreaded rendering do that? There is still scheduling and synchronization, though. And wasn't the whole point of Experimental to do much more advanced routing than Standard? Maybe that only was routing the cargo, not the vehicles.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #81 on: February 07, 2017, 09:06:27 AM »
So far the only extra thing experimental does, is looking for additional restrictions (weight, third rail).

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #82 on: February 07, 2017, 10:51:56 AM »
I should note that Simutrans-Experimental does use a pool of threads for each threaded task, so there is no overhead associated with starting threads. As to the proportion of CPU time spent routing, in a 2047,1663 map about half of which is water and with numerous ships, taken from an old game played on the online server (the map being well developed), the convoy route finding took 5.85% of the CPU time (multi-threaded). This compares to 4.96% for the path explorer (goods/passenger routing), 8.25% for the display_region_thread and 15.42% for karte_t::step (single threaded), convoi_t::step (the single threaded part with the routing removed) taking 1.99%.

I imagine that in maps of 256x256 size, there is little to be gained from multi-therading convoy route-finding, but in very large maps such as this with many ships, it does make a real difference.

Do either of you have any idea how to obtain the correct .dll file to work with the cross-compiled build as now statically linked? The cross-compiled build could be run on Windows before it was statically linked, but it would crash on loading saved games - just as the Msys2 build now does in any event.
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

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #83 on: February 07, 2017, 05:01:06 PM »
You got the link library (.a file) from somewhere. That same place must also provide the corresponding DLL.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #84 on: February 07, 2017, 10:56:48 PM »
There is a libpthread.a in /usr/i686-w64-mingw32/lib. There is also /usr/share/mxe/mxe/usr/i686-w64-mingw32.static/lib/libpthread.a. There is /usr/lib32/libpthread.a
, which I assume is the native Linux version. Then there are these:

Code: [Select]
/usr/i686-w64-mingw32/lib/libpthread.a
/usr/i686-w64-mingw32/lib/libpthread.a.old
/usr/i686-w64-mingw32/lib/libpthread.dll.a
/usr/i686-w64-mingw32/lib/libwinpthread-1.dll
/usr/i686-w64-mingw32/lib/libwinpthread.a
/usr/i686-w64-mingw32/lib/libwinpthread.dll.a

None of these have the file name that the Windows executable seems to want. The last set seem the most promising, and are consistent with what the Windows version of MinGW (that supplied by Msys requests), but it is a file of a different name (as reported above) that the error message complains is missing when I link statically.

Edit: I am having some very bizarre and quite incomprehensible trouble: as noted in this post in this thread, I had been able to get cross-compiling to work (subject to the crashes on loading issue) by putting these .dll files in my simutrans directory until I made this change to the makefile to attempt static linking (which in the end did not statically link pthreads). Now, I have reverted that with this commit, but the same failure as I had after static linking persists for no apparent reason, despite me having run the make clean command before producing the build. I am extremely confused: I really do not understand what is happening or how to deal with it as there is no consistent behaviour at all.

Edit 2: I have managed to find what seems to be an official MinGW/pthread example of pthreadGC2-w32.dll. Putting this in the simutrans directory allows the cross-compiled executable to run. However, I now get a new sort of failure on loading saved games: freezes instead of crashes, and these freezes occur much earlier in the loading process than the crashes: immediately after selecting the saved game in many cases. The behaviour is reminiscent of a thread deadlock (there is one which very occasionally occurs in the Visual Studio build on loading saved games and which I have been unable to eradicate despite working at it for many hours), but it is hard to tell whether this is actually what is happening because I cannot debug these builds, so the failure could be something else entirely.

I have also tried unsuccessfully to link pthreads statically using the instruction here, and, oddly, the resulting binary now requires more .dlls relating to pthreads than it did before (all of libwinpthread-1.dll, pthreadGC2-w32.dll and libgcc_s_dw2-1.dll). Static linking of pthreads would at least eliminate the problems caused by not being sure of having the right version, but this seems to be fantastically difficult to achieve.

Edit 3: Running the cross-compiled version in the Windows MinGW debugger, it seems that, despite the difference in observed behaviour (freezing rather than crashing to desktop), the actual cause of the problem with this build is the same, namely a segmentation fault in the destructor of marker_t.

Edit 4: I think that I have managed to make a version that works. using the pthreadGC2-w32.dll from edit 2 above, reverting the static linking as suggested by, I think, Ters earlier in this thread, and by replacing the thread local static marker with a static array of markers indexed by thread local thread numbers, a version compiled on my Linux server can now run on my Windows machine, repeatedly load games and connect to the Linux server without crashing. However, I now seem to get a desync, albeit only after a period in excess of 10 minutes. It is not clear whether this is specific to the cross-compiled version or what is causing this, and I am checking with the Windows MinGW build is any better in this respect.

Edit 5: The nightly builds, together with the necessary .dll file, can now be found here.
« Last Edit: February 08, 2017, 05:11:55 PM by jamespetts »
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #85 on: February 11, 2017, 11:54:07 AM »
I had an entire day "fun" with mingw64. You *must* use the posix threads, winpthreads will crash during reading. Aparently the mingw64 runtime messes up the winpthreads (despite other documentation).

And you must built bzlib and whatever else you need with the same compiler!

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #86 on: February 11, 2017, 12:00:29 PM »
Thank you for that. I am not quite sure how to choose posix threads over and above winpthreads, but the build that I have seems to work now, save for the desync, which further testing has revealed is in any event common to the pure Linux GCC build.
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 HaydenRead

Re: Cross-compiling: Linux to Windows
« Reply #87 on: February 12, 2017, 09:09:31 AM »
Did the 'Simutrans Ex' 'devel-new-2' build using 'SDL2' for linux, and windows on the box which I use for compiling Steam builds, and the only change I had to make was to remove the '-static' flag from the Makefile mingw section, and add '#include <cstdio>' to sdl_sound.cc (it uses printf which is declared in cstdio - for some reason it compiles linux build fine with or without <ctsdio>, but not for windows using mingw on linux).

Also will take a look at Mac OSX build (my Mac OSX build is done on a server that charges by the hour, so I don't do Mac builds as often).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4812
  • Total likes: 191
  • Helpful: 108
  • Languages: EN, NO
Re: Cross-compiling: Linux to Windows
« Reply #88 on: February 12, 2017, 10:15:38 AM »
(it uses printf which is declared in cstdio - for some reason it compiles linux build fine with or without <ctsdio>, but not for windows using mingw on linux).

It is not uncommon to find that when trying out a different compiler suite, even different versions of the same, one suddenly has to include an std... header file (for me, usually stdlib.h). In hindsight, it was always required according to the docs/spec, but these headers files a very often included by other header files, and you had somehow come to depend on it. I'm not sure what the standard says about its header files including each other. However, it might also be 3rd party headers that conditionally include headers depending on platform (or other stuff).

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #89 on: March 21, 2017, 01:10:37 AM »
Having got this to work, I am now encountering a fresh problem with makoebj (but, oddly, not the main Simutrans-Extended executable). I am now getting the following error when cross-compiling:

Code: [Select]
===> LD  ../build/mingw/makeobj-extended/makeobj-extended
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x32): undefined reference to `png_create_read_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x45): undefined reference to `png_create_info_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x7d): undefined reference to `png_init_io'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x8f): undefined reference to `png_read_info'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0xd5): undefined reference to `png_get_IHDR'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x10c): undefined reference to `png_set_strip_16'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x117): undefined reference to `png_set_packing'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x147): undefined reference to `png_read_update_info'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x159): undefined reference to `png_get_rowbytes'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x1a8): undefined reference to `png_read_image'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x235): undefined reference to `png_read_end'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x24f): undefined reference to `png_destroy_read_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x262): undefined reference to `png_set_expand'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x26d): undefined reference to `png_set_strip_alpha'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x288): undefined reference to `png_set_filler'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x298): undefined reference to `png_set_swap_alpha'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x2a3): undefined reference to `png_set_invert_alpha'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x2e9): undefined reference to `png_destroy_read_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x4f2): undefined reference to `png_create_write_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x505): undefined reference to `png_create_info_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x53d): undefined reference to `png_init_io'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x550): undefined reference to `png_set_compression_level'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x598): undefined reference to `png_set_IHDR'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x5aa): undefined reference to `png_write_info'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x5cf): undefined reference to `png_set_filler'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x5fc): undefined reference to `png_write_row'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x615): undefined reference to `png_write_end'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x627): undefined reference to `png_destroy_write_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x64a): undefined reference to `png_destroy_write_struct'
../build/mingw/utils/dr_rdpng-makeobj-extended.o:dr_rdpng.cc:(.text+0x6ab): undefined reference to `png_destroy_write_struct'
collect2: error: ld returned 1 exit status
../uncommon.mk:22: recipe for target '../build/mingw/makeobj-extended/makeobj-extended' failed
make: *** [../build/mingw/makeobj-extended/makeobj-extended] Error 1

The normal Linux build works, as well as the Windows Visual Studio build. This had been working until recently, but I have of late been merging in some of the latest changes from Standard.

This looks like a linker error relating to the PNG libraries, but I do not really understand what has changed such that my previous setup now no longer works. If anyone could suggest where I might look to try to find the answer to this, I should be most grateful, as I find this all very opaque.
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 Vladki

Re: Cross-compiling: Linux to Windows
« Reply #90 on: April 12, 2017, 07:39:04 AM »
I'm no expert on cross compiling, but I suppose you had to prepare all libraries for cross compile somehow (libc, libbz,...). Did you do the same for libpng?




Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #91 on: April 12, 2017, 09:44:43 AM »
I did - and it initially worked, but do then stopped working after I merged some changes from Standard for no discernable reason.
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #92 on: April 12, 2017, 01:37:38 PM »
You likely have to define something to farce name mangling, because it does now regard the functions as extern.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 15697
  • Total likes: 395
  • Helpful: 174
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Cross-compiling: Linux to Windows
« Reply #93 on: April 12, 2017, 09:33:47 PM »
I am afraid that I am not sure that I quite follow: what functions are now regarded as extern that were not before? Apologies if I am being a bit dim.
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 prissi

  • Developer
  • Administrator
  • *
  • Posts: 8798
  • Total likes: 319
  • Helpful: 229
  • Languages: De,EN,JP
Re: Cross-compiling: Linux to Windows
« Reply #94 on: April 13, 2017, 07:05:16 AM »
functions are oten renamed "void doing(int,int)" from "_doing" for extern functuion usual in a library to "@Vdoing22"to check types for function comiled within the same program. So if the extern somehow is missing, then the names are decorated (mangled), which is a problem for libaries. However, if you are using the same compiler for both library and code, then mangling may be on.