Godotsteam: Cross-compiled game from linux to windows crashes on startup

[EIREXE]

Versions of the engine compiled with MinGW seem to crash on windows after initialization, steamworks initializes properly and the game just quits, nothing in the logs.

This is my output:

Godot Engine v3.2.beta.custom_build.12482bf88 - https://godotengine.org
OpenGL ES 3.0 Renderer: Radeon RX Vega

WARNING: set_native_icon: No small icon found, reusing 128x128 @32768 icon!
     At: platform/windows/os_windows.cpp:2845
Setting breakpad minidump AppID = 1216230
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198041958539 [API loaded no]
[INFO] SteamServiceProvider: Steamworks active.

Compiling this natively on windows with MSVC works.

[Gramps]

Hmm, compiling on Linux with MinGW for Windows? There are no errors or warnings during compile? And nothing seems to show up in the logs when it dies? Might be a bit tricky to figure out.

[EIREXE]

@Gramps there are some, here's the log:
log.txt

[Gramps]

If I'm reading that right, you're compiling a template. So when exporting using this template the game crashes at boot?

[EIREXE]

Yes, if I compile the template on windows itself the crash does not happen.

As a matter of fact, if I launch the game (and take care of not doing anything with Steamworks after steamInit() is called) with steam closed, the game does not crash.

[Gramps]

That's odd. Do you have the steam_appid.txt in the same folder as the executable?

[EIREXE]

Yes I do, as I said it only crashes when steam is open for some odd reason, if I close Steam it works.

[Gramps]

Just to cover all the bases... the version you compile on Windows is exactly the same source code and GodotSteam version as the one you compile on Linux. Both have the steam_appid.txt in the same directory as the executable. Linux is cross-compiled for Windows with MinGW and the executable works fine if you don't include the module but fails if you do.

What Linux version are you using? What version of GCC is MinGW using? I will attempt a cross-compile on Ubuntu 19.10 today and see what I get.

[EIREXE]

I'm on arch, using GCC 9.2.

I will attempt some tests tomorrow to see what I can find, thanks for the help btw.

[Gramps]

Welcome! Hmm, OK. I will write back after I compile it on my end.

[Gramps]

So I compiled it on Ubuntu 19.10 with GCC / G++ 9.2.1 and MinGW 9.2 with POSIX. Everything seemed to go fine and I get no crashes when running my test project. Is your MinGW using POSIX by chance?

Weirdly, if I try to get the user Steam ID it will crash with:

ERROR: _get_socket_error: Socket error: 10054
   At: drivers/unix/net_socket_posix.cpp:190

Not exactly sure what that is about as that function hasn't changed since the beginning but it is added to my list.

[EIREXE]

That... sound plausible, i'll check.

[Gramps]

Let me know how that goes. That's about all I can find really.

[EIREXE]

Yes it was compiled using posix, godot without posix fails to compile

[Gramps]

Can you zip your compiled editor and template then upload it to this issue?

[Gramps]

Any further progress on this?

[EIREXE]

@Gramps Sorry for not responding, I was out, I'll set myself a reminder to do it tonight.

[Gramps]

It's all good. Just checking in.

[EIREXE]

https://we.tl/t-ha3dMoSV4g

Here's the link, sorry for taking so long.

[Gramps]

It's all good, I'll give this a run here after I finish up some stuff!

[Gramps]

Well, both templates works fine for me. I can run the exported example and everything is functional. The engine does crash when I try to run the example from it though. I noticed it says it is the 3.2-beta build which might be an issue. Also the file is opt.tools; not sure how you got that naming convention in compiling. What command did you run to compile this?

[EIREXE]

scons -j8 platform=windows tools=no target=release bits=64

and

scons -j8 platform=windows tools=no target=release_debug bits=64

[Gramps]

Those are for your templates? What do you compile the editor with? Since that seems to be the only issue I see.

[EIREXE]

scons -j8 platform=windows tools=yes target=release_debug bits=64

[Gramps]

Sorry for the delay. Hmm, try using just:
scons platform=windows bits=64
I don't know the target=release_debug line should be used for the editor, more so for the templates.

[EIREXE]

Sorry for the delay. Hmm, try using just:
scons platform=windows bits=64
I don't know the target=release_debug line should be used for the editor, more so for the templates.

I think the stock editor is built with release_debug, so that it has good performance.

I'll try.

[Ranoller]

With release_debug is integrated the print console and the debug functions, not the editor. The editor is appended with tools keyword (tools=yes tools=no)

[Ranoller]

target = release_debug or target =debug are needed for the editor to work (to debug)... release_debug seems to be a middle point between release and debug, some optimizations are applied and some debug functions seems to not work (i remember some memory spaces, static or dinamic i can't remember, but one of them can't be debuged with release_debug... look at the profiler with both options...)

[Gramps]

Then I'm not sure what the default is when you compile without it but I never use any debug options when building templates or editors. Can't say I've run into any debugging issues without it.

[EIREXE]

Building the engine with release still results in a crash on windows

[alperc84]

Building the editor with "target=release" is impossible. You can only build the editor with "debug" or "release_debug".

_release: Build without symbols, with optimization and with little to no runtime checks. This target can’t be used together with tools=yes, as the editor requires some debug functionality and run-time checks to run._

I am using ubuntu 18.04 lts and I am building for windows. I am not pro but i think your problem not related with build options. I can build with all options, no crash or anything on my side.
I know it's not a fix but maybe you can try with another os (ubuntu) via virtual pc. So we can make narrow the problem. Just a suggestion.

[Gramps]

@EIREXE I wasn't saying to build with "release" just build with only platform and bits like this: scons platform=windows bits=64.

Sadly since no suggestions have changed the issue and I cannot reproduce it, I'm not sure where to go from here.

@alperc84 is correct that trying a VM might be your next step to see if perhaps it is just your setup that is causing the issue.

[EIREXE]

Yes, I am preparing to build using ubuntu 14 (I think that's what godot uses).

[EIREXE]

Building the editor with "target=release" is impossible. You can only build the editor with "debug" or "release_debug".

_release: Build without symbols, with optimization and with little to no runtime checks. This target can’t be used together with tools=yes, as the editor requires some debug functionality and run-time checks to run._

I am using ubuntu 18.04 lts and I am building for windows. I am not pro but i think your problem not related with build options. I can build with all options, no crash or anything on my side.
I know it's not a fix but maybe you can try with another os (ubuntu) via virtual pc. So we can make narrow the problem. Just a suggestion.

I was referring to building the game-only code, not the editor, this crash seems to be godotsteam exclusive at the time.

[Gramps]

I probably wouldn't use Ubuntu 14 because it has a really old version of GCC / G++. I would use at least 18.04 LTS or higher. Godot 3, I think, won't compile correctly without GCC 6 or higher.

Building game-only code? Like the template? Yeah, it seems to only crash when the editor you compile runs the game. As to why it is a problem on Arch with this library doesn't make any sense; I wonder if it is some deeper configuration problem.

Speaking of, what version of Arch are you using?

[EIREXE]

I probably wouldn't use Ubuntu 14 because it has a really old version of GCC / G++. I would use at least 18.04 LTS or higher. Godot 3, I think, won't compile correctly without GCC 6 or higher.

Building game-only code? Like the template? Yeah, it seems to only crash when the editor you compile runs the game. As to why it is a problem on Arch with this library doesn't make any sense; I wonder if it is some deeper configuration problem.

Speaking of, what version of Arch are you using?

AFAIK ubuntu 14 LTS is what's used to compile the official binaries, unless something has changed.

Arch is rolling release so it doesn't have versions.

Anyways, I will probably move to an ubuntu VM for building, as that is necessary anywyas.

[Gramps]

The compiling document for Godot says to use Ubuntu 16.04 since, supposedly, the exported game will not work on platforms older than the one it is compiled on. I don't know how that's true or if it's true in practice but I've been compiling my game on Ubuntu 19.10 and haven't had any issues.

Did swapping to Ubuntu from Arch work for you? Finally downloaded the ISO for Arch and will try compiling on that to see what happens.

[EIREXE]

I discovered that indeed you are supposed to compile on 16.04, I will be swapping my VM for a 16.04 one.

[Gramps]

Did swapping your Ubuntu distro work out?

[EIREXE]

Hi again, I tested yesterday compiling in ubuntu 16.04, the game unfortunately still crashes on windows, here's the template build:

https://files.catbox.moe/l6wpwl.zip

[Gramps]

Hmm, that example doesn't run because there is no .pck file and it is looking for it. Also I thought the problem was that running the project from the editor caused a crash?

[EIREXE]

No, the game never ran on windows directly, even if there is a pck file next to it of the same game it doesn't run with Steam open (but if steam is closed it does run).

[alperc84]

for proper scientific method, you must upload the game with all files. pck file, steam_api64.dll, steam_appid.txt and game executable. (maybe we need to see project file too).

so we can reproduce the same error in different pc.

[EIREXE]

steam_appid.zip

This is all I can provide :/

[Gramps]

Without the .pck file the game will never run. All components are needed to test or else there is nothing I or anyone else can do.

If it crashes when Steam is open, there is some failing implementation in your Steamworks code, most likely. You will have to show some code to be able to pinpoint where and why.

[Gramps]

I got a notification you said:

My apologies, I may have mixed versions, the ubuntu built version does work on windows

But that comment is now gone. Did it actually not work?

[EIREXE]

https://files.catbox.moe/qmeeai.7z Here's a build of the default steamworks one that crashes.

[Gramps]

Well, sending a compiled build doesn't really tell me anything or help, honestly.

If you can't provide a code base I can look at or actually answer any of the previous questions I or anyone else asked, then I will close this issue. I also cannot reproduce it so cannot verify it is an actual problem.

[MaxCorpEnjoy]

Hi, same issue as @EIREXE here.

I am running on Ubuntu 18.04, with gcc 7.5.

Everything is fine when I compile for x11, but I start to see issues when cross compiling for win64:

• getSteamID() -> causes crash
• getAppOwner() -> causes crash
• getStatInt() -> always returns 0
• setStatInt() + storeStats() -> does not update Steam stats

Some other getters are okay, like getPersonaName(), loggedOn(), getters and setters for Achievements are also fine, and the steam overlay seems to be working

Interesting is that connecting to user_stats_received, we get the appropriate steamID from (game,result,user), but calling getSteamID() will still cause a crash afterwards.

A small example would be what @Gramps proposed in the tutorial, but can even be reduced to :

func _ready():
    Steam.steamInit()
    Steam.getSteamID()

I checked the precompiled version from last week (3.4), and it works perfectly fine.
So I cloned a clean godot repo, with the 3.2 branch state of today, added only godotsteam with the 1.48 sdk and tried again to no avail.
--> Linux builds work fine (editor+release), Windows builds crash (editor+release)

On Jan5, I guess @Gramps got the same result.
Was the rootcause found in the meantime, or is the precompiled version compiled from windows ?

I will continue to investigate.

Edit: I only get pragma warnings and a warning for the redefinition of __cdecl:
modules/godotsteam/sdk/public/steam/steam_api_common.h:56:0: warning: "__cdecl" redefined
Which is basically:

#if defined( POSIX )
#define __cdecl
#endif

[Gramps]

@MaxCorpEnjoy Thanks for the new information. Very strange that those two functions cause crashes since they are the most basic. Still not 100% how to even approach solving it, but narrowing it down is good.

The pre-compiled version are always from their native operating systems. I never cross-compile anything; but not really for any particular reason other than I dual-boot.

Yeah, couldn't get the pragma warning on Linux to be quiet and the redefinition warning I haven't seen, but if it's in the Steamworks API there isn't much we can do about it.

Armed with this new information I will see what I can dig up this weekend. I guess for production releases only use non-cross-compiled templates and editors until we sort this out.

[eh-jogos]

Hi I'm having similar issues, and I tried compiling on windows and I'm getting some errors I don't understand, I just posted a separate issue about it!

Just wanted to add here that while I don't have enough knowledge to help with this, I can provide access to my game's steam version repository if it helps! I just started to integrate steam to my game so all I have is the basic Global implementation to initialize steam as in @Gramps tutorial and nothing else steam specific! So I'm assuming game is crashing because of STEAM_ID = Steam.getSteamID() as it's the only method I'm using from @MaxCorpEnjoy's list.

I'm basically having the same problem, Linux works fine, windows doesn't. I got the same pragma and __cdecl warnings as well, only when trying to cross compile.

I haven't tried building on windows with the precompiled version yet, but if there's anything I can do to help narrow down this issue, just ask! It would be really comfortable to be able to build everything from linux and only use windows for testing and bug fixing windows specific problems.

By the way, on linux I'm on a manjaro distribution.

[Gramps]

Hey there! Yes, this issue is still rather puzzling and on-going issue that only seems to affect cross-compile for Windows from Linux. I'm not sure if it's strictly the cross-compiling or MinGW or what.

For the time being, I would suggest people just use the pre-compiled version in the release section if they cannot native compile. At least until we figure out what is going on.

While I don't need access to your game's repo, could you possibly share the compiled editor and template you get that fail to work on Windows?

Also, I totally understand; I am a primary Linux user!

[eh-jogos]

Sure! It'll take some time though, I actually deleted them in the process of trying to compile natively on windows, but I'll soon restart my computer on linux and build them again / test to see if I got the same result and if so post them here!

[eh-jogos]

Ok here is a link to a google drive folder with the cross compiled editor and templates, and a wndows natively compiled editor that opens my project but doesn't run the game on F5 unless I comment out getSteamID()

the scons command I used to build this last one was
scons -j12 platform=windows target=release_debug use_lto=yes use_mingw=yes

[Gramps]

Hey there. OK, so you got as far as I did with it then; for cross-compile that is. As to why getSteamID causes a crash is a mystery since it is an incredibly simple function. There isn't really anything that can change with the function either.

I will check out the files you uploaded at some point today to see if there are any other weird similarities to my cross-compile tests.

[MichaelBelousov]

FWIW, I seem to be having this same issue compiling with use_mingw on pure windows.

[Gramps]

Yeah, my current going assumption is that somewhere in the process of using MinGW something goes terribly wrong. I don't know what or how, but that seems to be the common point of the problem. Upon my next update for the documentation, I will probably put a warning in there for people to not use it at all, especially for cross-platform.

[MichaelBelousov]

Before I switched to MSVC a couple hours ago, I ran it through gdb and a segfault occurs 2 functions (I forget which) into the steam_api.dll, It probably wouldn't be easy to find out more though.

[Gramps]

Hmm, thanks for the info. I know getSteamID has some weird issues in certain circumstances, which is odd since it's so simple. What is GDB?

[MichaelBelousov]

Gdb is the gnu debugger, the native debugger for part of the gnu tools which is often used on Linux for c++ development with gcc. (mingw actually means MINimum Gnu for Windows so in addition to compiling with gcc, you can debug with gdb). I was using the mingw gdb on windows.

[Gramps]

Ah, gotcha. I use Linux primarily for development but clearly not the debugger. Except checking linking and dependencies.

[Gramps]

OK folks, I can finally confirm that compiling with MinGW does indeed causes crashes (as we are all aware) with Steamworks. You can read more about it in this issue, with a link to subsequent posts about it.

As I think I said earlier... do not use MinGW to compile for Windows. It will end in crashing. I have updated the readme to reflect this and will be updating the documentation as well. Since this is something in Steamworks, I'm not sure it can be fixed in GodotSteam itself. Supposedly changing the Steamworks header can be a work-around but I'm not going to suggest that to folks.

When or if this gets resolved I will remove the warning, but until then only use MinGW at your own risk.

[MichaelBelousov]

Would you be opposed to ever having a branch of godotsteam (probably if someone volunteers to maintain it) with support for mingw using the header manipulation? I haven't looked into it a lot yet but I would be very happy if I could compile with mingw and would invest some time in trying to make it possible.

[Gramps]

As far as I understand it is something that needs changed in the Steamworks header, nothing in GodotSteam. I'm still digging through the various posts about it seeing if there is something else that can be done.

For now, I think the best way to bridge the gap is to write up a small list of instructions on what to change so that folks who want to do so can fairly easily. From what I read, it's just making a minor change in the steam_api.h file.

[Gramps]

Hmm, so someone in one of the threads mentions they fixed the issue in OpenSteamworks. He points to this bit of code:

// returns the CSteamID of the account currently logged into the Steam client
// a CSteamID is a unique identifier for an account, and used to differentiate users in all parts of the Steamworks API
STEAMWORKS_STRUCT_RETURN_0(CSteamID, GetSteamID) /*virtual CSteamID GetSteamID() = 0;*/

Essentially replacing line 33 in isteamuser.h. Since you have MinGW all set up, try swapping that line out and seeing if it fixes the issue. If so, I will add this workaround into the documentation and readme so folks with MinGW have an option.

[MichaelBelousov]

Sorry when I said branch of godot steam I meant like with separate documentation and perhaps some scripts for automating the process about using mingw with the modified headers.

I'll try your suggestion above at some point tonight, and report back.

[Gramps]

Ah, gotcha. Well, if this fix works I'm going to add it in the documentation along with other notes; similar to Mac OS and Linux caveats. Let me know how it goes!

[MichaelBelousov]

@Gramps can you provide a link to the thread? (I tried what I believe to be the line swap, and it's not compiling, some additional context would help).

[Gramps]

The thread here only really specifies this link that shows how OpenSteamworks fixes the issue: https://github.com/SteamRE/open-steamworks/blob/master/Open%20Steamworks/ISteamUser017.h

Line 44 is what you're looking for. If it errors out the compiling then I'm not quite sure what to try next.

[MichaelBelousov]

Started looking into it more deeply now, I didn't have enough time yesterday after a github search of the open steamworks repo didn't find the definition for that macro. However, I did find it with grep on the repo, I've extracted it, and it's compiling now. As for the thread, I somehow can't open that communities link since I am not a member of the community, but I can't find it for joining either... Maybe I'm just poorly navigating the communities interface to try to find what I assume is the "steamworks" community, but I wasn't able to. Anyway I'll still have something to report later today once I test it.

[Gramps]

Hopefully the compiling works!

Yeah, that community group is for folks who have games on Steam. If you don't have a game or have purchased an app license then you can't read thread or join the group. I think, after you have done so, you are automatically added?

[MichaelBelousov]

It does in fact seem to work, GetSteamID did not segfault. I had to copy this macro from Open SteamWorks to the start of isteamuser.h, and then perform the line substitution.

[MichaelBelousov]

I will hopefully be developing with this a lot so I can create issues if I run into other functions that don't work besides GetSteamID

[Gramps]

Well that sounds pretty promising. So you took the whole macro and made the other change in isteamuser.h?

[MichaelBelousov]

Yep, I actually just copy and pasted the entire conditional section, here's the file.
isteamuser.h.txt. You could definitely trim it down, but I assumed it would be easier in the tutorial to not separate the conditional branches or something. I suppose for the tutorial you'll need to provide an exact snippet anyway.

[Gramps]

Awesome. I have saved it and will create a new MinGW tutorial as well as link it in the how-to sections. Glad to hear that sorted out the issue.

If it's all fixed up, I will make those changes tomorrow and close the issue.

[MichaelBelousov]

it would be nice imo if you provided a bash, powershell, or python script to automatically apply it. something like:

• user puts godotsteam in godot trunk
• user puts sdk in godotsteam
• user runs script to automatically apply the patch, or has to do it manually

[MichaelBelousov]

maybe @EIREXE could confirm that it works on linux cross compiling to windows before closing this issue maybe?

[Gramps]

Automated scripts would be cool, I'll definitely add that to my to-do list.

[MichaelBelousov]

Want me to submit a PR for that to the trunk? Any particular language or maybe multiple? like mingw-patch.sh and/or mingw-patch.psh and/or mingw-patch.py?

[Gramps]

Sure, if you'd like to take it on. Perhaps a new folder called mingw-patch with whatever languages you see fit. If you only do one, you can skip the folder. I'm not sure which languages are most convenient for it.

[MichaelBelousov]

I want to go with bash but I think I'll go with python since it's easy to install and most people have it cross platform unlike bash with windows users and powershell isn't popular on linux.

[Gramps]

Sounds good to me, sir!

[Gramps]

Patch file is added and this issue should be closed now. If anyone has any further issues, please re-open this issue or create a new one.

[zombieCraig]

FYI @MichaelBelousov Running the script didn't seem to fix the problem. I copied your isteamuser.h.txt full file and replaced it and that did the trick. There maybe a substitution or something that still needs to happen in the script for it to work.

[MichaelBelousov]

I'll look at it tonight, (try it again from scratch), could you provide your isteamuser.h file? Also your python version?

[Gramps]

Patch might need patched? I haven't looked at it too carefully and haven't run it since I don't use MinGW. Working on getting the next GodotSteam version together for upload this weekend.

[MichaelBelousov]

I've been running into issues with godot's platform detection on msys2's python distribution so sorry I haven't been able to confirm anything yet. Probably will finish it some time tomorrow. I at least ran the script and it _looked_ fine, but I'll still be checking everything on this new machine.

[Gramps]

No rush on my end. Still working on the next update. I will mention the patch in the upcoming MinGW tutorial as well as what is changed particularly.

[zombieCraig]

@MichaelBelousov I overwrote it with yours but happy to restore and try again. I was having some problems with Scon not cleaning properly scons -c so I did a find . -name '*.o" | xargs rm` to ensure a clean build. Your patcher seemed to have patched and compiled but I just ended up with the same result. I copied the .txt from above over top and did a full clean and rebuild and it worked. Which unblcoked me so I excited switched gears and start fixing stuff :)

I posted here to give you a heads up but happy to test again. I really wish github had DM capabilities. Are you on Godot's discord? It takes me awhile to see updates here.

[MichaelBelousov]

MikeBelousov#5804 on discord and Godot's server ofc. Feel free to provide relevant information or ask for updates. I just posted an issue on godotengine/godot about my problem with platform detection on msys, but I'll look into it myself more tomorrow.

EDIT: platform detection problem was (of course) on my end, I just had different python os.name = "posix" and sys.platform= "msys" variables on the different machine (compared to usual "nt" and "win32", so I wasn't sure if scons wasn
t detecting the windows platform because of that, I just forgot some mingw64 dependencies on the new environment. I'm building and should know what's going on soon. Except I just ran into an msbuild dependency issue :)

[MichaelBelousov]

@zombieCraig it really does seem to work for me, (at least getting the steam id), could you send me the resulting isteamuser.h after you apply the patch and upon it failing?

[zombieCraig]

@MichaelBelousov Attached.
isteamuser.h.txt
As you can see the patch puts in the macro but didn't update GetSteamID to STEAMWORKS_STRUCT_RETURN_0(CSteamID, GetSteamID) It never calls the macro.

[MichaelBelousov]

@zombieCraig what's are your python and steamworks versions? I'm running python 3.8.2 and it does correctly use the macro. Maybe there's a python version issue? Your version of the header looks like it should work with the script...

[MichaelBelousov]

actually wait I definitely missed something about your resulting header file. It looks like the macro is placed at the bottom, I may have made an assumption that iirc python normalized the line ends of files so 'n' is sufficient on all platforms, and I'm matching on that. Maybe that's the issue, looking into it.

[MichaelBelousov]

probably windows python was expecting '\rn' so the string I partition on to place the macro didn't work. I'll try to remember what environment I thought of normalized line endings, but I'll send you a fix and put up a PR soon.

[Gramps]

Patch is updated!