wxMax duplicate section app compile issue
BlitzMax Forums/Brucey's Modules/wxMax duplicate section app compile issue
| ||
| Hi, I started checking out wxMax, builds ok but then when I'm building the simple hello world example I get this: http://pastebin.com/FRFdtw8F Preview: Building hello_world [ 99%] Processing:hello_world.bmx [ 99%] Compiling:hello_world.bmx.console.release.win32.x86.c [100%] Linking:hello_world.exe C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xh_frame.o): duplicate section `.rdata$_ZTV20wxThreadHelperThread[__ZTV20wxThreadHelperThread]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xmlres.o): duplicate section `.rdata$_ZTV20wxThreadHelperThread[__ZTV20wxThreadHelperThread]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xmlres.o): duplicate section `.rdata$_ZTV17wxStringTokenizer[__ZTV17wxStringTokenizer]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xh_toolb.o): duplicate section `.rdata$_ZTV20wxThreadHelperThread[__ZTV20wxThreadHelperThread]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xh_statbar.o): duplicate section `.rdata$_ZTV20wxThreadHelperThread[__ZTV20wxThreadHelperThread]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xh_menu.o): duplicate section `.rdata$_ZTV20wxThreadHelperThread[__ZTV20wxThreadHelperThread]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xh_sizer.o): duplicate section `.rdata$_ZTV20wxThreadHelperThread[__ZTV20wxThreadHelperThread]' has different size C:/BlitzMaxNG/mod/wx.mod/wx.mod/../lib/win32/libwxmsw31u_xrc.a(xrclib_xh_sizer.o): duplicate section `.rdata$_ZTV17wxStringTokenizer[__ZTV17wxStringTokenizer]' has different size ... ... I'm using GCC 4.7.1 |
| ||
| The static libs were built with GCC 5.1. You'll probably either need to build with a 5.x GCC or rebuild the libs yourself with your choice of GCC. |
| ||
| Ok thanks Brucey, will try to test it with 5.1. |
| ||
| With NG, just stick your MinGW install in C:/BlitzMaxNG/MinGW32 and rebuild. Should be good to go. |
| ||
| Ok got it. The last I have downloaded binaries in your github page is with MinGW32 4.8.1, I seem to forgot where I got the link (BlitzMax_win32_0.62.3.06.zip). Where can I get the bmx-ng win32 binaries with MinGW gcc 5.1? |
| ||
| bmx-ng.com The Windows download contains the GCC compiler that builds wxMax. Dabz |
| ||
| The Windows download contains the GCC compiler that builds wxMax. It's not an official (my :-p) build though, and contains changes to bmk that are not officially supported by me :-p Where can I get the bmx-ng win32 binaries with MinGW gcc 5.1? I'll do a new release later this week. |
| ||
| Thanks Brucey, Ok I will just wait for the new release. awesome! :-) Hey Dabhand, I agree with Brucey and as my last download from your custom build is not compatible with my setup. I do appreciate your efforts though and what you have done so far in terms of support here and opening this awesome site. :-) cheers. |
| ||
| Lol@brucey Well get ya finger out bonny lad and I'll whack a new official one up there! :P hehehe ;) In other news... I've started a game in blitzmax-ng... Yay!!!! \o/ Dabz |
| ||
| Oh, just spied your reply Rusti! ;) That's okay... But what you could do is download the package from bmx-ng and copy and paste the MinGW32 folder over to the official one and wxMax should build accordingly! Dabz |
| ||
| I've started a game in blitzmax-ng Which should be just like starting a game in BlitzMax proper :-p If you find there's anything you need to do differently (that you'd expect to work in the old legacy stuff, please let me know), as everything generally should work the same... (platform specific things obviously excepted) |
| ||
| Well, I could, but... 1) android, pi testing out of the box, can build around them as well... Biggy! 2) manipulating lists is a no no I'm bmx-ng, which I like being forced to do it the proper way, top feature imo 3) it will give bmx-ng a good run out... Very important because if someone can finish a game in it... Well, it's there innit! Oh, and if I hit any snags, I will post... Topic title "BRUCEYYYYYYYYYY... HELLLLLPPPP" ;) hehehe Dabz |
| ||
| 2) manipulating lists is a no no I'm bmx-ng, which I like being forced to do it the proper way, top feature imo Which removed some potential segfaults (happening sometimes) in my game TVTower ... which might have been a reason for Brucey to include it (to rap me on the knuckles ... for behaving badly :-)). If you see it compile a bit slow, append the "quick"-param to bcc - so it does not check modules whether they are modified or not ... for my geany-addon I appended it, dunno if Brucey's "maxIDE"-clone already includes the param. bye Ron |
| ||
| Oh, just spied your reply Rusti! ;) That's okay... But what you could do is download the package from bmx-ng and copy and paste the MinGW32 folder over to the official one and wxMax should build accordingly! Ah ok haha. :D Thanks, I will try that as well. |
| ||
| If you see it compile a bit slow I'm sure that's just you :-p Even in my VM's it builds quickly... |
| ||
| If you see it compile a bit slow, append the "quick"-param to bcc - so it does not check modules whether they are modified or not ... for my geany-addon I appended it, dunno if Brucey's "maxIDE"-clone already includes the param. Yeah, it's in MaxIDE, builds my imports once then forgets about them, goes to 99% straight off the bat when compiling, obviously with the 1% being the file I've just pretinkered! ;) Dabz |
| ||
| The "check module sources for modification" adds a big bunch of compile time here on my "classic hdd"-machine (non-ssd) - maybe it's the ext3-partition (gets stressed when doing multiple things at once). The "quick"-param ("opt_quickscan" in the bmk-sources) disables module-source-modification-lookup (it is then failing modification-recognition similar to vanilla bmk - so disable it, if modifying modules and relying on auto-recompilation). @Brucey We closed 2 issues the last days regarding this ... albeit it should be still a "problem" (if not using the quick-param) especially when using bigger modules (wxMax in my case). $ time ./bmk makeapp -t console -r -a "/PATH_TO/TVTower.git/editor.bmx" [ 19%] Compiling:base.util.mersenne.c [ 19%] Compiling:glue.cpp .... [100%] Linking:editor real 0m51.264s user 0m46.112s sys 0m3.135s $ time ./bmk makeapp -t console -r -a -quick "/PATH_TO/TVTower.git/editor.bmx" [ 19%] Compiling:base.util.mersenne.c [ 19%] Compiling:glue.cpp .... [100%] Linking:editor real 0m46.733s user 0m43.502s sys 0m3.033s Without recompilation: $ time ./bmk makeapp -t console -r "/PATH_TO/TVTower.git/editor.bmx" real 0m1.589s user 0m1.480s sys 0m0.071s $ time ./bmk makeapp -t console -r -quick "/PATH_TO/TVTower.git/editor.bmx" real 0m0.402s user 0m0.328s sys 0m0.055s Of course this time the time differences are not that big - maybe it improved over the last releases (there were issues with the way and order things get "imported" in multiple source files). For my game the difference is better visible (but same factor of "4"): $ time ./bmk makeapp -t console -r "/PATH_TO/TVTower.git/TVTower.bmx" real 0m4.480s user 0m4.397s sys 0m0.061s $ time ./bmk makeapp -t console -r -quick "/PATH_TO/TVTower.git/TVTower.bmx" real 0m0.926s user 0m0.851s sys 0m0.055s This only matters if you are - like me - one who codes some lines and is eager to check it out by running the app. bye Ron |
| ||
| Is that using legacy BlitzMax with bmk NG? Also, is your bmk NG multi-threaded? |
| ||
Yes to both questions$ ./bmk -v bmk 3.04 linux-x86 / gcc 040804 (cpu x4) $ ./bcc BlitzMax Release Version 1.48 Like said, this is happening because of the huge amount of file lookups (I suggested various things in the issue that time - though none of them was really useful). I had some debugs that time logging file accesses and thoughts on "caching" file information. Edit: I know that this bmk is NOT the most current. with the most current I get this: $ ./bmk -v bmk 3.06 mt-linux-x86 / gcc 040804 (cpu x4) $ time ./bmk makeapp -t console -r -quick "/PATH_TO/TVTower.git/TVTower.bmx" real 0m1.541s user 0m1.435s sys 0m0.107s $ time ./bmk makeapp -t console -r "PATH_TO/TVTower.git/TVTower.bmx" real 0m8.410s user 0m7.759s sys 0m0.188s And the editor file (using wxMax) $ time ./bmk makeapp -t console -r "/PATH_TO/TVTower.git/editor.bmx" real 0m3.173s user 0m3.050s sys 0m0.099s $ time ./bmk makeapp -t console -r -quick "/PATH_TO/TVTower.git/editor.bmx" real 0m0.729s user 0m0.618s sys 0m0.101s Which shows, why I am not using the most current bmk. bye Ron |
   |