Windows 7 support

[cogthecat]

Following the instructions provided on the main GitHub page to install MSYS and build Avara on Windows 7 x64, but the make and make winapp commands produce the following output respectively:

$ make mkdir -p build/src/audio/ clang++ -Isrc/audio -Isrc/base -Isrc/bsp -Isrc/compat -Isrc/game -Isrc/gui -Isrc/level -Isrc/net -Isrc/util -Isrc/util/huffman -Ivendor/glad -Ivendor/nanovg -Ivendor/nanogui -Ivendor -MMD -MP -g -Wno-multichar -DNANOGUI_GLAD -fPIC -std=c++1y -c src/audio/CBasicSound.cpp -o build/src/audio/CBasicSound.cpp.o clang++: error: unsupported option '-fPIC' for target 'x86_64-w64-windows-gnu' make: *** [Makefile:86: build/src/audio/CBasicSound.cpp.o] Error 1

$ make winapp mkdir -p build/src/audio/ clang++ -Isrc/audio -Isrc/base -Isrc/bsp -Isrc/compat -Isrc/game -Isrc/gui -Isrc/level -Isrc/net -Isrc/util -Isrc/util/huffman -Ivendor/glad -Ivendor/nanovg -Ivendor/nanogui -Ivendor -MMD -MP -g -Wno-multichar -DNANOGUI_GLAD -fPIC -std=c++1y -c src/audio/CBasicSound.cpp -o build/src/audio/CBasicSound.cpp.o clang++: error: unsupported option '-fPIC' for target 'x86_64-w64-windows-gnu' make: *** [Makefile:86: build/src/audio/CBasicSound.cpp.o] Error 1

[assertivist]

Hey @cogthecat, thanks so much for downloading and trying to build the game.

This is actually a Makefile problem. Basically what is happening, is that your build is skipping the Windows build invocation and hitting the baseline Linux build invocation, where we definitely need -fPIC. We use a couple specific strings to check whether or not we're building on MSYS2, and it's not really ideal. I typically have to modify this string to whatever uname returns when I am setting up on a non-Windows 10 system. Here's what I want you to try:

• Make sure you are using MSYS2, because regular MSYS sucks and will probably not work correctly.
• After you confirm that or install it, run uname to get the string that should go in the Makefile and catch the windows build options
• Go to the Makefile, line 21 and replace the "MINGW64_NT-10.0" string with what you got from uname.

You should be able to build after that. Or at least run into another error... it has definitely been reported that Win7 doesn't like our current binaries, which are built on NT-10.0 as well, but please feel free to try those if you can't get it building.

We need a really good check to see if we're building on MSYS2 to set proper flags (for example, excluding -fPIC).

Anyway, I hope this at least gets you building. You may run into more issues building on Win 7 simply because no one of us has it available for testing. Let us know and thanks again!

If you get it building, the output from your uname will be helpful info for fixing this permanently. I think we need to search that string for NT-x for some minimum version, but the lowest I've seen it working is 10.0 so far.

[rherriman]

Clearly this is an issue, but I did want to mention that if you are just wanting to get the game up and running @assertivist has some builds available here: https://vastan.net/avara-builds/030119_everyone_download_this_one/

[cogthecat]

@rherriman - @assertivist is correct that Windows 7 is unable to run the version located at the link you specified, which is actually what I tried before touching the build-from-source process outlined here. However, as he guessed, the uname for the MSYS2 version I've installed (which appears to be up to date) is MINGW64_NT-6.1 and correcting the makefile to that appears to have worked without issue. However, running build/Avara now results in the following:

$ build/Avara Segmentation fault

Any ideas on that one?

[assertivist]

@cogthecat Thank you for trying that! I had a bad feeling this was going to happen. It could be any number of things really, I think if it was a problem with GL drivers that you might get more info than that but I can't be sure without running a debugger. This is going to have to wait until I set up a Win 7 VM.

If you want to help us with this, you can run gdb build/Avara, (you might have to install gdb in MSYS2) then type run into gdb and let us know where exactly the segfault occurs (it should give you a method name or something hopefully--if not, do a bt and send that).

Note that running in gdb on MSYS2 will be quite slow

[cogthecat]

Okay, here's the output of that tool; it went quite quickly since it apparently failed on the first instruction:

(gdb) run Starting program: /c/Users/Jacob/Desktop/Avara-master/build/Avara [New Thread 17936.0x3434]

Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt

0 0x0000000000000000 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)

[assertivist]

Yikes, alright. I'm in the dark here but I'll work on getting that Win7 VM setup, for the sake of you and that other person :)

[assertivist]

Here's the result I got doing the same thing (though in this example i changed the color bit depth to see what would happen):

Reading symbols from build/Avara...done.
(gdb) run
Starting program: C:\msys32\home\IEUser\Avara\build\Avara
[New Thread 4076.0x5c4]
[New Thread 4076.0xa94]
[New Thread 4076.0xfe4]
[New Thread 4076.0xc1c]
[New Thread 4076.0x8b8]
[New Thread 4076.0xce8]
warning: INFO: OpenAvaraTCP
[New Thread 4076.0xe64]

Thread 1 "main" received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x00524679 in nanogui::Screen::initialize (this=0x294d690,
    window=0x29508b8, shutdownSDLOnDestruct=true)
    at vendor/nanogui\screen.cpp:225
#2  0x00524311 in nanogui::Screen::Screen (this=0x294d690, size=...,
    caption=..., resizable=true, fullscreen=false, colorBits=8, alphaBits=8,
    depthBits=16, stencilBits=8, nSamples=0, glMajor=3, glMinor=3, fps=60)
    at vendor/nanogui\screen.cpp:197
#3  0x00489cde in CApplication::CApplication (this=0x294d690, title=...)
    at src/gui\CApplication.cpp:19
#4  0x00440444 in CAvaraApp::CAvaraApp (this=0x294d690)
    at src/game\CAvaraApp.cpp:38
#5  0x0056fc0a in SDL_main (argc=1, argv=0x2946420) at src\Avara.cpp:64
#6  0x005712e4 in main_getcmdline ()
#7  0x005713f5 in WinMain@16 ()
#8  0x0057b7cd in main (flags=1, cmdline=0x1951878, inst=0x1951b08)
    at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18

This is in the SDL Initialization of our 3rd party GUI library... flipping some window initialization parameters around and seeing if i can get it to run.

@cogthecat For what its worth, I'm getting this stacktrace by building in 32-bit MSYS2 (that's just the VM I got from Microsoft)--you may want to try building it in 32-bit mode as well, maybe you can get farther than I am currently.

[assertivist]

OK so I figured out why my VM segfaults at least, and it has to do with the supported version of OpenGL. We are targeting 3.3, and nanogui requires 3.x minimum (via nanovg).

@cogthecat to check what version of OpenGL your machine supports, download the GLView utility and check to see that it supports core features past 3.0. If it does not, and your graphics card is capable of supporting it, you should be able to upgrade your graphics card drivers and get 3.x support in Win 7.

It's pretty impossible to run the game without this though, as our shaders also target 3.x, and we use the high-DPI support features for Retina display on MacOS.

This could either be the reason or one of many reasons we can't run on Win7

[assertivist]

I feel like my choices here are limited to leaving this open for 8 months until it gets closed because Win 7 is EOL, or just closing it now, because I kind of doubt we'll be removing or backporting our principal GUI library.

So I'm closing it. No hard feelings, I hope that you are able to come join us again from another OS or once you are able to upgrade to Win10. Thank you again for the report and your help troubleshooting.

[cogthecat]

It's a little mind-boggling that Windows 7 on decent hardware can't run Avara of all things, but it's certainly not your fault that those challenges are in the way. I'm a little confused as to the actual issue, though, since GLView shows that I've currently got version 4.6 installed. Just in case I'm updating my NVIDIA drivers now, but I doubt that would make much difference in this instance.

So that we're clear, you're saying that since the issue on your end appears to be an OpenGL versioning issue there's nothing you can do to continue investigating whatever's going on on my end? Or is there something else I can do to get this up and running?

Edit: just noticed your suggestion to build in 32-bit mode. I assume that'll require me to install the x86 version of MSYS2?

[assertivist]

Pretty much--I just don't have access to hardware running Win7. Even my work environment is Win10 now. You're totally welcome to keep looking at this, I can only offer suggestions though. I'm really glad that you have OpenGL 3+

I closed because i was thinking that OGL was the issue. It clearly isn't for you, you should be able to open a 3.3 context, so I would yes suggest building in 32-bit, by installing MSYS2 i686, and then try gdb again. Basically without a better backtrace its really hard to figure out what to do.

You're totally right, its weird that you wouldn't be able to do such an old game in Win7, but the issue I ran across in my VM isn't the game code but the rendering context code, which is all us, and we're not graphics engine wizards--We just picked the best looking (from aesthetic and also API standpoint) GUI library and went with that. Our shaders are also really basic, just to get stuff drawing on the screen correctly so we could work on other things. But we followed modern OpenGL tutorials, which target newer versions. There was an experimental port of the original drawing code which is all software rendering but it was MacOS only and I'm certainly not smart enough to understand how it works :)

I was going to suggest trying BSPViewer but it looks broken right now.

cross platform support is hard

[cogthecat]

No worries, I was mostly pointing out the irony that technology so often abandons the best parts of its own history in the pursuit of the latest and greatest. Getting MSYS2 x86 set up is going to take a bit, but I'll report back either way.

Thank you for your time helping sort this issue out, and for helping bring Avara into the present-day!

[cogthecat]

Welp, now we have this:

$ make winapp mkdir -p build/src/audio/ clang++ -Isrc/audio -Isrc/base -Isrc/bsp -Isrc/compat -Isrc/game -Isrc/gui -Isrc/level -Isrc/net -Isrc/util -Isrc/util/huffman -Ivendor/glad -Ivendor/nanovg -Ivendor/nanogui -Ivendor -MMD -MP -g -Wno-multichar -DNANOGUI_GLAD -fPIC -std=c++1y -c src/audio/CBasicSound.cpp -o build/src/audio/CBasicSound.cpp.o make: clang++: Command not found make: *** [Makefile:86: build/src/audio/CBasicSound.cpp.o] Error 127

That's occurring in the 32-bit version of MSYS2 when running in the same Avara source directory as the 64-bit version. Running it without renaming the existing 64-bit \build\ directory produces this output:

$ make winapp cp -r bsps levels rsrc shaders build rm -rf build/WinAvara mkdir -p build/WinAvara if [ -f build/Avara ]; then mv build/Avara build/Avara.exe; fi mv: 'build/Avara' and 'build/Avara.exe' are the same file make: *** [Makefile:62: winapp] Error 1

Attempting to build using the existing directory produces the following two outputs, in order:

$ build/Avara C:/Users/Jacob/Desktop/Avara-master/build/Avara.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

$ build/Avara bash: build/Avara: No such file or directory

I'm more than slightly confused as to why it misbehaves this way, even after I've updated the uname line in the makefile to match the 32-bit MSYS2 installation (MINGW32_NT-6.1-WOW), but truthfully this is all sailing straight over my head since this sort of thing isn't really my wheelhouse generally.

[assertivist]

clang++: Command not found -- you probably don't have the 32-bit compiler installed. You can install the i686 development packages you need with this: pacman --noconfirm --needed -Syuu zip mingw-w64-i686-SDL2 mingw-w64-i686-SDL2_net mingw-w64-i686-clang mingw-w64-i686-glbinding mingw-w64-i686-glew make

You definitely also want to do a make clean before you switch between 64 and 32 bits build. Otherwise weird stuff will happen I think.

Also just a heads up, if you have a nice machine with a lot of cores, you can tell make to use more cores to make it go faster. make -j<number of cores +1> I normally do make -j3 cus I only have a dual core machine.

Thank you for being so patient with this--I understand this is pretty convoluted.

[cogthecat]

Finally got Clang++ installed in the 32-bit shell; the output of make winapp is now as follows:

$ make winapp mkdir -p build/src/audio/ clang++ -Isrc/audio -Isrc/base -Isrc/bsp -Isrc/compat -Isrc/game -Isrc/gui -Isrc/level -Isrc/net -Isrc/util -Isrc/util/huffman -Ivendor/glad -Ivendor/nanovg -Ivendor/nanogui -Ivendor -MMD -MP -g -Wno-multichar -DNANOGUI_GLAD -std=c++1y -c src/audio/CBasicSound.cpp -o build/src/audio/CBasicSound.cpp.o In file included from src/audio/CBasicSound.cpp:13: src/audio/CSoundMixer.h:15:10: fatal error: 'SDL2/SDL.h' file not found

include <SDL2/SDL.h>

     ^~~~~~~~~~~~

1 error generated. make: *** [Makefile:86: build/src/audio/CBasicSound.cpp.o] Error 1

Looks like it isn't able to find SDL2 now? I apologize for being such a pest, but this just does not want to work for me so far.

[assertivist]

@cogthecat I have two builds for you to try:

here's a 32 bits: https://drive.google.com/file/d/1gmkj9AParAeh3tSod3IYaY_Est95KCfE/view?usp=sharing

and here's a 64 bits: https://drive.google.com/file/d/1v_sb4FQtnNWc47R1lNuv-uB_jW-hx117/view?usp=sharing

Try both of them and see if they work. I made these by cross-compiling from GNU/Linux with the same compiler I've been trying to help you install. Everything is linked statically with these, so no DLL files and hopefully it should run on Win7.

MXE looks like the best way to make release builds. I still like the MSYS2 builds because they include a console window, but I might just need to specify some option to get that from the compiler on Linux.

[assertivist]

I had another friend with a Win7 laptop try these and he said that they didn't work. Give them a shot anyway... he may have not had the right OpenGL support.

[cogthecat]

No dice, unfortunately. Looks like it crashes very similarly to the other pre-built version linked earlier.

[assertivist]

My next long shot is to build with Visual Studio. This is proving quite difficult but it's probably for the best long term for Windows builds since we can actually sign them and stuff. I'm not a Windows developer so I'm pretty much learning as I go along. I dunno if you have any experience with Visual Studio but I will be publishing the branch i'm working off of to my repo soon.

[assertivist]

Just a quick update since it's been two weeks. I worked on the code until I got VS to give me a binary. This binary doesn't work though, even for me, because I have some DLL issues. Still working out how to properly get dependencies loaded correctly. Hopefully once I get that figured out, I can build against an older Windows API and get something working for you. I'll try to make time for that this weekend.

[assertivist]

I know it's been quite some time since I've had an update, the thing is, this is kinda low on our priority list--win7 is EOL pretty soon.

But either way, we updated a whole lot of the rendering code, and it may be that some of the things we were doing before had made it crash on specific setups. Give this one a shot for me:

https://drive.google.com/file/d/192ltkHFuIpOjm6wQKufCrchOLX19Bnon/view?usp=sharing

That's just from make winapp in MSYS2 Mingw x64 on my windows 10 machine with the most recent code.

[cogthecat]

Unfortunately it's still no good. Honestly I'm not expecting you to do anything further with this - I'm just impressed you worked this hard on it already. Eventually I'll end up with a machine that can run it, so I'll just wait until then and rejoin the community properly when it won't cost you any extra development resources.

Thanks so much for trying, though!

[assertivist]

This is the last time i will bug you...

I've been researching changing our build system to CMake and the result of that is that I can now make Avara builds with Visual Studio C++. I dunno if you've upgraded to Win10 yet, but you might try this one:

https://vastan.net/avara-builds/WinAvara-x64-Debug.zip

The only issue that there may be is that it might depend on parts of the Windows 10 API. You might be able to install some c++ redistributable though? Let me know.

[cogthecat]

As it turns out this is very timely (or untimely?) because I'm currently in the middle of a major hardware upgrade that now has me settling in on Win10. I still hope that this is somehow made available for Windows 7, but I personally no longer need that. Feel free to close the thread from here and I'll see you in my HECTOR soon enough.