-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Printing to stdout/stderr fails with SDL import on Windows #86
Comments
Can't reproduce:
I used an MSYS2 package install for SDL rather than those steps, but I don't think that's relevant -- it's the same library (right down to needing that replacement On the other hand, I'm using all 64-bit, and if you followed those instructions 100% you're using 32-bit. It's definitely plausible for there to be a bug in one but not the other. If that's not it, a broader inspection of the differences in our configurations might be helpful, though I'm honestly not sure what to look for. |
Hmm I tried reinstalling sdl2 w/ 64-bit GHC + libraries w/ the instructions above but running the above program yields the same result, not printing anything. Are you using the v2.0.0 bindings @tejon? |
At a quick glance, this looks a lot more like an issue with your tooling/compiler than something in sdl2. The sdl2 library doesn't execute any code at all when simply imported. |
Everything I have was installed fresh yesterday, from github. Bleeding-edge current. :) What happens if you import some other module? Try |
@tejon changing the import to Oddly in ghci I can @polarina I checked the source and you're right I don't see any code running. This is very confusing |
I have the same issue on windows 7 building with GHC 7.10.2. The problem occurs with both 32 bit and 64 bit SDL. The files I used to build are here: https://www.sendspace.com/file/xxg33j The wacky_***_.bat files build/run the examples and all four of them reproduce the problem on my machine. |
Thanks. I have a window machine now so may be able to work on this. On Mon, 9 Nov 2015 11:38 pm redxaxder notifications@github.com wrote:
|
It seems this is an intentional SDL feature: http://sdl.beuc.net/sdl.wiki/FAQ_Console A workaround is for windows users to recompile SDL with the right incantation. However, the import shouldn't be triggering this behavior for sure. I'd guess there's a call to SDL_Init() hiding in the top level of the Haskell bindings. |
@redxaxder just importing a package shouldn't evaluate any top-level declarations, even with |
Hi Could SDL2 be redefining a symbol? (for example, SDL2 defines main) Does the same thing happen if you use dynamic vs static linking? (the Ivan On 16/09/15 21:41, nxths wrote:
|
I have this problem too. I'm on Windows 10 64-bit with 64-bit GHC and SDL2 2.03. EDIT: |
I don't have this issue anymore when installing SDL2 2.0.4 w/ stack, following https://www.reddit.com/r/haskellgamedev/comments/4jpthu/windows_sdl2_is_now_almost_painless_via_stack/ |
Closing since this is reported fixed. |
I am experiencing the same problem on windows 10, even when I installed via stack as explained in the post linked to by @nxths. |
Same issue here with the latest sdl2, Windows 10 64bit. |
Same issue on win7 64 bit |
This issue stems from the user's system configuration of SDL2. For my case, I installed SDL2 via msys2 (mingw64) and have the mingw64 tools in my path such that they come before Haskell Platform's mingw64 binaries. My guess was that cabal would use For whatever reason, the mingw64 package is set with the option
So you can supersede this option by appending
Then in my cabal store, I deleted sdl2 to force it to reinstall with this changed configuration:
Rerunning the build. Note the final line is some
I do not know how to set up my own cabal files such that dependent libraries are passed |
With a little extra research, I found that linking is done with ghc, so the flag can be passed with ghc-options (see haskell/cabal#1865). In my project's cabal file I added:
Or from the command line:
Of course if you did any of the above that I suggested in the previous comment, undo that and delete sdl2 from the cabal store again. |
Another caveat, cabal new* seems to have some issues and this option could get stuck on. Use this to get the Windows behavior back:
|
I'm using stack, and adding My project is using Thanks @cromachina! |
Is there any way to make this the default behaviour for programs using this package? The behaviour is very surprising, and the plerthora of ghc/windows/utf8/crummy-cmd.exe bugs provide plenty of red herrings when trying to troubleshoot the exceptions thrown and messages not printed. Perhaps a visible notice in the readme could help if there's no technical solution. |
Just turn on Don't add For cabal, we must delete |
When importing SDL the following program will no longer print anything:
Removing the SDL import will print as expected. My linux box's 256MB of ram is insufficient to compile the bindings so I'm assuming this issue is Windows only otherwise someone would have already noticed. I installed the bindings on Windows with these steps.
Most likely the stdout/stderr (and probably stdin) handles are getting clobbered somewhere, causing the apparent no-op? Replacing the print in the above program w/ trace similarly yields no output. Not that familiar w/ the FFI, but do the handles need to be explicitly preserved when interfacing w/ C code (e.g. SDL2)? Creating new file handles and reading/writing to them do not have any issues w/ the SDL import, fwiw
The text was updated successfully, but these errors were encountered: