MinGW 7.2.1 compilation error


When compiling a simple JUCE app, MinGW issues an error when compiling the juce_win32_WebBrowserComponent.cpp file:

In static member function ‘static void juce::WebBrowserComponent::clearCookies()’:
…\JUCE\modules/juce_gui_extra/native/juce_win32_WebBrowserComponent.cpp:407:99: error: cannot convert ‘const char* const’ to ‘LPCWSTR {aka const wchar_t*}’ for argument ‘1’ to ‘void* FindFirstUrlCacheEntryW(LPCWSTR, LPINTERNET_CACHE_ENTRY_INFOW, LPDWORD)’
::HANDLE urlCacheHandle = ::FindFirstUrlCacheEntry (searchPattern, entry.getData(), &entrySize);

The culprit for this error is this line:

const auto searchPattern = “cookie:”;

To fix this, you should use the _T macro or the same TEXT marco:

const auto searchPattern = _T(“cookie:”);


const auto searchPattern = TEXT (“cookie:”);


This is fixed on the develop branch.

The fix was a little more complicated than that - unfortunately the MinGW distributed with Code::Blocks (which is fairly prevalent) had a bug in the format of the web browser calls, which we also had to work around.


Hello Tom,

Thanks for responding.
Fortunately, I always use the latest available MinGW builds I can get with the latest GCC version.
Usually, I use this one (it’s considerred to be the most popular one) or this one (with optimized threading). The easiest way to use them is to extract the downloaded archive file and to add the MinGW’s binary folder (e.g. C:\MinGW\bin) to the PATH environment variable. That’s it.
The latest MinGW builds already have many features you always complain about in your comments in the source code.
I never use MinGW provided with Code::Blocks. Maybe this is the time for JUCE to move on and use the most fresh MinGW builds?

One more thing, Tom. Could you remove -flto flag set by default in Projucer for MinGW or GCC, please? The point is it does not work properly sometimes and a user can always set it himself if he needs it.



Code::Blocks is relatively popular so we need to maintain compatibility with the bundled compiler as we get a lot of people without much Linux experience using it. We’re also limited to version 5.3.0 for full compatibility with CLion.

I’ve just pushed some LTO fixes to the develop branch. Could you pull the latest version and let us know where you’re running into linking issues?


Of course, it’s your decision.
But Code::Blocks and CLion both work flawlessly with other MinGW builds even if they are installed separately.
It’s just a matter of pointing to the desired MinGW installation (binary) path of your choice in IDE’s settings dialog.
Moreover, there are nightly builds of Code::Blocks that are distributed without MinGW and Code::Blocks can easily detect your compilers, including MinGW if its ‘bin’ folder is included into PATH. If not, then this is also a matter of setting the corresponding settings for a compiler in IDE. I don’t think developers who uses JUCE so incompetent that they cannot do that themselves and they need only the bundled version of MinGW. Possibly I’m wrong.

Regarding LTO. To be clear, there are no issues when linking with LTO flag. Compilations and linkages go flawlessly. The problem is that the resulting executable file sometimes doesn’t run or crashes when launched. This is not the fault of JUCE. This is something wrong with LTO in MinGW for Windows. I asked you to disable setting the LTO flag by default only. If the LTO flag is set by default then a developer will not understand what could cause crashing.

Of course, I’ll check your latest changes and let you know if it’s OK.



I’m aware that you can use modern versions of MinGW with Code::Blocks - I’m saying that we get a lot of people who are new to software development starting out with Code::Blocks who try the bundled compiler first. If that doesn’t work then they either blame JUCE or, worse, get discouraged and give up. We don’t want either of those.

CLion does not work flawlessly with other MinGW builds:


Ok. I see your point now.