My apologies, Brucey...

BlitzMax Forums/Brucey's Modules/My apologies, Brucey...

Russell(Posted 2011) [#1]
After re-reading my post 'cascading errors...' I realized that I could have made the "bug" report easier for you if I had not put the entire list of errors in one message. Plus, it may have appeared like I was being pushy. Sorry if that's the way I came off. :)

Most of the errors were as a result of deleting the boost.mod folder, which many (many!) other modules need to compile. So I think if I can resolve the problem with boost.mod, virtually all of the other compile problems will go away.

The boost.mod error returned from BMax was :
#error Configuration not supported: Boost.Filesystem V3 and later requires std::wstring support

The, perhaps more informative, error message from the output window was:
Compiling:utf8_codecvt_facet.cpp
In file included from C:/BlitzMax/mod/bah.mod/boost.mod/src/boost/filesystem/config.hpp:31,
                 from C:/BlitzMax/mod/bah.mod/boost.mod/src/libs/filesystem/src/utf8_codecvt_facet.cpp:11:
C:/BlitzMax/mod/bah.mod/boost.mod/src/boost/filesystem/v3/config.hpp:49:5: #error Configuration not supported: Boost.Filesystem V3 and later requires std::wstring support
Build Error: failed to compile C:/BlitzMax/mod/bah.mod/boost.mod/src/libs/filesystem/src/utf8_codecvt_facet.cpp

I have G++ version 3.4.2. Do you think upgrading to a newer version of mingw would help? (And if so, which version do you recommend?)

Thanks in advance!
Russell


Brucey(Posted 2011) [#2]
One exciting error after another, eh? :-)

It's interesting that 3.4.2 doesn't support wstring? (well, it is really old, so maybe it's not so strange at all...)

If you don't want BaH.FilesystemEx, you can try building again without it, since it is the one which builds those .cpp files that it is complaining about.

Otherwise...

You could try a version of MinGW with GCC 4.x, but that requires some other changes to your BlitzMax...
You can either :
1) install a 4.x version, copy the relevant files from it (ar.exe, ld.exe) into your BlitzMax/bin. And copy all the matching .a and .o files into BlitzMax/lib.

2) install a 4.x version, and use my latest bmk, which doesn't require you to copy the libs.

But both 1 and 2 require you to be reasonably comfortable changing your configurations...

According to the boost mailing list from 2009, on Windows one requires at least GCC 4.4 to have std::wstring support.


Brucey(Posted 2011) [#3]
I should point out, that as time moves on, many 3rd-party libraries (that my modules use) are only testing against more recent versions of GCC, so those older (2005/6) MinGW installations will start to fail where they didn't previously.
This has recently reared its head with CEGUI, amongst a couple of others.

I think it is better (for me) to keep up with more recent libraries. Certainly, my SVN repository can be expected to do that. If you want more stability, it is better to stick with the "official releases".


Russell(Posted 2011) [#4]
I thought BRL had adopted your modified BMK as the default BMK? I'll get your bmk from your site and upgrade to 4.x mingw. Seems like the best (and easiest) option.

I'll let you know how everything goes.

Thanks again!
Russell


xlsior(Posted 2011) [#5]
I thought BRL had adopted your modified BMK as the default BMK?


They haven't, but they should. :-?

Last edited 2011


Russell(Posted 2011) [#6]
Ok, here's what I did:

1) Downloaded the latest mingw (using mingw-get-inst-20110211.exe).
2) Selected the C and C++ compilers as well as the developers toolkit. (EDIT: Didn't see the 'Base Files' and 'G++' options, like the tutorials say, so that's why I chose the developer's toolkit; I assumed they would be in there).
3) Backed up my old C:/MinGW installation (actually, renamed the folder OLD_MingGW)
4) Installed the new files at C:/MinGW
5) Did not change any of the previously set environmental variables, since the directory/file structure appears to be the same as the old installation. (Although there are like three times as many files in the bin folder now...)
6) Found Brucey's bmk on his website, http://brucey.net/programming/blitz/misc/bmk/bmk2.zip, downloaded it.
7) Compiled Brucey's BMK ("bmk.bmx"), after disabling GUI mode and Debug mode
8) Renamed the current BMK to OLD_BMK.exe
9) Copied Brucey's BMK to C:/BlitzMax/bin
10) Rebuild All Modules and...
Building Modules
Compiling:blitz_app.c
gcc: CreateProcess: No such file or directory
Build Error: failed to compile C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c
Process complete

:(

Do I need to set/change any of the environmental variables? Any idea what the problem could be?

I'm running Windows 7 x64

Russell

Last edited 2011

Last edited 2011


xlsior(Posted 2011) [#7]
if you type "gcc -v" at a command prompt, do you get the version of GCC that's installed?

Also, make sure to copy ld.exe and ar.exe from the MinGW\bin folder into your blitzmax\bin folder, as well as overwrite the files in blitzmax\lib with their equivalents that came with MinGW.


Brucey(Posted 2011) [#8]
I would suggest using this bmk instead.


Russell(Posted 2011) [#9]
xlsior: On my original minGW installation, I get 3.4.2. On the latest minGW installation, I get 4.5.2. Also, I need to copy all of the files from minGW/bin that have a corresponding file in BlitzMax/bin? [EDIT: I meant the lib folder, not the bin folder. I also copied the ar and ld files from bin to bin.]

Brucey: I have your new BMK. Do I need to compile anything in the zip other than bmk.bmx (which imports several files)? There's a bmk_bb2bmx.bmx and many other files in there that are that are not imported by bmk.bmx. Which ones need to be compiled?

Russell

Last edited 2011


Brucey(Posted 2011) [#10]
You only need to compile bmk.bmx, which will create your bmk.exe

If you use this bmk.exe you don't need to copy the libs into the BlitzMax/lib folder, although you should copy the ar.exe and the ld.exe (well, only ar.exe, but you may as well have a matching set!)

Then you need to rebuild your modules - so that they are all built against the new GCC.


xlsior(Posted 2011) [#11]
What Brucey said -- his latest version of BMK negates the need to copy the files to blitzmax/bin, but if you are using any other BMK version that is indeed necessary.


Russell(Posted 2011) [#12]
Ok, round two ;)

1) I compiled Brucey's bmk and copied it to the BMax bin folder (after renaming the original to OLD_bmk.exe). The resulting file was about 372k-ish.
2) Copied ar.exe and ld.exe from C:/Mingw/bin to C:/Blitzmax/bin (after renaming the originals to OLD_ar.exe and OLD_ld.exe).
3) Used TortoiseSVN Checkout to re-download Brucey's modules (Except for wx.mod, which is a separate namespace now).
4) Got the latest wx.mod from Brucey's website.
5) Just for good measure, and to really give BMax a workout, I obtained several other mods, such as koriolis.mod, maxmod2.mod, pantson.mod and zipstream.mod.
6) I select Program/Rebuild All Modules from the menu and wait...for 3 seconds. (This process normally takes at least 5 minutes, usually more.)

BMax output looks something like this:
Building Modules
Archiving:blitz.debug.win32.x86.a
Archiving:appstub.debug.win32.x86.a
Archiving:avbin.debug.win32.x86.a
Archiving:barcode.debug.win32.x86.a
Archiving:base64.debug.win32.x86.a
Archiving:bass.debug.win32.x86.a
Archiving:bass_fx.debug.win32.x86.a
Archiving:box2d.debug.win32.x86.a
Archiving:cairo.debug.win32.x86.a
Archiving:chipmunk.debug.win32.x86.a
Archiving:clearsilver.debug.win32.x86.a
Archiving:crypto.debug.win32.x86.a
Archiving:curses.debug.win32.x86.a
Archiving:database.debug.win32.x86.a
Archiving:dbgp.debug.win32.x86.a
Archiving:dbmysql.debug.win32.x86.a
Archiving:dbodbc.debug.win32.x86.a
Archiving:dboracle.debug.win32.x86.a
Archiving:dbpostgresql.debug.win32.x86.a
Archiving:dbsqlite.debug.win32.x86.a
Archiving:dbxbase.debug.win32.x86.a
<snip>

No error messages. At first I thought, "Wow! The compile speed is like 100x faster!". Then I notice it doesn't appear as though anything is being compiled at all, just archived...

7) I load an example from maxmod2.mod's example folder, "PlayFolder.bmx", and click compile.
8) I get this message:
Building PlayFolder
Unrecognized app source file extension:bmx
Process complete

Uh oh....
Now what?

Russell


Russell(Posted 2011) [#13]
It looks as though I can not compile anything with the new bmk! Not even simple core Bmax programs.

I compiled bmk with debug off and GUI App off as well.

I think I will start over with a clean re-install of Bmax and the modules and see what happens.

Cross your fingers!

Russell


xlsior(Posted 2011) [#14]
Note that you can also compile modules manually from the command line.
Under blitrmax/bin: bmk makemods -a <modulename> for non-threaded, and makemods -a -h <modulename>

Sometimes you get weird things if a module has dependencies on others that have been compiled with a different MinGW version, so you may want to start out by manually re-compiling brl.mod and pub.mod first, before going on to the others...


Russell(Posted 2011) [#15]
I'll give that a shot, xlsior. Thanks for the advice.

Russell


Russell(Posted 2011) [#16]
I just noticed that there's a bmk_ng.bmx as well as a bmk.bmx. Am I supposed to compile the bmk_(N)ext(G)eneration?

Russell


Russell(Posted 2011) [#17]
I'm really not an idiot, but can someone please give me a step by step on how to update to a newer mingw and get BMax to compile Brucey's modules? Like, a link to which mingw should be downloaded, which options to choose, what to copy where and how, etc. Because no matter what I do it does not work! In fact, I just put back my original ld.exe, ar.exe and bmk.exe files and I still can't compile anything! I used to be able to compile without any problems (with the default installation). Now I get:
Building Modules
Compiling:blitz_app.c
gcc: CreateProcess: No such file or directory
Build Error: failed to compile C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c
Process complete

It's looking more and more like the latest mingw is not compatible with the latest BMax or Windows 7 64bit (or me)!

Help!
Russell


xlsior(Posted 2011) [#18]
It's looking more and more like the latest mingw is not compatible with the latest BMax or Windows 7 64bit (or me)!


For what it's worth, I am using the latest MinGW on windows 7 x64 with Blitzmax myself, and it's all working properly...

(It was a royal pain in the behind to get everything configured properly, though)


Russell(Posted 2011) [#19]
So why is it not working for me I wonder? You're using Brucey's bmk as well?

(It was a royal pain in the behind to get everything configured properly, though)

It shouldn't be, if you ask me. This is ridiculous that I have to go through so many loops to get this working!

So, to make it clear, xlsior:
- You're using BMax 1.41
- You're using Brucey's bmk (You compiled the bmk.bmx file in this archive: http://brucey.net/programming/blitz/misc/bmk/bmk_ng_2_11_src.zip with 'Debug' and 'Build GUI App' turned off)
- You have the latest minGW installed, with the proper environmental variables set (I never had any problems before with these, so I did not touch them after "upgrading" to the newest minGW)
- You copied minGW's bin/ar.exe and bin/ld.exe to BlitzMax's bin folder

The ONLY thing I haven't tried is copying the .o and .a files from the minGW lib folder to BlitzMax's lib folder because Brucey says I don't need to if I use his bmk.

Did you answer yes to all of the above? If so, do you think I need to copy the .a and .o files also?

Any steps that I'm missing otherwise?

Thanks anyone!
Russell


Brucey(Posted 2011) [#20]
With the new bmk, you also need to copy a few of the .bmk files to bin. These are helper "build scripts" which are Lua-based.
There should be a little readme.txt that explains what they are for :-)

Now you have all the files : bmk.exe, core.bmk and make.bmk in BlitzMax/bin, open up a shell/terminal/cmd, and type : gcc -v

This at least ensures that MinGW is runnable.

Now, try running bmk from the BlitzMax/bin dir.

bmk -v

will give you a version number. Here's what it looks like when I run it on Mac :
$ bmk -v
bmk 2.11 mt-macos-x86 / gcc 40201

It should also report correctly the version of gcc. "mt" shows it was compiled with multithread enabled (this improves compilation speed of c/c++ files)


Russell(Posted 2011) [#21]
Typing gcc -v get's me GCC version 4.5.2.

Ok, I hadn't copied the core.bmk and make.bmk files over. Did that. Now I get this error when I try to compile a test piece of code from the manual (Which is better then the dreaded 'unrecognized application extension:bmx'):
Building .createimage
Compiling:.createimage.bmx
flat assembler  version 1.68  (1719555 kilobytes memory)
3 passes, 3151 bytes.
Linking:.createimage.exe
ld: cannot find crtbegin.o: No such file or directory
ld: cannot find -lstdc++
ld: cannot find -lgcc_s
ld: cannot find -lgcc
ld: cannot find -lgcc_s
ld: cannot find -lgcc
ld: cannot find crtend.o: No such file or directory
Build Error: Failed to link C:/BlitzMax/docs/html/Modules/Graphics/Max2D/.createimage.exe
Process complete

Brucey, I copied the minGW/lib .a and .o files which corresponded to BltzMax's lib's .a and .o files. You said it wasn't necessary with your bmk, but I was getting desperate! Could that be the problem?

Russell

Last edited 2011


Russell(Posted 2011) [#22]
Nope, that's not it: I re-re-reinstalled BlitzMax to start with the standard lib folder contents, then did the bmk compile (copying it and core and make over to the bin folder). Copied mingw's ar and ld to BMax's /bin folder.
Trying to compile anything gives the error above. Trying to rebuild all modules gives the aforementioned:
Building Modules
Compiling:blitz_app.c
gcc: CreateProcess: No such file or directory
Build Error: failed to compile C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c
Process complete

I am at my wit's end here! It looks like ld is the one outputting the errors. It says it can't find crtbegin.o, yet it is plain to see in BlitzMax's lib folder! I'm supposed to use minGW's ld.exe, right?

Got to go to bed. I'll try to figure this out tomorrow...

Wish me luck! (Also, give me some pointers if you have any left!)
Russell


Brucey(Posted 2011) [#23]
on the command line, from the BlitzMax/bin folder, try this :
bmk makemods -v -a

It is a verbose compile... i.e. it will show everything it is trying to do.
Hopefully there will be something in there that will help to see what you've missed out :-)

It's remarkable how much trouble there is sometimes getting this to work...

This is what I usually do when installing it fresh on a new system :

* Download and install MinGW (usually into C:/MinGW)
* Download and install BlitzMax (doesn't matter where this goes. Sometimes in Program Files, sometimes on C:\)
* Set up the environment variables (put Mingw on the path, and a variable for mingw)
* drop my bmk (and files) into BlitzMax/bin
* build modules on the command line (of course, you would use the ide normally, but it all does the same thing)

On a base install, that usually takes less than an hour.

I've recently documented the setup on a Mac, using Macports for MinGW, which follows a similar process, and has been successfully installed, by all accounts. Not that this helps your cause, but I'm just trying to show that it should be a painless process to get it working. Yes, really!

If you get really desperate, drop me a mail and I'll see if we can't get you sorted ;-)


Russell(Posted 2011) [#24]
Here's the full output from typing 'gcc -v' at the console:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r
untime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)

C:\Windows\system32>

Don't know if this sheds some more light on the subject.

Now, I'm going to do a clean install per Brucey's instructions. Stand by...

* Download and install MinGW (usually into C:/MinGW)
Done
* Download and install BlitzMax (doesn't matter where this goes. Sometimes in Program Files, sometimes on C:\)
Done (Installed in C:\BlitzMax, the default)
* Set up the environment variables (put Mingw on the path, and a variable for mingw)
Done (GCC_EXEC_PREFIX = C:\MinGW MinGW = C:\MinGW Path = ...other paths;C:\MinGW\bin)
* drop my bmk (and files) into BlitzMax/bin
Done (Compiled bmk.bmx - from bmk_ng_2_11_src.zip - and it, along with core.bmk and make.bmk in BlitzMax's bin folder). For completeness, here's BMax's output when compiling bmk.bmx:
Building bmk
Compiling:bmk_config.bmx
flat assembler  version 1.68  (1854503 kilobytes memory)
3 passes, 13881 bytes.
Compiling:bmk_ng_utils.bmx
flat assembler  version 1.68  (1852227 kilobytes memory)
3 passes, 8753 bytes.
Compiling:bmk_ng.bmx
flat assembler  version 1.68  (1851557 kilobytes memory)
4 passes, 27435 bytes.
Compiling:bmk_util.bmx
flat assembler  version 1.68  (1851407 kilobytes memory)
4 passes, 17895 bytes.
Compiling:bmk_modutil.bmx
flat assembler  version 1.68  (1850513 kilobytes memory)
4 passes, 9039 bytes.
Compiling:bmk_make.bmx
flat assembler  version 1.68  (1850117 kilobytes memory)
4 passes, 21503 bytes.
Compiling:bmk_bank.bmx
flat assembler  version 1.68  (1850543 kilobytes memory)
3 passes, 3571 bytes.
Compiling:bmk_modinfo.bmx
flat assembler  version 1.68  (1851217 kilobytes memory)
3 passes, 4829 bytes.
Compiling:bmk_zap.bmx
flat assembler  version 1.68  (1851567 kilobytes memory)
3 passes, 4685 bytes.
Compiling:bmk_bb2bmx.bmx
flat assembler  version 1.68  (1851267 kilobytes memory)
4 passes, 33679 bytes.
Compiling:bmk.bmx
flat assembler  version 1.68  (1851263 kilobytes memory)
4 passes, 17162 bytes.
Linking:bmk.exe

Process complete

So far, so good...
* build modules on the command line (of course, you would use the ide normally, but it all does the same thing)

Cross your fingers! Here we go! 3...2...1...
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\BlitzMax\bin>bmk makemods -v -a
Compiling:blitz_app.c
gcc -w -march=pentium -ffast-math -fno-exceptions -c -O2 -I"C:/BlitzMax/mod/brl.
mod/blitz.mod" -I"C:/BlitzMax/mod"  -o "C:/BlitzMax/mod/brl.mod/blitz.mod/.bmx/b
litz_app.c.debug.win32.x86.o" "C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c"
gcc: CreateProcess: No such file or directory
Build Error: failed to compile C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c
C:\BlitzMax\bin>

(Cue the sad music)

If I replace the old MinGW, the default installation compiles fine. So, I'm going to add modules one at a time here and invoke "bmk makemods" from the command console (Sorry in advance for the lengthy post...):

Added maxgui.mod
No problems installing or using

Added koriolis.mod
No problems installing or using

Added maxmod2.mod
No problems installing. However, example program miniplayer.bmx when compiled reports
Linking:MiniPlayer.exe
\mingw\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lunicows
collect2: ld returned 1 exit status
Build Error: Failed to link C:/BlitzMax/mod/maxmod2.mod/examples/MiniPlayer.exe
Process complete
Perhaps it is not compatible with my original mingw?

Added pantson.mod (Theora)
No problems at all!

Added bah.mod/bass.mod
No problems (After downloading bass.dll of course ;)

Added bah.mod/bassfx.mod
No problems (After downloading bass_fx.dll - {Oddly, unlike bass.dll which can be installed in the system32 folder and be recognized, this seems to need to be in the current folder})

Added bah.mod/box2d.mod
No problems. (You'd think this one would be finicky if any of them are!)

Added bah.mod/cairo.mod
No problems.

Added bah.mod/chipmonk.mod
No problems compiling. However, running demo1.bmx reports (from line 136):
Identifier 'AddCollisionPairFunc' not found
. The actual highlighted code is:
space.AddCollisionPairFunc(1, 0, collFunc)

demo2-demo6 worked fine. Demo7 reports
Identifier 'CPJoint' not found
and demo8 reports
Unable to convert from 'Int(bah.chipmonk.CPBody,bah.chipmonk.CPVect,Float,Float)' to 'Int(CPBody,CPVect,Double,Double)'
on line 108. No big deal because I will probably use box2d rather than chipmonk, but this information may still be useful to you.

Added bah.mod/crypto.mod
No problems (After downloading libeay32.dll)

Added bah.mod/database.mod (Plus dbgp,dbmysql,dbodbc,dboracle,dbsqlite and dbxbase)
No problems (After compiling base64.mod)

Added bah.mod/expat.mod
No problems

Added bah.mod/fmod.mod + fmodaudio.mod
No problems

Added bah.mod/format.mod (plus regex.mod, which it needs)
No problems

Added bah.mod/freeimage.mod
No problems compiling this now (After making a minor change to freeimage.mod\src\LibOpenJPEG\opj_malloc.h as suggested by Brucey), but attempting to compile the test_01.bmx file I get:
Building test_01
Compiling:test_01.bmx
flat assembler  version 1.68  (1746461 kilobytes memory)
3 passes, 1400 bytes.
Linking:test_01.exe
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x738):tcd.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x13da):tcd.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x3bf4):tcd.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x3eca):tcd.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x4229):tcd.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x10c2):dwt.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x12e3):dwt.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x15cf):dwt.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x198c):dwt.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x118):t1.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x125):t1.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x168):t1.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x179):t1.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x228):t1.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x232):t1.c: undefined reference to `_mm_free'
collect2: ld returned 1 exit status
Build Error: Failed to link C:/BlitzMax/mod/bah.mod/freeimage.mod/tests/test_01.exe
Process complete

I looked inside LibOpenJPEG/tcd.c but could find no reference to _mm_malloc

Added bah.mod/inet.mod
No problems compiling. In non-debug mode, though, the example_01.bmx program causes an exception_access_violation (But still outputs the network information). Debug mode works fine and does not put out any error messages.

Added bah.mod/irrklang.mod and bah.mod/irrklangaudio.mod
No problems

Added bah.mod/leptonica
No problems

Added bah.mod/libtcod.mod
No problems (And the example was surprisingly cool! YAY, old school!)

Added bah.mod/libusb.mod
No problems compiling (Didn't try the example, because it said devices should not be attached when starting it up. I'm pretty confident it will work though.)

Added bah.mod/libxml.mod
Module compiles fine, but example1.bmx gives an 'Unhandled Exception:Attempt to access a field or method of Null object' in debug mode (line 12:
Print doc.getUrl()
, and an 'Exception_Access_Violation' first, then a 'parser error:XML declaration allowed only at the start of the document' error in non-debug mode. The other example, bookstore.bmx works fine in both modes.

Added bah.mod/libxslt.mod
Module compiles fine. No example to test. This is something I personally probably will never have a need for. But who knows?

Added bah.mod/magick.mod
No problems.

Added bah.mod/persistence.mod
No problems

Added bah.mod/raknet.mod,raknetvoice.mod,raknetvoicefmod.mod
No problems

Added bah.mod/random.mod
No problems

Added bah.mod/rtmidi.mod
No problems

Added bah.mod/sfxr.mod
No problems (YAY! Old school rocks!)

Added bah.mod/speech.mod
No problems. (Although I did waste 10 minutes making the example program say obscene things...)

Added bah.mod/volumes.mod
No problems

Added wx.mod
No problems. Did not need to compile this one, as the binary is available from Brucey's site.

I couldn't find libsvg.mod. Was it incorporated into cairo.mod?

So, really, the only problem modules with my old minGW (of the modules that I would make use of, or need because of dependencies) are:
Cegui.mod (and therefore ceguidirect3d39.mod and ceguiopengl.mod)
Boost.mod
Freeimage.mod (and freeimageext.mod)

Whew! You have no idea how long it took to individually compile and test all the above modules. Then again, Brucey, you most certainly do...

Is there anyone willing to compile boost.mod, the cegui modules and freeimage.mod for win32 and host them for people like me who are having trouble getting the newest minGW to work on their system?

Well, thanks for listening! :)
Russell


Brucey(Posted 2011) [#25]
Cross your fingers! Here we go! 3...2...1...

Hold on... so at first you are trying to build against the new MinGW... then subsequently against the original MinGW?
If I replace the old MinGW, the default installation compiles fine

Which is what you are saying here?

Okay...

Assume for a moment, that we are back to using the new MingW...

So, from here :
C:\BlitzMax\bin

If you run gcc -v, what output do you get?
And, when you run
bmk -v

what output do you get?
(this command only works with my bmk, not the original)


Ole JR(Posted 2011) [#26]
Try removing the environment variable GCC_EXEC_PREFIX = C:\MinGW.
Running Win7 x64 here also, and don't have that one,
with it I get the error: gcc: CreateProcess: No such file or directory.


Brucey(Posted 2011) [#27]
with it I get the error: gcc: CreateProcess: No such file or directory.

Oh? To tell the truth, I have never set that one either...

Thanks for that :-)


Russell(Posted 2011) [#28]
Thanks Ole JR! That's the exact error message I get, so I will try removing that and see what happens!

Sorry for the confusion, Brucey. I meant to say that I installed all of those modules one at a time under the old minGW because the new one would pittle out after the first file (blitz.c or something or other).

Anyway, if Ole JR's suggestion works, I will be a happy camper! (Can't remember where I got the GCC_EXEC_PREFIX idea from, but it was from some tutorial somewhere I read.

Stay tuned... :)
Russell


Brucey(Posted 2011) [#29]
I hope it works!


Ole JR(Posted 2011) [#30]
Can't remember where I got the GCC_EXEC_PREFIX idea from, but it was from some tutorial somewhere I read.

Me guess from Ziggy's guide step four.
VISTA ONLY:
4.- The same way you have added the environment variable called MinGW (step 2), you should create an environment variable named GCC_EXEC_PREFIX and set it to c:\MinGW



Russell(Posted 2011) [#31]
I guess I figured that because I have the OS right after Vista, Windows 7, that that would include me (Well, live and learn!)

Thanks again!
Russell


Zeke(Posted 2011) [#32]
Also if running windows and using BMK_NG you must change config.bmk paths:

path_to_mingw=c:\mingw

name_of_ar=ar.exe
name_of_ld=ld.exe
name_of_gcc=gcc.exe
name_of_gpp=g++.exe

path_to_mingw_lib=%path_to_mingw%/lib

path_to_mingw_lib2=%path_to_mingw%/lib/gcc/mingw32/4.5.2

and 'comment out' line (add #):
#path_to_wine=/Applications/Darwine/Wine.bundle/Contents/bin/wine

and if using latest MinGW you don't need to install dev toolkit. just C++.

Last edited 2011


Brucey(Posted 2011) [#33]
Also if running windows and using BMK_NG

No, you just don't use config.bmk at all - don't put it in the bin folder!

It's only used for cross compiling (On Mac and Linux).


Zeke(Posted 2011) [#34]
oh. yeah.. sorry my mistake.. i missed that part in your readme...
but if using g++ linker. maxgui gives error that unicows lib not found..
or if i use import "-lunicows".

Last edited 2011


xlsior(Posted 2011) [#35]
Did you actually download the unicows library?

IIRC it does not exist by default under windows XP.

From the Blitzmax 1.33 release, it explicitly gave a link to the unicows.dll download in the versions.doc, because it's a requirement for unicode support under windows 9x -- but MS apparently does not allow you to redistribute it with apps...


Zeke(Posted 2011) [#36]
problem solved. i copied libunicows.a from bmax/lib to mingw/lib.


Queller(Posted 2011) [#37]
Russell said:

Added bah.mod/freeimage.mod
No problems compiling this now (After making a minor change to freeimage.mod\src\LibOpenJPEG\opj_malloc.h as suggested by Brucey), but attempting to compile the test_01.bmx file I get:
Building test_01
Compiling:test_01.bmx
flat assembler version 1.68 (1746461 kilobytes memory)
3 passes, 1400 bytes.
Linking:test_01.exe
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x738):tcd.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x13da):tcd.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x3bf4):tcd.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x3eca):tcd.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(tcd.c.release.win32.x86.o)(.text+0x4229):tcd.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x10c2):dwt.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x12e3):dwt.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x15cf):dwt.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(dwt.c.release.win32.x86.o)(.text+0x198c):dwt.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x118):t1.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x125):t1.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x168):t1.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x179):t1.c: undefined reference to `_mm_malloc'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x228):t1.c: undefined reference to `_mm_free'
C:/BlitzMax/mod/bah.mod/freeimage.mod/freeimage.release.win32.x86.a(t1.c.release.win32.x86.o)(.text+0x232):t1.c: undefined reference to `_mm_free'
collect2: ld returned 1 exit status
Build Error: Failed to link C:/BlitzMax/mod/bah.mod/freeimage.mod/tests/test_01.exe
Process complete

I looked inside LibOpenJPEG/tcd.c but could find no reference to _mm_malloc


I have this exact problem using Win XP SP3 on a completely clean install of MinGW 5.1.3 and BlitzMax 1.42. and BaH.freeimage from SVN. May I ask how it got fixed (if it did)?