I’ve seen the GNU toolchain and the IDE’s that run it getting somewhat of a bum rap here about bloated executables, only static linking, etc, etc, so I thought I’d throw in a comment or two about using these tools.
Firstly, the GNU toolchain runs on more platforms and contains more language front-ends and code-generating backends that you can shake a stick at: expecting it to be quite as “tight” as a pure platform-native compiler is a bit rich, really. That being said code performance/size comparisons are for the most part acceptable, if the toolchain is configured correctly. If you want the tightest possible code then go with the (expensive) Intel compiler which beats even msvc hands-down. Of course then you’re, as with msvc, bolloxed if you’re doing cross-development to OSX. GNU gcc is of course the platform compiler for OSX.
For windows developers using whatever version of Visual Studio, of course compiling native windows apps is a piece of piss: you need to know next to bugger-all about the toolchain to get your executable. Using the free compilers to get comparable results just takes a little bit of effort to understand what’s what. So here’s some what’s what about gcc & in particular MinGW gcc
MinGW gcc never repeat never statically links against windows system DLL’s. When you specify, say -lgdi32 to the linker it pulls in an import lib to resolve the function names only, which is of course exactly how msvc does it as well. For the really paranoid you can instead of specifying the import lib with “-lgdi32” supply the complete path to the dll itself - “c:\windows\system32\gdi32.dll” and the linker will resolve the needed names on-the-fly. Again absolutely no static code is imported from the DLL, just the function name stubs. This direct linking unfortunately doesn’t work for all DLL’s in the system directory ( but it does for gdi32.dll & wininet.dll among others). To compile a simple JUCE app you can specify
c:\windows\system32\gdi32.dll c:\windows\system32\wininet.dll -lwinmm -lrpcrt4 -lvfw32as linker parameters, and it’ll link just fine. I don’t think you really gain anything except a marginally faster link time with this though.
The GNU linker leaves a lot more symbolic information inside the executable by default in all configurations, so make sure you specify the “-s” linker option for release builds to remove all the extra cruft.
Building JUCE 1.14 with Dev-Cpp 126.96.36.199. The version 1.14 .dev project file has files missing from the project so it will build ok, but you’ll be left with undefined symbols when you try to link an application. Specifically the directory src\juce_appframework\gui\components needs the source files in that directory added. Also before you open the .dev file make the output directory “juce\bin” and ensure there are no spaces in your directory paths. Copy the dsound.h file from an SDK or someplace and you should be set to go.
If anyone is having problems with the gcc toolchain,dev-cpp,CBX, or Eclipse feel free to gimme a shout and I’ll try to help. Maybe Julian would be agreeable to me trying to knock together a Dev-Cpp “DevPak” for JUCE & a skeleton app template to ease the pain. I had at one time a DevPak for the VST & VSTGUI SDKs, but I was unfortunately not at liberty to distribute it because of Steinbergs licencing policy.