MinGW errors

I wanted to try MinGW with juce for some faster then VS builds, and almost got it, but some errors appeared

First my gcc version is the latest i could find:

C:\Users\atom>gcc -v
C:\Users\atom>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,ob
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libg
mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.0 (GCC)

First there are the includes, DIRECTWRITE and WASAPI don’t work out of the box in MINGW had to disable those.

This is an error that turns into a warning if “-fpermissive” is passed to GCC

In file included from C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/juce_core.cpp:177:0:
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/native/juce_win32_ComSmartPtr.h: In member function 'HRESULT juce::ComBaseClassHelper<ComClass>::QueryInterface(const IID&, void**)':
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/native/juce_win32_ComSmartPtr.h:139:54: warning: there are no arguments to 'AddRef' that depend on a template parameter, so a declaration of 'AddRef' must be available [-fpermissive]

This one can be fixed by adding #include malloc.h somewhere in the code (alloca needs it)

In file included from C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_graphics/juce_graphics.cpp:85:0:
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_graphics/geometry/juce_EdgeTable.cpp: In member function 'void juce::EdgeTable::intersectWithEdgeTableLine(int, const int*)':
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_graphics/geometry/juce_EdgeTable.cpp:442:57: error: 'alloca' was not declared in this scope
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_graphics/geometry/juce_EdgeTable.cpp: In member function 'void juce::EdgeTable::clipLineToMask(int, int, const uint8*, int, int)':
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_graphics/geometry/juce_EdgeTable.cpp:693:82: error: 'alloca' was not declared in this scope

This one is related to windows versions (as described here http://stackoverflow.com/questions/5247862/error-with-regopenkeyex), I don’t know what windows versions JUCE supports i think there has to be some minimal XP build (SP2?). Setting the -D_WIN32_WINNT didn’t help much, had to replace the function getValueWow64() with something that does not use that KEY_WOW64_64KEY constant, since i don’t use the registry stuff myself it’s not a big problem for me.

In file included from C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/juce_core.cpp:180:0:
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/native/juce_win32_Registry.cpp: In static member function 'static juce::String juce::WindowsRegistry::getValueWow64(const juce::String&, const juce::String&)':
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/native/juce_win32_Registry.cpp:134:70: error: 'KEY_WOW64_64KEY' was not declared in this scope

This one can be fixed by replacing GetUserDefaultUILanguage() with GetUserDefaultLangID() (taken from the how to build GIMP on windows tutorial http://meudepositodeideias.wordpress.com/2011/12/19/how-to-build-gimp-2-7-5-using-mingw-in-windows-32-bits/)

In file included from C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/juce_core.cpp:181:0:
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/native/juce_win32_SystemStats.cpp: In static member function 'static juce::String juce::SystemStats::getDisplayLanguage()':
C:/devel/ctrlrv4/nightly/Builds/Standalone/JuceLibraryCode/modules/juce_core/native/juce_win32_SystemStats.cpp:406:68: error: 'GetUserDefaultUILanguage' was not declared in this scope
  1. Does MinGW provide improved support for c++11 over MSVC?

  2. What’s the secret for building an application that statically links to the standard C runtimes?

  1. i really don’t know, i quickly found a list of feature that gcc has now http://gcc.gnu.org/projects/cxx0x.html
  2. i don’t know what you mean by that ? the win32api libraries are in MINGW

How do you eliminate the dependency on mingwm10.dll?

Don’t know yet :slight_smile: I just got rid of the compiler errors, i’m trying to link the app right now, i don’t know if it’s at all possible. I’m looking into MINGW cause it links my app much faster then MSVC.

You get what you pay for. If you want your application to link fast in Visual Studio, turn off “Use Link Time Code Generation.”

I tried that some time ago but with or without that option it still takes way too long:

1>Link:
1>  Generating code
1>  Finished generating code
1>  Ctrlr_Standalone.vcxproj -> C:\devel\ctrlrv4\nightly\Builds\Generated\Windows\Standalone\.\Release_Nightly\Ctrlr-Win32.exe
1>PostBuildEvent:
1>          1 file(s) copied.
1>FinalizeBuildStatus:
1>  Deleting file ".\Release_Nightly\Ctrlr_Standalone.unsuccessfulbuild".
1>  Touching ".\Release_Nightly\Ctrlr_Standalone.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:30:06.30
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

In comparison i just got my MINGW build to run and the entire app takes:

----------Build Ended----------
0 errors, 0 warnings, total time: 00:03:00 seconds

So it’s a big difference.

I know why it takes that long, it’s the boost/luabind combo that does this. I wrapped some of the JUCE classes and am planning to wrap more so it will only get bigger. I’m trying to change my application so that the core app does not include luabind (and also boost) but it’s not that easy. The more luabind files i have the longer it takes to build, especially in the Release mode, the Debug mode seems to be very fast.

For those interested the compile flags i used are (release build):
-O3;-w;-fpermissive;-march=pentium;-pipe;-fomit-frame-pointer
The linker libraries needed are (opengl enabled)
libimm32;libglu32;libshell32;libole32;libws2_32;libimm32;libwinmm;libversion;libwininet;libopengl32;libuuid;liboleaut32;libshlwapi

Sounds like you haven’t set up precompiled headers in MSVC. Boost really needs precompiled headers to get sane compilation times.

Also, if you would like to eliminate your dependency on Boost you can replace LuaBind with LuaBridge which, coincidentally, I happen to be the maintainer of :lol: :lol: :lol:

LuaBridge is a single .h #include file that has no external dependencies. No .cpp, no library to link, just include the one file and off you go!

Your LuaBridge look very nice but i got so far with luabind that switching now would take too much time, also i got used to how luabind works.

The precompiled headers stuff, what do i need to do, just enable them ? Should i tell MSVC what files to use (it defaults to StdAfx.h)

Also i’m not sure if precompiled headers are what i need. 99% of the time is the linker time, the compilation runs quickly (i got 16cpus running in parallel).

A slow link is almost always the result of “Use Link Time Code Generation” in Release builds.

Hey…wait a minute, how do you have 16 cores? a Xeon?

Two xeons

and btw. is it possible to use JUCE with precompiled headers, i started to do some stuff on my code and i hit a dead end, i’d need to add my precompiled header file to the juce sources everytime i re-save the Introjucer project. Is it possible to use both ?

[quote=“atom”]and btw. is it possible to use JUCE with precompiled headers, i started to do some stuff on my code and i hit
a dead end, i’d need to add my precompiled header file to the juce sources everytime i re-save the Introjucer project. Is it possible to use both ?[/quote]

It is possible to use JUCE with precompiled headers. But I think that the question you are asking, is if it is possible for IntroJucer to preserve the precompiled header options in the project. My guess is no, because I don’t see any precompiled header options in the settings. You might be able to configure it through the “additional compiler options” and specify the switches manually. Perhaps you can get the precompile to include everything up to “JuceLibraryCode.h” this way.

Too compilcated i’ll stick what i have so far. I doubt this will decrease my link time anyway.

Precompiled headers will probably do nothing for the link time but did you turn off “Use Link Time Code Generation?”

Yes, the 30 minute link time is with this option disabled.

I assume you mean 30 seconds.

Does the link time go up when you re-enable LTCG (Link Time Code Generation ? If not then you’re doing something wrong with the setting. It’s interesting that my link time goes up to around 26 seconds when I turn on this option.

Try also setting “No Whole Program Optimization”.

If it was 30 seconds i wouldn’t be saying anything. IT IS 30 minutes. And no i haven’t found any speed up with this option enabled, i’ll do a complete clean and test with both options and report back.