search

CapsCollective / raylib-cpp-starter

A portable, automated template for raylib projects with C++ bindings
Other
68 stars 17 forks source link

Fix broken dll's on windows #5

Closed mTvare6 closed 3 years ago

mTvare6 commented 3 years ago

According to this issue and when compiling on my system, it says broken dll's. Adding few compiler flags fix it.

jonjondev commented 3 years ago

Hey @mTvare6, thanks for popping up with a PR! Our resident Windows guy @Raelr will be able to check it out and hopefully merge it in a few days from now (whenever he's back online). In the interim, could you describe the issue for him to test against?

mTvare6 commented 3 years ago

So I don't use windows myself, but a friend of mine who is using windows couldn't compile manually so we used github artifacts and exported it image but that gave this error, so after few stackoverflow searches we found the so answer and added those flags then later when exporting github build artifact it built and he was able to run

Raelr commented 3 years ago

Hey @mTvare6,

Thanks for opening this up!

I've reviewed your request and it all seems fine to me! Before merging, I was just wondering whether you could clarify a few details for me?

1) You mention that your friend wasn't able to compile the project. Would it be possible for you to ask them what their original error was, and if possible copy/paste it to this thread? 2) If I understand you correctly, you used Github Artifacts to get the project build from our Github Actions? Did you get the project itself, or just our main libraries?

My apologies for dragging this out. We've seen a few Windows-related issues and we'd like to get to the bottom of this so that folks like you don't need to go through Github Artifacts in future!

mTvare6 commented 3 years ago

Yep, so we were 3 people, 2 windows and 1 mac, one of us using windows was able to compile, but the other wasn't and got the following error

Makefile:590: recipe for target 'raudio.o' failed
mingw32-make[1]: *** [raudio.o] Error 1
mingw32-make[1]: Leaving directory 'C:/Users/name/project/vendor/raylib-cpp/vendor/raylib/src'
Makefile:74: recipe for target 'lib' failed
Raelr commented 3 years ago

Hey @mTvare6,

Thank you so much for providing the extra information!

Strange that it only worked on one of the Windows machines. We've seen the raudio.o error before, but it seems to always show up when compiling raylib itself.

Out of interest, I wonder whether your friend would be able to try and compile Raylib by itself? I believe the exact commands and instructions can be found here.

If they CAN build it independently then it might be indicative of an issue with our makefile. Would you be willing to give that a shot, or would you rather we leave the case as-is? I don't want to keep you here for too long, but any further info you can supply would be insanely helpful!

Thanks again!

mTvare6 commented 3 years ago

I am extremely sorry, he seems to be busy, I prefer leave the case as-is.

mTvare6 commented 3 years ago

@Raelr would It be nice if the github workflows in this template builds artifacts by default.

jonjondev commented 3 years ago

Hi @mTvare6, I've been loosely following the thread here and I wanted to jump in with a few notes.

The code you've submitted doesn't appear to make any changes to the build as far as we've tested, which is good, but we don't really know what any of the flags (-static -static-libgcc -static-libstdc++) are doing, let alone how to reproduce the issue on our end.

Additionally, you're saying that you pulled in prebuilt libs that were compiled on another machine (the Github artefacts) and then tried to patch them into you friend's build, which is not ideal for users and we should go about trying to fix the root problem, which is that raylib is not compiling correctly; potentially due to this framework, but as @Raelr believes, more likely a problem with raylib or the machine itself as this issue occurs on a subset of Windows machines.

It's great to see that you found a workaround to the problem for your friends, but ultimately implementing a workaround just obfuscates the real problem at hand, so if you could help us diagnose the issue that was preventing the use of the framework in the first place, that would be much more helpful to future users like yourself. It may even be a good idea to put your solution into a troubleshooting doc with a bit of explanation for anyone who tries the workaround, and maybe a walkthrough of it for less technical individuals.

We really don't want to be difficult about anything, but we want to make everything transparent and robust so that new programmers will have a super easy time getting a start in the world of games programming!

mTvare6 commented 3 years ago

Let me soon try to reproduce, but the reason for gh build is because he wasn't able to compile. Leaving that the reason for this PR is because when exporting a standalone build to run game on any machine it gives the dll error, the unable to compile raylib is totally different problem.

I didn't patch the libs, just build the exe to run

jonjondev commented 3 years ago

Ok, I'm starting to understand the situation you were in. Correct me if I'm wrong, but the timeline is:

  1. You could not build raylib on Windows [issue]
  2. You pulled a lib from the runner to build with
  3. You compiled the bindings using the starter script, which worked
  4. You attempted to run the resulting executable on a different machine, where it could not find DLLs [issue]

If this is correct, then we have a scenario we can test against! Looks like MinGW tools could possibly not be functioning as expected without specific flags. But as unlikely as it is, the situation does not preclude the possibility of the GitHub lib frankenbuild being at fault, since g++ should already be linking it statically according to all possible documentation...

mTvare6 commented 3 years ago

I don't exactly understand what you mean by 2, 3 point, but what happened is I just added the github-upload-artifact to export the built binary before make clean in actions build

The workflow was the github workflows in the template project with additional export artifact image The artifact is build there, and run on different machine

Also according to stackoverflow answer, this lets it run without mingw installed on system

jonjondev commented 3 years ago

Thank you for clarifying that, @mTvare6. We were able to successfully reproduce your issue and prove that that the flags you added solved it! We'll go ahead and merge the fix now, but please let us know if you're ever interested in helping us diagnose that Windows build issue. Thank you for contributing and we appreciate you baring with us while we tried to understand what happened.

mTvare6 commented 3 years ago

afaik it seems his installation of mingw is broken because other person was able to build.

Also should I make another PR or you yourself change it so the github actions also exported the compiled binary( it isn't a loss for anyone, because its just exporting binaries ) so they will also be able to download and run even if they don't have compiler or whatever