The International Simutrans Forum

 

Author Topic: Incorporating changes from Standard  (Read 29979 times)

0 Members and 1 Guest are viewing this topic.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #140 on: September 14, 2020, 02:20:56 AM »
Easiest to obtain minupnpc is using the script from the standard technical documentation for MINGW64. Apart from downloading, it also compiles the lib files for MSVC and has all the h files.
https://forum.simutrans.com/index.php/topic,20271.0.html

However, minupnpc is only relevant if someone wants to set up a server at home behind a router and does not want to set up port forwarding by hand. With the large extended savegame size, ADSL is not very well suited for that, so one could as well set USE_PNP=0 and postpone this for normal development.

The github built for standard also contain provisions for freetype see here (Librotli is also broken on Mingw, and this is needed by freetype):
https://github.com/aburch/simutrans/tree/master/.github

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: Incorporating changes from Standard
« Reply #141 on: September 14, 2020, 11:20:14 AM »
Imho, the server build should usually be built without upnpc. It's simply unusual to run a headleass server at home and even if someone wanted to do this, he will most likely know how to setup port forwarding.

In case, nightlies of the client should be compiled with it.
Many home internet connections got 50 Mbit/s upstream, which is still more than enough, given we got players with much less downstream playing actively on bridgewater.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #142 on: October 10, 2020, 12:29:10 PM »
Thank you for this. I have now managed to get the miniupnpc working, but I am missing a freetype dependency, freetype.lib. May I ask where you obtained the freetype.lib file so that I can find this easily?

Thank you for your work on this so far.

Offline Freahk

  • Devotee
  • *
  • Posts: 1624
  • Languages: DE, EN
Re: Incorporating changes from Standard
« Reply #143 on: October 10, 2020, 04:43:48 PM »
From the simutrans repository on git:
Quote
The following are also recommendend, but optional
libfreetype (http://www.freetype.org/)
libminiupnpc (http://miniupnp.free.fr/)

Thus, I believe https://www.freetype.org/download.html is the official download source.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #144 on: October 10, 2020, 05:41:20 PM »
From the simutrans repository on git:
Thus, I believe https://www.freetype.org/download.html is the official download source.

The download that I found there did not include the Windows .lib file; is this not available anywhere pre-compiled?

Offline Andarix

  • *
  • Posts: 314
  • Languages: de
Re: Incorporating changes from Standard
« Reply #145 on: October 10, 2020, 05:46:32 PM »
https://github.com/Andarix/simutrans/tree/master/libs

windows libs compile msvc 2019

miniupnpc not compile on my Windows 10 2004 and msvc 2019

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #146 on: October 11, 2020, 12:35:48 AM »
Andarix - thank you for that. I shall investigate this to-morrow.

One potentially extremely challenging problem that I foresee with adding new libraries is the need to obtain working cross-compilation libraries to allow the nightly builds to work: Windows builds are compiled on a Linux server. I recall spending a truly vast amount of time a few years ago struggling with this issue for the existing libraries.

Has anyone managed to get cross-compiling to work with these new libraries?

Offline freddyhayward

  • Devotee
  • *
  • Posts: 692
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #147 on: October 11, 2020, 02:02:28 AM »
Andarix - thank you for that. I shall investigate this to-morrow.

One potentially extremely challenging problem that I foresee with adding new libraries is the need to obtain working cross-compilation libraries to allow the nightly builds to work: Windows builds are compiled on a Linux server. I recall spending a truly vast amount of time a few years ago struggling with this issue for the existing libraries.

Has anyone managed to get cross-compiling to work with these new libraries?
I can't help with cross-compiling, but couldn't you switch to using the github CI builds?

Offline Matthew

  • Devotee
  • *
  • Posts: 620
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Incorporating changes from Standard
« Reply #148 on: October 11, 2020, 04:33:34 AM »
I can't help with cross-compiling, but couldn't you switch to using the github CI builds?

The Github Actions configurations that ceeac kindly made are all using Ubuntu. So if they are used as a base, using Github CI is cross-compiling, isn't it?

My sim-mingw-debug branch is an attempt to do that. It is very much work-in-progress; at the moment I am still learning how makefiles work, especially in conjunction with James' shell script.

Github does offer Actions using Windows, with the MSYS2 distribution of MinGW available in the default image. However, I believe GCC and MSVS builds of Simutrans are not interoperable. I don't know whether using MSYS2 to build on Windows would be easier than cross-compiling or not.

Offline Andarix

  • *
  • Posts: 314
  • Languages: de
Re: Incorporating changes from Standard
« Reply #149 on: October 11, 2020, 04:37:02 AM »
I can't help with cross-compiling, but couldn't you switch to using the github CI builds?

see https://github.com/Andarix/simutrans/blob/master/.github/workflows/windows.yml

I create the builds with Git action.
https://github.com/Andarix/simutrans/releases not all testet

[EDIT]
Compiling miniupnpc itself is not the problem. Only the created lib cannot be linked to Simutrans.

https://simutrans-germany.com/files/upload/miniupnpc.lib.zip (to 9 dec 2020)

Quote
1>miniupnpc.lib(minissdpc.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp__GetBestRoute@12".
1>miniupnpc.lib(minissdpc.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp__GetIpAddrTable@12".

« Last Edit: October 11, 2020, 05:17:26 AM by Andarix »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #150 on: October 11, 2020, 10:43:54 AM »
Thank you for that. I am getting the same sorts of errors as Andarix now that I have linked to the supplied Freetype libraries. My errors in Visual Studio are:

Code: [Select]
Severity Code Description Project File Line Suppression State
Error LNK2001 unresolved external symbol FT_Init_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Init_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_Done_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Done_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_New_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_New_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_Done_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Done_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_Set_Pixel_Sizes Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Load_Glyph Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Render_Glyph Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Get_Char_Index Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Get_Char_Index Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol __imp_freeUPNPDevlist Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_upnpDiscover Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_GetValidIGD Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_FreeUPNPUrls Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_GetExternalIPAddress Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_AddPortMapping Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_DeletePortMapping Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK1120 15 unresolved externals Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\Simutrans-Extended-debug.exe 1

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #151 on: October 11, 2020, 01:27:56 PM »
FT_xxx missing  means missing freetype library ... You need to specify freetype.lib as library somewhere.

The __imp_ xxx come linking to a DLL. I am sending you my libd and includes.

Offline Andarix

  • *
  • Posts: 314
  • Languages: de
Re: Incorporating changes from Standard
« Reply #152 on: October 11, 2020, 03:37:15 PM »
FT_xxx missing  means missing freetype library ... You need to specify freetype.lib as library somewhere.

The __imp_ xxx come linking to a DLL. I am sending you my libd and includes.

libd is debug

I compile release. Debug-dll not exist by not install MSVC

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #153 on: October 12, 2020, 12:11:08 AM »
Well, I use static libs.

Offline Roboron

  • Devotee
  • *
  • Posts: 359
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: Incorporating changes from Standard
« Reply #154 on: October 12, 2020, 06:25:47 PM »
My sim-mingw-debug branch is an attempt to do that. It is very much work-in-progress; at the moment I am still learning how makefiles work, especially in conjunction with James' shell script.

I've wanted for a long time to cross-compile Simutrans on my system, and only recently (and after dealing with mingw on windows, too) I learned how to do it. I've documented what I've learned cross compiling Simutrans on the wiki. You may find it useful.
« Last Edit: October 13, 2020, 11:41:46 AM by Roboron »

Offline Matthew

  • Devotee
  • *
  • Posts: 620
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Incorporating changes from Standard
« Reply #155 on: October 13, 2020, 11:39:41 AM »
I've wanted for a long time to cross-compile Simutrans on my system, and only recently (and after dealing with mingw on windows, too) I learned how to do it. I've documented what I've learned cross compiling Simutrans on the wiki. You may find it useful.

Thank you for this suggestion and for kindly documenting it on the wiki, Roboron. It's so helpful when Simutransers document the things they've learned for others to use!

It seems that your strategy uses MXE, which is a makefile to cross-compile the libraries from source. That approach makes sense for you since you're already self-compiling most of your software on Arch. But it's an awkward fit with Github Actions, which start with a clean Ubuntu installation (or MSYS2 on Windows). Compiling the whole of MXE after every (Simutrans) commit seems like using a sledgehammer to crack a nut. But I will bear it in mind while I continue watching Andarix's experiments.

Offline Roboron

  • Devotee
  • *
  • Posts: 359
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: Incorporating changes from Standard
« Reply #156 on: October 13, 2020, 11:49:39 AM »
It seems that your strategy uses MXE, which is a makefile to cross-compile the libraries from source.

I think you didn't read the article well enough. I suggested two approachs:

Quote
For installing mingw64 on a GNU/Linux machine, you generally have two options: install from your distribution repositories or install the MXE enviroment

1. Cross-Compile using mingw64 from your system repositories (I only have listed packages for Fedora and and extra repositories for Arch Linux - I don't know what mingw64 packages are necessary on Ubuntu).
2. OR Cross-Compile using mingw64 from MXE (if you can't get mingw64 from your distribution!).

Also, you don't need to compile all the MXE software if you don't want to, I said that in the wiki page too...

Quote
This will build all necessary dependencies. If you don’t want to compile them (it will take a while), you can also download binaries from https://pkg.mxe.cc/

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #157 on: October 13, 2020, 02:10:12 PM »
Ubuntu has a mingw64 cross compiling (at least debian has)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #158 on: October 16, 2020, 05:56:16 PM »
Thank you very much for all your feedback and especially to prissi for sending me the library and include files. I have now put the files that Prissi has sent into my respective include and lib directories, but I am afraid that I am still getting the same errors. Since this is a linker error (LN2001: unresolved external symbol), this means that there is a series of method/variable names referred to in header files that are not actually defined in the library files linked.

This is very odd, since I have put the library files in the some directories that I have set up (one for freetype and the other for miniupnpc), and then added these locations to the list of library files for the relevant build. Moreover, I know that the problem is not that I have mis-specified a directory somewhere, since, if I rename freetype.lib, I get a different error, "cannot open freetype.lib", which reverts to the linker errors as described above when I revert the name change.

I am wondering whether there might be some mismatch between the include and library files? If anyone has any idea what is happening, I should be very grateful, as I am keen to progress this.

Offline Ranran

  • Devotee
  • *
  • Posts: 1660
  • 今日は兎汁よー
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #159 on: October 16, 2020, 06:13:36 PM »
I think the library is different for 64bit and 32bit. I only use 32bit for debugging...
I have successfully compiled using MSVC2017.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #160 on: October 16, 2020, 06:28:09 PM »
I think the library is different for 64bit and 32bit. I only use 32bit for debugging...
I have successfully compiled using MSVC2017.

That might explain it. I debug with 64 bit builds. Prissi - can I check whether the files that you sent were 64 bit or 32 bit? Does anyone know where one might find 64 bit libraries?

Offline Roboron

  • Devotee
  • *
  • Posts: 359
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: Incorporating changes from Standard
« Reply #161 on: October 16, 2020, 06:34:23 PM »
Does anyone know where one might find 64 bit libraries?

Not long ago I used https://github.com/Microsoft/vcpkg for that. I think all libraries Simutrans needs are available there, but i've never compiled Simutrans in MVSC, so I don't know for sure if they work.

Offline ceeac

  • Devotee
  • *
  • Posts: 276
Re: Incorporating changes from Standard
« Reply #162 on: October 16, 2020, 08:20:47 PM »
Not long ago I used https://github.com/Microsoft/vcpkg for that.
That's also the approach I went with in my CMake build support branch that has just been merged by James. The goal is to auto-download, build and auto-update all the dependencies when generating MSVC project files with CMake, although this is not yet 100% finished because the merge caught my by surprise. :) I'll try to create a separate thread this weekend outlining how to build using CMake + Visual Studio.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10905
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #163 on: October 16, 2020, 11:22:29 PM »
My libaries are 32 bit, since community edition can only build 32 bit programs (at least in the 2015 version I use). I never built 64 bit on MSVC. But it is quite forward to build freetype.lib


Offline Matthew

  • Devotee
  • *
  • Posts: 620
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Incorporating changes from Standard
« Reply #164 on: October 17, 2020, 08:45:46 AM »
That's also the approach I went with in my CMake build support branch that has just been merged by James. The goal is to auto-download, build and auto-update all the dependencies when generating MSVC project files with CMake, although this is not yet 100% finished because the merge caught my by surprise. :) I'll try to create a separate thread this weekend outlining how to build using CMake + Visual Studio.

I would definitely be interested in using such a workflow and would need a tutorial to do so. I suspected was the dependencies that defeated my last attempt to use Visual Studio.

There's no hurry, but hopefully it will be good to know that your efforts will be used.  :thumbsup:

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #165 on: October 17, 2020, 03:31:44 PM »
I have made some progress with this, but am still unable to get it to compile.

I have built my own Visual Studio 64 bit versions of Freetype and Miniupnpc. The Freetype build worked without difficulty, but the Miniupnpc build has had some trouble. I had to create a new x64 configuration in Visual Studio for this; this apparently worked, but I had the same errors as before. I realised that I had to add the MINIUPNP_STATICLIB preprocessor definition to the Simutrans project to allow this to work.

Having done this, I then had to rebuild bzip.lib as it complained about this being made with an older version for some reason. I was able to do this successfully, but now I get new and mysterious linker errors apparently relating to miniupnpc:

Code: [Select]
Severity   Code   Description   Project   File   Line   Suppression State
Error   LNK1120   4 unresolved externals   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\Simutrans-Extended-debug.exe   1   
Error   LNK2001   unresolved external symbol __imp_perror   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)   1   
Error   LNK2001   unresolved external symbol __imp__memicmp   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)   1   
Error   LNK2001   unresolved external symbol __imp_GetAdaptersAddresses   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(minissdpc.obj)   1   
Error   LNK2001   unresolved external symbol __imp_GetBestInterfaceEx   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(minissdpc.obj)   1   

If anyone has any idea what is going on and how to go about trying to fix this, I should be most grateful.

Edit: I have reduced those errors by recompiling miniupnpc with the static linker option, but I still get these errors:
Code: [Select]
Severity    Code    Description    Project    File    Line    Suppression State
Error    LNK2001    unresolved external symbol __imp_perror    Simutrans-Extended    C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)    1   
Error    LNK2001    unresolved external symbol __imp__memicmp    Simutrans-Extended    C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)    1   
Error    LNK1120    2 unresolved externals    Simutrans-Extended    C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\Simutrans-Extended-debug.exe    1   
« Last Edit: October 17, 2020, 03:45:27 PM by jamespetts »

Offline Ranran

  • Devotee
  • *
  • Posts: 1660
  • 今日は兎汁よー
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #166 on: October 17, 2020, 04:07:06 PM »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #167 on: October 17, 2020, 04:54:37 PM »
https://github.com/seredat/karbowanec/issues/38

Is this relevant?

I suspect not, sadly - the significance of that is changing from a DLL build to a non-DLL build, but my Visual Studio builds are not DLL builds (albeit they are debug rather than non-debug versions of these builds).

May I ask - do you use Visual Studio for your debug builds? If so, how were you able to get this to work?

Offline Ranran

  • Devotee
  • *
  • Posts: 1660
  • 今日は兎汁よー
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #168 on: October 17, 2020, 05:54:38 PM »
do you use Visual Studio for your debug builds?
Yes.
I think I'm using an older version as it was added to standard a few years ago. The version that uses the dll.

Debug builds can be built using these. It may be the same as provided by prissi...
https://drive.google.com/file/d/1_Xr2-jiILN1nHTHWV4BrDJmyYNa_-Dwu/view?usp=sharing

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #169 on: October 18, 2020, 01:06:03 PM »
Yes.
I think I'm using an older version as it was added to standard a few years ago. The version that uses the dll.

Debug builds can be built using these. It may be the same as provided by prissi...
https://drive.google.com/file/d/1_Xr2-jiILN1nHTHWV4BrDJmyYNa_-Dwu/view?usp=sharing

Thank you for those. However, given that I use 64 bit debug builds, this unfortunately will not assist me, as I presume that these are 32-bit libraries?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #170 on: October 25, 2020, 01:39:21 PM »
I have finally succeeded in making this work. The error had been that I had been compiling a .dll version of miniupnpc. I thought that I had changed this to static, but it transpires that I had become confused with the "upnpc static" project in the Visual Studio file which is, in fact, unrelated to miniupnpc, and had changed the settings on that instead of the miniupnpc library. Recompiling the library as static allows this to compile. I had also added IPHlpApi.Lib to the linker's list of input libraries.

I have this on my merge-from-standard-8434 branch. I appreciate that this is now a little behind Ranran's work, but it is better, I think, to stabilise this and get it working before moving forward to incorporate later changes, unless doing so is likely to fix problems in this version.

This is likely to require extensive testing. It would very much help to have a list summarising the areas where there are expected to be major differences so that I can test those specifically. One problem that I notice immediately is that the file names in the load dialogue are not clickable: I can only load games by typing file names manually.

I should be very grateful for testing by anyone who can compile this, as, given the number of things that have changed, the more testing, the better.

The next challenge, which might well be very difficult, is to get this version working with cross-compiling for the nightly build server. Can I check whether anyone has managed this yet? How does this branch work with CMake? I notice that I have had error messages from the CI builds sent to me complaining of compile failures whenever I update this branch on Github.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 692
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #171 on: October 25, 2020, 03:15:10 PM »
I can't compile this using cmake or regular make:
Code: [Select]
In file included from /usr/include/c++/10/bits/stl_iterator_base_types.h:67,
                 from /usr/include/c++/10/iterator:61,
                 from bauer/../utils/../utils/for.h:10,
                 from bauer/../utils/../simtypes.h:13,
                 from bauer/../utils/log.h:12,
                 from bauer/../simdebug.h:21,
                 from bauer/brueckenbauer.cc:8:
/usr/include/c++/10/type_traits: In instantiation of ‘struct std::is_move_constructible<sparse_tpl<short unsigned int> >’:
/usr/include/c++/10/type_traits:138:12:   required from ‘struct std::__and_<std::is_move_constructible<sparse_tpl<short unsigned int> >, std::is_move_assignable<sparse_tpl<short unsigned int> > >’
/usr/include/c++/10/type_traits:143:12:   required from ‘struct std::__and_<std::__not_<std::__is_tuple_like<sparse_tpl<short unsigned int> > >, std::is_move_constructible<sparse_tpl<short unsigned int> >, std::is_move_assignable<sparse_tpl<short unsigned int> > >’
/usr/include/c++/10/type_traits:2195:11:   required by substitution of ‘template<class ... _Cond> using _Require = std::__enable_if_t<std::__and_< <template-parameter-1-1> >::value> [with _Cond = {std::__not_<std::__is_tuple_like<sparse_tpl<short unsigned int> > >, std::is_move_constructible<sparse_tpl<short unsigned int> >, std::is_move_assignable<sparse_tpl<short unsigned int> >}]’
/usr/include/c++/10/bits/move.h:189:5:   required by substitution of ‘template<class _Tp> std::_Require<std::__not_<std::__is_tuple_like<_Tp> >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = sparse_tpl<short unsigned int>]’
bauer/../obj/../tpl/sparse_tpl.h:240:15:   required from ‘class sparse_tpl<short unsigned int>’
bauer/../obj/../simcity.h:180:21:   required from here
/usr/include/c++/10/type_traits:960:52: error: static assertion failed: template argument must be a complete class or an unbounded array
  960 |       static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc: In static member function ‘static void bridge_builder_t::build_bridge(player_t*, koord3d, koord3d, koord, sint8, const bridge_desc_t*, const way_desc_t*, overtaking_mode_t)’:
bauer/brueckenbauer.cc:855:40: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
  855 |    const slope_t::type hang = start_gr ? start_gr->get_weg_hang() :  slope_t::flat;
      |                               ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc:909:34: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
  909 |    const slope_t::type hang = gr ? gr->get_weg_hang() :  slope_t::flat;
      |                               ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc:998:35: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
  998 |     const slope_t::type hang = gr ? gr->get_weg_hang() :  slope_t::flat;
      |                                ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc: In static member function ‘static void bridge_builder_t::build_ramp(player_t*, koord3d, ribi_t::ribi, slope_t::type, const bridge_desc_t*, const way_desc_t*, overtaking_mode_t, bool)’:
bauer/brueckenbauer.cc:1118:33: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
 1118 |   const slope_t::type hang = gr ? gr->get_weg_hang() : slope_t::flat;
      |                              ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [common.mk:56: build/default/bauer/brueckenbauer.o] Error 1

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20923
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #172 on: October 25, 2020, 03:40:47 PM »
Interesting - this appears to be a syntax error in an included header file. This would suggest that the CMake build settings are targetting a different language subversion. I am not sure how this would work, since I am not familiar with CMake. Is there a way of explicitly forcing CMake to expect C++11?

Offline ceeac

  • Devotee
  • *
  • Posts: 276
Re: Incorporating changes from Standard
« Reply #173 on: October 25, 2020, 05:29:11 PM »
Is there a way of explicitly forcing CMake to expect C++11?
It already does expect C++11; see the beginning of CMakeLists.txt.
For fixing the error, see my reply in the CMake thread.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 692
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #174 on: October 25, 2020, 08:36:32 PM »
Interesting - this appears to be a syntax error in an included header file. This would suggest that the CMake build settings are targetting a different language subversion. I am not sure how this would work, since I am not familiar with CMake. Is there a way of explicitly forcing CMake to expect C++11?
Again, this also occurs with regular make.