V144 now up!
BlitzMax Forums/BlitzMax Programming/V144 now up!
| ||
| Hi, BlitzMax V144 is now available from the product update section on the Accounts page. This started out as a simple fix for a Linux problem, but I ended up updating a few other things at the same time. * Added skid branch of sourceforge maxgui to main release. * Changed Win32 MinGW distro to nuwen.net - main mingw page is here: http:///nuwen.net/mingw.html Direct download is currently here: http://nuwen.net/files/mingw/mingw-7.2.exe This version includes gcc4.6, and is much easier to install. The 'pre built' BRL and Pub modules shipped with this update have already been built with this new version of MinGW, but you will probably need to rebuild any 3rd party modules you may have installed. Otherwise, you are likely to get weird linker errors. * Fixed bmk failing to link with gcc4.6 on Linux. |
| ||
| Nice one, Mark. Thanks. |
| ||
| Thanks mark, been waiting for that fix on linux. |
| ||
| Do I need to do anything special to install the linked MinGW? If I rename my old MinGW folder and replace it with the new one under the c:\MinGW folder, things don't work -- trying to recompile anything gives a ton of errors: Building Modules Compiling:blitz_app.c C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s: Assembler messages: C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:30: Error: invalid instruction suffix for `push' C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:45: Error: invalid instruction suffix for `push' C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:65: Error: invalid instruction suffix for `push' .... C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:345: Error: invalid instruction suffix for `push' C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:349: Error: register save offset not a multiple of 8 C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:618: Error: invalid instruction suffix for `pop' C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:620: Error: invalid instruction suffix for `pop' C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:622: Error: invalid instruction suffix for `pop' C:\Users\Marc\AppData\Local\Temp\ccO3SzPh.s:633: Error: invalid instruction suffix for `push' Build Error: failed to compile C:/Code/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c Process complete (The help -> about in MinGW does show GCC 4.6.1 and G++ 4.6.1) Last edited 2011 |
| ||
| Is MaxGUI now part of the BlitzMax distribution? |
| ||
| Is MaxGUI now part of the BlitzMax distribution? It appears so, yes -- there's a maxgui.mod in the distribution now. |
| ||
| The instructions are a little bit misleading. it says: First, extract the distro into C:\MinGW . A common mistake is to create C:\MinGW\MinGW . Don't do that. The bin directory and its friends should be directly under C:\MinGW . But the distro creates the MinGW directory for you. So in reality, you should extract the distro directly to the root C:\ instead. |
| ||
| Tried rebuilding the modules. Got this error Building Modules Compiling:blitz_app.c gcc: error: CreateProcess: No such file or directory Build Error: failed to compile C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c Process complete MinGW is installed and typing in g++ --version in the command console returns g++ (GCC) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. so the paths are ok BTW, trying to compile on Win7 Home Premium. Last edited 2011 |
| ||
| Firstly, thank you for the update. It`s nice to see BMax getting some attention again. It deserves it. Anyway... I`m getting build errors too when trying to rebuild modules. I have renamed my MinGW folder and replaced it with the new one like xlsior above. Rebuilding fails straight away. Building Modules Compiling:blitz_app.c Build Error: failed to compile C:/Program Files (x86)/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c Process complete Also, BMax states that both GCC and G++ are both unavailable in the about box despite the path being correct. (Worked perfectly before.) Jason. Last edited 2011 Last edited 2011 |
| ||
| @QuickSilva, make sure you are putting MinGW in the right place. The installer creates it's own MinGW directory, so If you extract to C:\MinGW, you are actually extracting to C:\MinGW\MinGW. @mark, I did an update of Win7 and it seems to have fixed my problem. |
| ||
| Thanks a lot for the update. I'm glad that such a great product is still supported. I have the same issues as QuickSilva mentioned (OS: Win7 64 Bit). Btw: - Does this version release include the newest maxgui version/code? - Btw: FASM is at version 1.69.34 by now: http://flatassembler.net/download.php |
| ||
| Do you get anything when you type g++ --version into a command prompt? Make sure your directory is set up so bin is in C:\MinGW\bin and not C:\MinGW\MinGW\bin. Also try Windows Update. I don't know which of the 97 updates it was, but something there fixed the problem I had. |
| ||
| I have patched my system, left out Silverlight and some others. I can compile code, (even with old modules) but rebuilding modules doesn't work. gcc --version displays: 4.6.1 |
| ||
| I'm on win7 - 64 bit and had no problems with the update and installing new MinGW. |
| ||
| Compile errors here as well. Using Windows 7 64-bit home edition, and have installed MinGW from the first post. |
| ||
| I have the new mingw in c:\mingw (confirmed it is the right version in the right place) My environment variable is set (always was) I have installed the blitzmax 1.44 exe (default location) I opened the maxide.exe and it prompted to Build Documentation. I got an error in the OUTPUT. Building: MaxGUI Drivers Building: MaxGUI.CocoaMaxGUI Building: MaxGUI.FLTKMaxGUI Building: MaxGUI.Win32MaxGUIEx Building: MaxGUI Building: MaxGUI.Drivers Building: MaxGUI.Localization Building: MaxGUI.MaxGUI Error: Unable to resolve link 'SetIndents' Building: MaxGUI.ProxyGadgets Building: Other Building: MaxGUI.XPManifest Should i be concerned? __ did a rebuild documentation and have the same message did a Rebuild Modules (default settings of Debug and Build GUI App) Compiled with no problems. rebuilt docs with same error warning __ Cheers glenn Win7 Pro 64bit Last edited 2011 Last edited 2011 |
| ||
| @TomToad Hello, no I have double checked and it is in the correct location but still does not work. Not sure what the problem is? Jason. |
| ||
| Hiya Mark, Thanks for the update :) To all.... EDIT -> This is the exact order I updated - I uninstalled an older version of MinGW and installed the newer from Marks link above. I saved all my modules before the next steps... I removed the old BMax install completely including deleting the BlitzMax folder. Installed MingW to C:\MingW, did a default install of BMax1.44 . Rebuilt docs as it suggested... MaxGui -> SetIndent is unresolved, oh well. Rebuilt the standard modules. This worked perfect. Added in all of my modules and rebuilt those. No problems at all, everything works lovely. Maybe its Win7/64bit ? I rebuilt on Vista Home Premium 32bit. Last edited 2011 |
| ||
| I have the same prob, using Win7 / 64 bit. MinGW is directly under c:\mingw (not c:\mingw\mingw) Should I remove the old MinGW environment variables / path entries, or are they still necessary? |
| ||
| The unresolved SetIndents error in MaxGUI... This is only because the docs compiler can't find the SetIndents function referenced in SetTextAreaTabs(....) documentation. It's nothing to worry about but maybe it should be resolved or removed in the future. |
| ||
| Here is how it is set up on my Win7 Home Premium 64 bit system BlitzMAx is installed in C:\BlitzMAX MinGW is installed in C:\MinGW ;C:\MinGW\bin is at the end of the path variable MinGW variable points to C:\MinGW I could not get MinGW to work until I ran Windows Update. Since I had never run update, it took a couple of hours and a few reboots. Not sure which of the updates did the trick (maybe one of the .net updates?) After updating, everything worked fine. |
| ||
| OK, working now. I had to add \bin to the end of my path variable as it didn`t have it before, instead it was just ;C:\MinGW (although this worked fine previously.) Edit : Actually it still doesn`t work :( My about box now says that MinGW has been found which is why that I thought all was OK but when I try to compile all modules I am still getting this, Building Modules Compiling:blitz_app.c gcc: error: CreateProcess: No such file or directory Build Error: failed to compile C:/Program Files (x86)/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c Process complete I do not have BMax installed in the default location, would this make a difference? Jason. Last edited 2011 |
| ||
| Hi, the file mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/lcUniConv/cp936ext.h is missing. I get a compile error when building the maxgui on Linux. Last edited 2011 |
| ||
| @QuickSilva: The reason BlitzMax doesn't install to "Program Files" is that the directory is protected by the OS and that means it can't write to that directory. Install it to C:\BlitzMax or C:\Tool\BlitzMax, etc. and try again. |
| ||
| @Quicksilva, that is the same error I was getting. Fixed it by running Windows Update and updating everything. Try that and see if it starts working for you. |
| ||
| @ Muttley, UAC is turned off so installing in Program Files should be OK. @ TomToad, for once I`m sad to say that there are no updates available. Jason. |
| ||
| Since I had never run update... *jawdrop* Please, please, everybody keep your OS up to date (not just the Windows users, either). The OS and software manufacturers assume you are using the latest version, and if you don't care about that, at least remember that the principle of Herd Immunity means that your system's security indirectly affects everyone else's. |
| ||
| Running Win7 profesional 64bit here. When trying to recompile modules I was also getting alot of: Error: invalid instruction suffix for `push'. Google told me that the error message for some reason had something to do with 64bit(?) So.. Changing line 164 in bmk_util.bmx from opts:+" -ffast-math"to: opts:+" -Wa,--32 -ffast-math"Rebuilt bmk, and now modules rebuild just fine.. Why it's working for some, but not for others.. Have no clue. AnyWhoo. The -Wa,--32 bit is "forcing" the assembler backend to 32bit.. |
| ||
| Cool But if there is prebuild modules and a new mingw, does BMK(NG) and Mac Cross-Compiling have to be updated or ? |
| ||
| Hi, > So.. Changing line 164 in bmk_util.bmx from Werid...what does this display? c:\MinGW\bin\as --version I get: GNU assembler (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `i686-pc-mingw32'. From the looks of the last line, it can ONLY do 32 bit asm so I wonder if you're somehow running a different assembler? Perhaps you've got another 'path' setup? That tweak to bmk is probably a good idea I guess, unless it masks other problems... Last edited 2011 |
| ||
| I cannot get it to work at all. I have typed, c:\MinGW\bin\as --version and am getting the same as you Mark. I have also re-installed BMax into the default location just to make sure that wasn`t the problem, double checked my paths but still no luck. I also have a 64-Bit OS so that does seem to be the cause of the problem somewhere along the line. Jason. |
| ||
| c:\MinGW\bin\as --version GNU assembler (GNU Binutils) 2.21.1 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `i686-pc-mingw32'. BUT just doing: as --version GNU assembler (GNU Binutils) 2.20.51.20100613 Have no clue what so ever where that x86_64 as.exe comes from, but I do have Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-w64-mingw32'. C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86 stuck into my path somehow. Me never added that for sure(!)(And yes there's an as.exe hiding inside that directory) Before I started googling/digging around in bmk sourcefiles, I was about to post that this could be a amd/intel problem. But then I installed max 1.44 on my intel i3 laptop, and got the same error. Only thing left that's similar on those two machines is the gfx card. Both running ATI card, or now AMD. So my guess is that the x64 as.exe, and path, has something to do with the AMD/ATI gfx driver.. or atleast was installed that way somehow.. EDIT: After searching some more I found that it indeed comes from the ATI/AMD graphics driver. More spesific the 'AMD APP SDK Runtime' part of the driverpackage.. And for some reason that gets installed by default if you do an express setup of the driver. It's removable by doing something like: (guessing the english wording, mine are norwegian) - controlpanel->Programs - rightclick AMD Catalyst Install Manager, select 'change' - choose 'uninstall' then 'custom'. - uncheck 'AMD APP SDK Runtime ' - done.. Last edited 2011 |
| ||
| With the changes posted by Ole it works. Only issue I have is that a command window is opened for each file compiled. It slows the process down a lot. Also I'm configured for 64 bit. See below.  |
| ||
| Hi, > After searching some more I found that it indeed comes from the ATI/AMD graphics driver. Holy crap! So the ATI/AMD driver installs a version of 'as' that effectively hijacks the one used by other installs of gcc? What else is lurking in that bin dir?!? Any suggestions for fixing this? I don't like just passing -m32 or whatever to the AMD assembler - I want to know that gcc is using the *right* assembler at all times. > Only issue I have is that a command window is opened for each file compiled. It slows the process down a lot. Also I'm configured for 64 bit. See below. Weird, doesn't happen here - perhaps your having a similar problem to the 'as' issue with 'ld'. Can you check that both 'ld --version' and 'as --version' are 2.21.1? Also, both 'gcc --version' and 'g++ --version' should be 4.6.1 These version checks *could* be added to the IDE, but then you wouldn't be able to upgrade any components. |
| ||
| Hello, thanks for the much anticipated fix :) P.S.: I'm glad I use nvidia. *trololololo* |
| ||
| You should be able to edit the path so that C:|MinGW\bin appears before the other directories, then the MinGW version would be run, but then AMD will start using the MinGW versions which could screw that up as well. One suggestion for Mark would be to set a variable to where MinGW is set up, then use absolute paths to the functions. So instead of cmd$ = "gcc", you would have path$ = GetEnv("MinGW") 'or whatever command to get the value of the environment variable cmd$ = path+"\bin\gcc" |
| ||
| Hi, Ok, it's definitely a feature of the new gcc/g++ - the old one appears to use the correct 'as' regardless of PATH. [edit]This is not correct - old MinGW doesn't even seem to use 'as'[edit] I've emailed the nuwen guy about the issue, perhaps we can get it fixed...otherwise, I might hack a hardcoded sanity check into the IDE. Last edited 2011 |
| ||
| What else is lurking in that bin dir?!? as.exe, ld.exe and clinfo.exe are the only files in there, but more than enough to make some trouble.. And if you install the complete SDK I think you get a bunch more files.. I might hack a hardcoded sanity check into the IDE. Ehm. Why not in bmk itself? I never use the IDE to compile modules ;)Besides the IDE use bmk doesn't it? Do it like?: path$ = GetEnv("MinGW") 'or whatever command to get the value of the environment variable As you have to set that variable anyway to be able to compile modules from the IDE me think it's the "best" solution.cmd$ = path+"\bin\gcc" Atleast I have to set it here on win7.. Last edited 2011 |
| ||
| bmk would be a better place IMHO - i dont use the IDE for building either... Fwiw, i also have an ATI videocard, so its definitely possible that that is what is interfering. Potential quick workaround for people: change the PATH order so mingw appears before the ATI folders? Last edited 2011 |
| ||
| Hi, Mark. Good to see that BMax is still being updated... I was wondering if it would be legal/possible to create a Bmax installation that INCLUDES all the necessary files from minGW inside the Blitzmax/ folder (in bin or lib or whatever) and not use environment variables or any of these other things that seem to be causing headaches for lots of people. In other words: A completely self contained compiling distribution. After reading the posts above, and after finally getting my own installation of BlitzMax compiling its own and third party modules correctly (mainly Brucey's), I'm a little hesitant to try this new setup. There must be some other way to do this that is virtually guaranteed to work! Russell |
| ||
| It seems like sticking c:\mingw\bin as the first entry in my path fixed the immediate issue for me -- modules are recompiling now, so far without errors. |
| ||
| ATI video card here as well. Seems to be related indeed. |
| ||
| ATI video card here as well. Seems to be related indeed. |
| ||
| same problem here fixed by moving c:\mingw\bin to front of path variable. Last edited 2011 |
| ||
| Is there any advantage of switching to a new gcc ? I'm still using GCC 3.4.5. I never know if those kind of changes can make any bad differences at runtime. |
| ||
| @Mark: Both "ld" and "as" are version 2.20.51.xx  GCC and G++ are both: 4.6.1 I'm using an ATI 6850 card. So it's related for sure... :) |
| ||
| Hi, > same problem here fixed by moving c:\mingw\bin to front of path variable. This should fix all such problems for BlitzMax, although it may prevent other SDK's from working. I could hack this into BMK using the MINGW env var I guess, so it's only in effect while BMK is running. Will have a go... |
| ||
| Hi, Ok, there's now a win32 v144b up with a kludged bmk. For this to work, you will need to make sure the MINGW env var is set correctly, eg: to 'C:\MinGW'. BMK will then temporarily add this (bmk will add the '\bin' - you don't need to) to the start of the PATH while running. Once BMK exits, PATH should go back to normal. I guess this also means that if you've got MINGW set, you wont need to add C:\MinGW\bin to your PATH, as bmk will now do it for you...but it wont hurt! Last edited 2011 |
| ||
| Thank you for the update! |
| ||
| @Mark: 1.44b works fine here. Thanks for the fix. |
| ||
| 1.44b fixed it for me as well! |
| ||
| Is there any advantage of switching to a new gcc ? I'm still using GCC 3.4.5. I never know if those kind of changes can make any bad differences at runtime. You should probably upgrade it, GCC 3.4.5 is really old. It probably has some performance advantages and bugfixes, especially for C99. You should check out the changelogs. GCC 4.5 also has LTO, and in GCC 4.6 it actually works. :D Oh, and thank you mark for fixing this <3 |
| ||
| When is the source available here http://code.google.com/p/max-gui/source/browse/trunk/maxide/?r=5 ? |
| ||
| Thanks for the answer The_Nici. I installed the recommended MinGW, install the fresh new 144b BlitzMax, import my modules and my biggest project. Everything re-build correctly. Didn't see any differences, no performance gain or lost so I think I can keep this BlitzMax for production purposes. Did anyone try with MacOSX and Linux yet? Hope I can trust this new configuration :) Thanks for the fix Mark. |
| ||
| Under linux fltkmaxgui still does not compile. File mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/lcUniConv/cp936ext.h is missing. |
| ||
| Hi, what type of changes you have made to the tree structure of your MinGW directory? I have copied the files from "C:\MinGW\libexec\gcc\i686-pc-mingw32\4.6.1" to "C:\MinGW\bin" this fix the "gcc: error: CreateProcess: No such file or directory" of QuickSilva and now? Apparently the compiler can't find many include files... flat assembler version 1.69.14 (1177263 kilobytes memory) 3 passes, 19911 bytes. Archiving:lua.debug.win32.x86.a ar: creating C:/BlitzMax/mod/pub.mod/lua.mod/lua.debug.win32.x86.a Compiling:reflection.cpp C:/BlitzMax/mod/brl.mod/reflection.mod/reflection.cpp:3:19: fatal error: cstdarg: No such file or directory compilation terminated. Build Error: failed to compile C:/BlitzMax/mod/brl.mod/reflection.mod/reflection.cpp Process complete Thanks. P.S. Mark can you include a zipped mingw directory to make more easy the installation? Last edited 2011 |
| ||
| I have resolved my problem using the official Sourgeforge MinGW installation setup. |
| ||
| Mark Help! Please make for a constant block: Enumeration .... EndEnumeration. |
| ||
| As reported by "igb" and "Bart Simpson", MaxGUI doesn't build on Linux because the file "lcUniConv/cp936ext.h" is missing. :( |
| ||
With 144b it won't build my modules returning:Building Modules Compiling:blitz_app.c gcc: error: CreateProcess: No such file or directory Build Error: failed to compile C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c Process complete Running Win7 64Bit, with an ATI 6770. Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\ngu>g++ --version g++ (GCC) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Users\ngu>c:\MinGW\bin\as --version GNU assembler (GNU Binutils) 2.21.53.20110804 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `mingw32'. C:\Users\ngu> Also made the suggested change to bmk_util.bmx and removed AMD APP SDK Runtime. Still no joy! Edit: in the above "as" version, I got the same output from "as --version" that I got using the path. Edit: also fully updated Windows. and have reverted to the recommended MinGW version. (4.6.1 and 2.21.1) Last edited 2011 |
| ||
| When can we expect a fix for Linux so maxgui will build again? Still missing lcUniConv/cp936ext.h error. |
| ||
| I did fix this and it was my own mistake, apologies! I had GCC_EXEC_PREFIX set. Not required in Win7. Doh! Code still not running on new machine, but this I will figure out. |
| ||
| Htbaa, I just commented out the lines that included 'lcUniConv/cp936ext.h' and it built without any issues. |
| ||
| The link to MinGW on their own page gives a 404: http://nuwen.net/mingw.html |
| ||
| I have uploaded an auto-extractible folder version of the needed MinGW on my website. You can download it here : http://arm42.com/downloads/softwares/Nuwem_MinGW_7.2.exe Tested on a fresh Windows 7 and BlitzMax installation, it's working like it should. Hope it help Last edited 2012 |
   |