Compatability with GCC 4.4?
BlitzMax Forums/Brucey's Modules/Compatability with GCC 4.4?
| ||
| Hi Brucey, I'm just trying the MinGW GCC 4.4 build and libcurlssl seems to have failed at the moment I'm just updating and removing modules that dont make the compile, do you have a list of modules that are compatible with GCC 4.4? |
| ||
| It may need a library update. All libraries built with 4.x on Mac and Linux. But since GCC 4.x is so new on Windows, it's more likely to break compilation. I suspect some of the "older" libraries will never be updated for 4.x, which is a shame. |
| ||
| Of course, since Win32 4.x is not officially support by BRL yet.... :-p |
| ||
| Are you using Brucey's BMK NG or the original bmk.exe that comes with Blitzmax? Supposedly GCC 4.4 expects some of the compile parameters in a different order than the old GCC did, so the original bmk.exe may not work with all modules under GCC 4.4 bah.libcurlsll recompiled without error for me using GCC 4.4.1 and BMK NG on Windows. |
| ||
| Yeah... the link order changed. However, there may also be differences depending on which version of MinGW you use - for example the "official" one, or the tdm one. I've not actually tried the "official" one yet. |
| ||
| I'm using the TDM (SJLJ) version ( http://www.tdragon.net/recentgcc ) and at the last attempt it recompiled everything without error using BMK NG. |
| ||
| Just backed out of TDM 4.4 as I was getting some kind of BEGIN/END FRAME not declared in blitzmax/lib/<name>.o file error! It was strange as all the libraries (well apart from a few modules which I removed) built fine, but the simplest app would fail the linking stage with the above type of error?! Which is mentioned in another thread and apprently is due to the link order? So didn't even get the BMK_NG fiels to build, this is on windows Vista! |
| ||
| Oh -- one more thing: If you upgrade GCC, make sure to also replace ar.exe and ld.exe in the blitzmax\bin folder with the versions that came with MinGW. :-? |
| ||
Well replacing ar.exe and ld.exe and now all the modules build and simple applications build as well but applications that use the Bah.datetime module fail, e.g.SuperStrict Framework BaH.DateTime Import BRL.StandardIO Local d:TDate = TDate.Create(2007, Jul, 17) Print d.day() Generates... |
| ||
| ? |
| ||
| For what it's worth, that source sample you posted above works without error on my computer with GCC 4.4.1... :-? Do you get any errors when you explicitly try to rebuild Bah.datetime from the command line? (e.g., from the blitzmax/bin folder: "bmk makemods -a bah.datetime", as well as "bmk makemods -a -h bah.datetime") |
| ||
| bah.datetime builds fine in both single and multithreaded mode on the command line and via the Ide. But when I try and build even a simple example the linking process fails with the above errors? |
| ||
| I'll have a look in a wee while. I left it doing a full build using TDM 4.4.1 this morning. |
| ||
| I've updated BMK(NG) (2.07) to better handle the different version of GCC on Windows (well.. we'll see if that is the case when someone else tries to use it!) With a new 4.4.1 build of the modules, I get this output from the example posted earlier : Building untitled1 Compiling:untitled1.bmx flat assembler version 1.68 (524700 kilobytes memory) 3 passes, 591 bytes. Linking:untitled1.exe Executing:untitled1.exe 17 Process complete This is using the TDM 4.4.1 installer to set up MinGW. I have replaced ld.exe and ar.exe appropriately. I have also copied all the relevant .a files into BlitzMax/lib, from the MinGW area - since these are used by ld and ar for linking. The only issue I had, was with the link order that BMK was issuing. This gave two errors, concerning functions inside libmingw32. I've modified it now so that it shouldn't matter what version of gcc you are using on Windows... |
| ||
| Cool got it working now thanks! So do all of your modules work with TDM 4.4.1? Cheers Brucey |
| ||
| So do all of your modules work with TDM 4.4.1? Most of them should be fine. Certainly, the popular ones will, but there may be issues with some of the more obscure third-party libs - which aren't yet part of the SVN but are available at brucey.net. |
| ||
| Hi Brucey. Standard bmk speedup(.i2 checking) has no effect on included/incbin files.I modified bmk_make.bmx to avoid this issue. The issue was described here: http://www.blitzbasic.com/Community/posts.php?topic=87485 It's just some simple modifications (just added a timestamp for included files). I've been using my modified BMK for quite a while now. So I think the modification should be safe. Please take a look. I'd be happy if the modification can be commit to your release. The following source is based on BMK_NG modified bmk_make.bmx |
| ||
| So do all of your modules work with TDM 4.4.1? Only two of Bruceys modules currently fail to recompile for me, and those are raknetvoice & raknetvoicefmod... but that might be a problem with the modules themselves, brucey recently released some raknet updates... |
   |