Hi there fello a.cc folks.

I recently switched from a MSVC setup to a QtCreator dev environment (on Windows and seldomly on a Linux VM), and I am now trying to compile the latest git of Allegro 5.1

I've set up QtCreator and a build environment made of MSYS, MSYS2 and the TDM-GCC64 compiler suite (which is here), which uses the MinGW-w64 runtime, and can target both 64bit and 32bit application, being thou a 32bit application in itself.

I compiled (loosely following SiegeLord's wiki tutorial about it) all the required dependencies downloading their latest source, installed them into the compiler's environment and finally configured Allegro build system through CMake-gui.

The configuration I'm trying to build is the SHARED one, the build environment seems sane so far, but I'm unfortunately stuck getting the following error (Note: the following is only the last error upon LINKING allegro-5.1.dll, the output is from VERBOSE_MAKEFILE):

Enfasys on " collect2.exe: error: ld returned 5 exit status ", on one of my Win7 PCs this is ld.exe CRASHING.

I've found out (through my weak Google-fu) that this MAY come from ld.exe having troubles with memory (too much RAM required AND/OR Access Violation), unfortunately I was unable to find what the hell the exit status 5 is for ld, 0 means success, 1 means general failure (undefined reference & the like) but 5 is really really obscure (at least to me, the online ld man page also didn't help me).

It's a couple days I'm wandering through this, I've resorted to a static build (fixing a couple of errors the compiler throws at me and which will be argument for another thread), which builds just fine BUT, when linking ANY of the examples or demos it just crashes badly as above.

I'm quite lost, but I would like to know if there is some sort of general knowledge about this, e.g. where to find infos about this "crash" of ld and maybe how to work around this...I've found many cases on the net of such things (building many different things an not only allegro), but no practical solution (I've started from a clean board a couple times already), or maybe hints on how to debug the problem.

As an additional note, I've tried also the "MSYS Makefiles" CMake generator but the same thing happens (and actually was expected since it uses the same ld.exe)

Of course there could be something fishy in my object files mixing 32 and 64 bit binay interface, but usually GCC warns about it quite explicitly....is there a way to double check? (Apologize in advance for such noobiness).

Also: is there a way to remove a single path from an MSYS/Cygwin $PATH, as well as win7 system %PATH%, maybe only temporarily from the command line? This could save me time if I end up trying different (all Ming-w64) compiler suites.

Thanks for any help you can share!

Thanks for any info you would share

DUOBLE EDIT: I had to change <terminal> tags into <code> tags for readability, the forum would span several columns to the right with the former and that was hell

ANOTHER EDIT

Well, switching to another compiler suite (mingw-builds 64 bit flavor) yelds positive results...so far ld.exe did not crash linking allegro-5.1.dll

Now I'll try to redo all dependencies and see if I am going anywhere...too bad cause TDM-GCC is quite a nice setup....

Thanks fella, that guide's clean and reads quite nice....wouldn't it be a nice addition to the Wiki?

Mostly thou, I'm aiming at using a more up-to-date MinGW compiler and the subsequent runtime, I work on win7 but I guess it's the same on Win8+, I'd like to be able to produce 64-bit and 32-bit applications, mostly for the sake of it and to learn how to manage a multi-target environment (reminiscent of the past when I deal with ARM, Thumb, 68K and PowerPC...it was a LOT EASIER!!!)

I've mostly succeeded in building Allegro git with both 32bit and 64bit flavors of the MinGW-w64 toolchain namely mingw-builds project.

I've also dropped their make package in the respective tool chains and set up their repackaging of MSYS.

There is also MSYS2 out there, but it's so close to Cygwin that I'm curious as to WHY they had to fork now (there's also some emotion about it)

The only nightmare on Windows is the PATH, I'll be damned if I am able to find an homogeneous solution for QtCreator, CMake(-gui) and the Command prompts, which does NOT involve changing JUST ONE envvar when needed?

PLUG: Does anybody know how to pass a purposely-tailored environment to an application through the windows shell?

Thanks Edgar, but that I know...unfortunately I meant actually changing the path in the windows shell as "through windows shell extension"

If I use a batch file it will change the path only in that console (the one that keeps open thatnks to '/k' )...and by the way THAT is the way MSYS and cmd are opened...but

...I also have things registry hacks like this

{"name":"608353","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/8\/28d53dd140f00ba69d93b7239ebe7ba3.png","w":514,"h":543,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/8\/28d53dd140f00ba69d93b7239ebe7ba3"}

and would like to be able to launch the thing with different environments.

Most PRACTICAL way in my workflow would be having an extentions that changes GLOBAL path before execution....but of course it's most because I'm lazy

I'm DUMB

setx is all the rage for this and it was right there in Siegelord's tutorial....