MinGW
Monkey Targets Forums/Desktop/MinGW
| ||
Here's an example of the clock demo built on MinGW : glfw_clock_mingw.rar (90k) No change to the generated code. Change to trans.monkey to support the revised target, and the addition of libopenal32.a (which gcc can link to). I didn't think there was any valid reason it couldn't work... so there you go. Anyway... nothing to see here. Move along, move along. |
| ||
Thanks man, very much appreciated. |
| ||
Here's all the bits you need, packaged up in this rar : monkey_glfw_mingw30.rar This is based on release 30 of Monkey. It includes : in bin new_trans_winnt.exe - A new binary with the new code. trans.monkey : modified source. trans.monkey.mingw.patch : a diff file showing the actual changes (there aren't many there!) in glfw mingw - a folder with some useful things. Add the mingw folder to your monkey/targets/glfw folder. Drop the trans exe in your monkey/bin folder and rename appropriately. (best to backup first!) Finally, in your config.winnt.txt, add this line : GLFW_SDK=GCC That will force it to use MinGW instead of Visual Studio. All going well, it should *just* work... |
| ||
Brucey, does it compile any faster? I'd like to know before I do the change if possible. |
| ||
I've no idea... I don't intend installing VS Express 2010 to find out! I certainly know that it can compile faster than I have made it - because it is compiling all the bits each time. A little more logic and it would only need to recompile the main.cpp file each time rather than the glfw parts (which are compiled into a static lib). Depends how slow, slow is, I suppose :-) |
| ||
It doesn't work for me, maybe because I have VS2010 installed, so it behaves differently. My first error is: FOPEN 'wb' for CopyFile(H:/prg/MonkeyPro/modules/mojo/data/mojo_font.png,H:/prg/MonkeyPro/bananas/Richard_Betson/mirror_fx_transform/mirror_fx_transform.build/glfw/mingw/Release/data/mojo_font.png) failed Actually I would prefer if the GLFW VS2010 target would still work, so you would have all the old targets and just a new target in addition: GLFW MinGW. I tried earlier to get glfw including with STDCPP, but didn't get that to work quite yet either. But I think I will keep trying to get a new target to work. EDIT: Step 1 is a success! I copied the GLFW target and called it GLFWMINGW target. I have now the old targets unchanged, and only added a new target. It successfully compiles now the examples, but still with VS2010. Now I just need to add Brucey's MinGW compiling lines into it. I will make it so that is uses GNU C++ also in MacOS, since I think GNU C++ exists also on MacOS, at least with a little compiling from source. |
| ||
Well, it takes about 30 secs to compile a GLFW for me right now. And I have a top of the line quadcore 3.4Ghz pc. |
| ||
Yeah, it's 30 sec with VS2010 for me too. I can't wait to get MinGW working, because I think it compiles in 5 sec, plus the exe is faster, I will make a test for that too. |
| ||
Step 2 is a success! I can now compile GLFW with MinGW on Windows and GLFW with GNU C++ on MacOS! Now on to Step 3: cleaning up, optimizing (I think I will make a makefile instead of Brucey's build.txt), and writing an article how to add a new target on monkeytools.net. As I guessed: compile time went down from 30 secs to 6 secs, and with a makefile it will be 5 secs. |
| ||
Yay Brucey! Awesome work! |
| ||
I noticed I need to make 2 bug fixes in mojo.glfw.cpp for MinGW to fix compiler warnings. I know I can't distribute mojo.glfw.cpp because the README.TXT file says so, but I think it's OK for Mark if I say how to fix 2 lines, like this: In line 480: add an f before the abs commands. In line 869: add an int( ) around the expression. I think this doesn't expose too much of the source code, and should be legal. |
| ||
It would be cool if it was added as another build option BUT I think Mark has enough on his plate for now. |
| ||
But I got it already working as a new build option. I'm writing a tutorial right now how to do it. No need for Mark here, I hope Mark focusses on the Android sound bug fix and Linux Monkey IDE :) EDIT: The tutorial is ready, with this you can add your own GLFWMINGW target to Monkey: http://www.monkeytools.net/articles/Adding_a_GLFWMINGW_target |
| ||
Hi, You guys are welcome to use this of course, but please note that it will *not* be officially supported! That goes for both the new mingw target and the forked version of trans. > I know I can't distribute mojo.glfw.cpp because the README.TXT file says so, but I think it's OK for Mark if I say how to fix 2 lines, like this: Yeah, that's fine. |
| ||
Yeah, I understand that it's not officially supported, since you must have had your reasons why you used VS2010 instead of MinGW. But I think it will work quite fine, even if some minor bug fixes need to be done in mojo.glfw.cpp from time to time to get rid of warnings, and to make it ANSI C++ compliant. I'm happy to hear that verbal patch instructions are OK with you, and I try to avoid any exposal of the source code also by just giving out minimal delta instructions :) |
| ||
Choice is good, I think :-) |
| ||
Hi, > Choice is good, I think :-) So is simplicity... |
| ||
Very true, but I didn't really want to install *another* Visual Studio and all that .net stuff. Nice to be able to use the tools I already have installed... Anyway, apologies for interfering, as I do... |
| ||
Apologies not accepted, your help was invaluable! :) I think it is written into Monkey that unsupported features will arise a lot in the future, because the bin directory is public domain. And that's good! I don't want another BlitzMax with no feature updates for 10 years. Monkey is all up to the developers to make it better, that's a very valuable aspect of it. |
| ||
Hi, > Very true, but I didn't really want to install *another* Visual Studio and all that .net stuff. Why not? IMO, installing VS2010 (about a 10 minute operation) is FAR preferable to having to maintain multiple versions of trans and a new target FOR EVER. > Anyway, apologies for interfering, as I do... Hey, no problem, Monkey is there to be played with! Just trying to minimize my own workload really - this is a pretty ambitious project for me and it's only gonna work if I KISS. |
| ||
I was thinking that trans.monkey could have some #if->#include definitions for additional targets, so that the original trans.monkey could be kept unchanged at all times, and if some config variable exists, it would cause it to include additional target code. |
| ||
I made a little speedtest program, and GLFWMINGW indeed makes faster code than GLFW (VS2010). With GLFW it took 21.306s to run, and with MinGW it took 21.243s. Not a big difference, but it will cumulate in bigger apps, and faster is faster, no matter how much faster. I mean that's how you win also in races, by hundreds of a second :)Import mojo Class Game Extends App Method OnCreate() Local t1:Int Local t2:Int Local tt:Float Local a:Float Local b:Float Local c:Float Local i:Int c=10000.0 b=0.001 a=0 Print "Speedtest begin." t1=Millisecs() For i=1 To 500 a=0 While a<c a=a+b Wend Next t2=Millisecs() tt=(Float(t2)-Float(t1))/1000.0 Print "Speedtest end. Total time: "+tt+"s." End End Function Main() New Game End |
| ||
Hi, That's gotta be one of the flakiest 'speed tests' I've seen yet! The real question is: If 1000 monkeys wrote 1000 flakey speed tests, would MinGW win them all?!? |
| ||
@marksibly: Probably not. They are two very different compilers and work very differently behind the scene, so they are probably also good at different things. I don't think MinGW is better than VS2010, and I don't think VS2010 is better than MinGW, but I don't like Microsoft for personal reasons, and therefore am glad to enjoy MinGW builds, even with the extra trouble. :) Also, MinGW is closer to the C++ standard, which is always good in my book. |
| ||
I made a new flakey speed test: I replaced all float with double in cpptranslator.monkey and lang.cpp, and now speedtest with GLFWMINGW runs even faster than before: 20.799s! So now I have 2 cumulative speed boost for GLFW apps over the standard GLFW target: g++ -O6 and double :) I will make soon a patch installer, have been planning that for a while now, since updating all new Monkey versions gets harder and harder the more custom hacks I make. With the patcher everyone can install with one mouse click the latest custom speed boosts for Monkey. I don't understand why people use float in C++ at all nowadays. Since Pentium 5 every PC runs double faster than float (because of the internal 64-bit FPU), and it has even a lot bigger accuracy. |
| ||
I changed the GLFWMINGW target to use a makefile and mingw32-make, and now a GLFWMINGW program compiles and runs in 2 seconds! It's almost as fast as the HTML5 target, which takes 1.5 seconds on my pc. I will add this new GLFWMINGW version to Monkey Patcher, on which I have been working since yesterday. A first public version should be ready today or tomorrow. |
| ||
Just an update on this. If anyone is using MingW as a compiler you will need to add the following compiler flags: -static-libgcc -static-libstdc++ If you don't, the following error is shown when you try and run: "This application has failed to start because libgcc_s_dw2-1.dll was not found. Re-installing the application may fix this problem." The computer I tried running my app on did not have MingW installed. Search of Google found some discussion on this issue. |
| ||
I get a bunch of errors ../main.cpp:31: error: `String' was not declared in this scope ../main.cpp:31: error: expected primary-expression before "const" ../main.cpp:31: error: initializer expression list treated as compound expression ../main.cpp:31: error: expected `,' or `;' before '{' token ../main.cpp:35: error: `String' was not declared in this scope ../main.cpp:35: error: expected primary-expression before "int" ../main.cpp:35: error: expected primary-expression before "int" ../main.cpp:35: error: expected primary-expression before "int" ../main.cpp:35: error: initializer expression list treated as compound expression ../main.cpp:35: error: expected `,' or `;' before '{' token ../main.cpp:43: error: `String' does not name a type ../main.cpp:58: error: invalid function declaration ../main.cpp:870: error: `unsigned char* loadImage(String, int*, int*, int*)' redeclared as different kind of symbol ../main.cpp:35: error: previous declaration of `unsigned char*loadImage' ../main.cpp:35: error: previous non-function declaration `unsigned char*loadImage' ../main.cpp:870: error: conflicts with function declaration `unsigned char* loadImage(String, int*, int*, int*)' ../main.cpp:872: error: `FILE* fopenFile(String, const char*)' redeclared as different kind of symbol ../main.cpp:31: error: previous declaration of `FILE*fopenFile' ../main.cpp:31: error: previous non-function declaration `FILE*fopenFile' ../main.cpp:872: error: conflicts with function declaration `FILE* fopenFile(String, const char*)' ../main.cpp: In member function `virtual int gxtkGraphics::DrawOval(float, float, float, float)': ../main.cpp:1366: warning: passing `float' for converting 1 of `int abs(int)' ../main.cpp:1366: warning: passing `float' for converting 1 of `int abs(int)' ../main.cpp: In member function `virtual gxtkSurface* gxtkGraphics::LoadSurface(String)': ../main.cpp:1484: error: `loadImage' cannot be used as a function ../main.cpp: In member function `virtual int gxtkApp::MilliSecs()': ../main.cpp:1882: warning: converting to `int' from `double' ../main.cpp: In member function `virtual gxtkSample* gxtkAudio::LoadSample(String)': ../main.cpp:2114: error: `fopenFile' cannot be used as a function ../main.cpp: At global scope: ../main.cpp:9040: error: invalid function declaration ../main.cpp:9041: error: invalid function declaration ../main.cpp:9042: error: expected unqualified-id before "return" ../main.cpp:9044: error: invalid function declaration TRANS Failed to execute 'g++ -o Release/main_winnt ../main.cpp -mwindows -I../openal/include -I../glfw/include -I../stb -L. -lopenal32 -lglfw -lopengl32 stb_image.o', return code=1 |
| ||
Update: woops just wiped out whatover what here! anyway, Mark has made some changes to v42 so you will need to have this code for mingw.monkey: Import target Class MingwTarget Extends Target Function IsValid() Select HostOS Case "winnt" If MINGW_PATH Return True Case "macos" Return False Case "linux" Return False End End Method Begin() ENV_TARGET="glfw" ENV_LANG="cpp" _trans=New CppTranslator End Method MakeTarget() Select ENV_HOST Case "winnt" CreateDir "mingw/"+CASED_CONFIG CreateDataDir "mingw/"+CASED_CONFIG+"/data",False Local main$=LoadString( "main.cpp" ) main=ReplaceBlock( main,"${TRANSCODE_BEGIN}","${TRANSCODE_END}",transCode ) SaveString main,"main.cpp" If OPT_BUILD Local line$ ChangeDir "mingw" Local build$=LoadString( "build.txt" ) For line=Eachin build.Split( "~n" ) Print line Execute line Next Local out$=CASED_CONFIG+"/MonkeyGame" 'Local out$=CASED_CONFIG+"/main_"+HostOS DeleteFile out 'Create exe Print "Generating code" Execute "g++ -o "+out+" ../main.cpp -mwindows -I../openal/include -I../glfw/include -I../stb -L. -lopenal32 -lglfw -lopengl32 -static-libgcc stb_image.o" 'Execute "g++ -o "+out+" ../main.cpp -mwindows -I../openal/include -I../glfw/include -I../stb -L. -lopenal32 -lglfw -lopengl32 -static-libgcc -static-libstdc++ stb_image.o" Print "Finished generating code" If OPT_RUN ChangeDir CASED_CONFIG Execute "MonkeyGame" Endif Endif Case "macos" Case "linux" End End End |
| ||
thanks, it turns out I put the //{$begin_code} in the wrong place, it works now :) |
| ||
From a fresh install from monkey V40, I couldn't get this to work. Errors: g++: unrecognized option `-static-libstdc++' TRANS Failed to execute 'MonkeyGame', return code=-1073741515 ... i tried gcc, but I received too many errors to count. The second error comes from when I run the file, it's looking for: OpenAL32.dll is missing... I'd rather create dependency-free files, but perhaps it has to do with the first error? |
| ||
For the first error, I searched around for an answer @29 and this was what I found. I think you either need to also install the c++ libraries (from memory - sorry cannot remember the options/libraries I used - perhaps their above)) or try removing this option from the Execute statement. I just know it works for me. For the second error you need this: http://www.monkeycoder.co.nz/Community/posts.php?topic=88#279 . I don't believe you can get away from installing the OpenAL library (I could very well be wrong here). |
| ||
Thanks for the reply, I kept the stdlibc++ off for now, but the openal.dll is a problem. |
| ||
So it works fine without stdlibc++ ? |
| ||
So it works fine without stdlibc++ ? After viciously tearing out the OpenAL audio from the mingw build, yes. |
| ||
Ok - thanks for confirming. I'll update the above. |
| ||
Mark has made some changes in v42 so you will need an updated mingw.monkey file. Process: 1. Grab the file above provide by brucey and unpack 2. Open file src\trans\targets\targets.monkey and make the following amendments: * Add Import mingw (line 11) to list of imports * Add If MingwTarget.IsValid() valid.Push "mingw" (line 23) to function ValidTarget * Update the Select statement (line 46) in function SelectTarget with the following: Case "mingw" Return New MingwTarget * Save the changes 3. Create a new file mingw.monkey in src\trans\targets\ and add the following: Import target Class MingwTarget Extends Target Function IsValid() Select HostOS Case "winnt" If MINGW_PATH Return True Case "macos" Return False Case "linux" Return False End End Method Begin() ENV_TARGET="glfw" ENV_LANG="cpp" _trans=New CppTranslator End Method MakeTarget() Select ENV_HOST Case "winnt" CreateDir "mingw/"+CASED_CONFIG CreateDataDir "mingw/"+CASED_CONFIG+"/data",False Local main$=LoadString( "main.cpp" ) main=ReplaceBlock( main,"${TRANSCODE_BEGIN}","${TRANSCODE_END}",transCode ) SaveString main,"main.cpp" If OPT_BUILD Local line$ ChangeDir "mingw" Local build$=LoadString( "build.txt" ) For line=Eachin build.Split( "~n" ) Print line Execute line Next Local out$=CASED_CONFIG+"/MonkeyGame" 'Local out$=CASED_CONFIG+"/main_"+HostOS DeleteFile out 'Create exe Print "Generating code" Execute "g++ -o "+out+" ../main.cpp -mwindows -I../openal/include -I../glfw/include -I../stb -L. -lopenal32 -lglfw -lopengl32 -static-libgcc stb_image.o" 'Execute "g++ -o "+out+" ../main.cpp -mwindows -I../openal/include -I../glfw/include -I../stb -L. -lopenal32 -lglfw -lopengl32 -static-libgcc -static-libstdc++ stb_image.o" Print "Finished generating code" If OPT_RUN ChangeDir CASED_CONFIG Execute "MonkeyGame" Endif Endif Case "macos" Case "linux" End End End 4. Compile up trans. |
| ||
also for faster compilings.... The build.txt file is compiling c files into o files again and again. If you compile your game once, you remove all lines from build.txt (in your build directory) and it still works...but its faster to compile |
| ||
Yes, that's why I use a makefile instead of compiling each file seperately. Using a makefile the gnuwin32-make tool automatically detects which files have changed and only compiles those, so you get super fast compiling times. |
| ||
Lumooja, Would you mind posting your makefile? |
| ||
Just reimaged my computer and needed to setup MinGW again! Arrr... I've used the new distribution Mark has make available for BlitzMax here: http:///nuwen.net/mingw.html which you unpack into C:\ (this sets up the C:\MinGW folder for you) Don't forget to update your environment settings: * Add ;C:\MinGW\bin to the end of the Path variable * Create new MinGW variable that points to C:\MinGW (I've added to both the user and system variables on Win 7). Probably needs a reboot as well. Took a bit of fiddling to get the environment stuff sorted out. |
| ||
monkey 56b src/trans/target/mingw.monkey I should add that the above target creates -O3 for release mode, and will also check for libglfw so it won't compile every time if it's already there. |
| ||
I havent installed mingw target for a while so I forgot how to do it, I recompiled trans ok, but then it asked for mojo.mingw.cpp I copied and renamed mojo.glfw.cpp so I got past that error but now it says "TRANS FAILED: Failed to copy target dir" it seems to be looking for targets/mingw but I think its supposed to be looking in the targets/GLFW/Mingw folder or something |
| ||
is this a viable replacement to using VC++ Express ? |
| ||
is this a viable replacement to using VC++ Express ? Yep, it should be - I believe thats the whole point why Brucey did it is to get away from VC++ :) Disclaimer: I havent actually tried it :P |
| ||
@AdamRedwoods Great - thanks for the update! @Taiphoz Yes - you can certainly use but you will need the OpenAL module (info about this is in the above). The main point Mark made about usual VC++ Express is its ease of install and setup compared to MinGW. It can certainly be challenging to get it working. |
| ||
"TRANS FAILED: Failed to copy target dir" - create a new copy of the targets/glfw folder and rename it "mingw". - in targets/mingw delete the vc2010 and xcode (you don't need it for mingw) - in targets/mingw create mingw folder - in targets/mingw/mingw you need: build.txt (copy from above), libopenal32.a, openal32.def (copy from openal32 site or Brucey#3 post above) libstc++.a (copy from mingw/lib install folder) is this a viable replacement to using VC++ Express ? I use mingw exclusively without any problems and it's very fast. its been great with minib3d. |
| ||
Question, does the normal MingGW install required to build bmax modules count or would additional stuff need to be done. and is there any chance of mark supporting this with an official target so we dont need to mess with the code ? |
| ||
thanks adam it compiles now :) hmm it seems to compile slower than VC++ now, dont know why, as -03 shouldnt be active cos im doing a debug build |
| ||
Question, does the normal MingGW install required to build bmax modules count or would additional stuff need to be done. the same one works and is there any chance of mark supporting this with an official target so we dont need to mess with the code ? no way, see above post #14 |
| ||
Updated for monkeyV62 (ogg vorbis) **instructions** monkey/src/targets/mingw.monkey mingw/mingw/build.txt |