WinLibs and compilations that fail with MapViewEx error

[MortenMacFly]

Hi there, remember me? :-) We once discussed about the MapViewEx errors that happen when compiling (large) projects like C::B with more recent WinLibs compiler versions.

I think I found the reason and a working solution here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101183

Esp. this hint:

msys2/MINGW-packages#5719
So you have to manually setdllcharacteristics on cc1.exe and cc1plus.exe

Having patched the compiler framework using the tool actually really works! And it works with all compilers that failed so far (at least for me).

So what I did is patching these files (which are in different folders depending on the version and flavour of your compiler):
cc1.exe, cc1obj.exe, cc1objplus.exe, cc1plus.exe, f951.exe
...with this tool from 2010 (!):
https://blog.didierstevens.com/2010/10/17/setdllcharacteristics/

...just thought this might be of interest for you, too.

[MortenMacFly]

...I found the old reference I was referring to:
#57

[brechtsanders]

I'm still trying to understand the exact issue.
Are you actually enabling or disabling DEP and/or ASLR to resolve the issue?

If you are disabling it, then you're really switching off an security feature intended to make sure an application isn't just starting code from a location that should contain data. DEP is also a feature you can disable in the OS. Have you tried if that makes a difference?

Is the original issue still present in MinGW-w64 10.0.0 (see latest winlibs release)?

[MortenMacFly]

I am switching it off both: ASLR and DEP (switches -n -d of the tool). And yes, I am aware of the consequences this may have.
I am currently using gcc-10.3.0-llvm-12.0.0-mingw-w64-9.0.0-r2, where this issues occurred at least less than with other releases. But it always has been there and I solved it by re-running the build as many times as needed. You should be able to reproduce if you try to compile: wxWidgets and C::B workspace with PCH enabled from scratch (btw.: It also occurs when PCH is disabled, just less likely - again, this is just a feeling). For me it fails for the C::B workspace latest.
I know that this should be resolved in the compiler actually, but the error with the memory mapping could really be because of address randomisation.
So I am not saying switch it off for your builds, but you may offer a downloadable patch for those who experience the issue and are willing to take the risk.
I have enabled this in the OS, too (otherwise most likely these switches would probably no effect anyway). But I would rather not switch it off on OS level because it would affect all applications.

[MortenMacFly]

I did not try the "totally latest" version you were referring to. This one is new to me (as it is just from 3 days ago!). I'll give t a try though...

[MortenMacFly]

...and I forgot it affects both: 32 and 64-bit compilers of gcc-10.3.0-llvm-12.0.0-mingw-w64-9.0.0-r2 to be precise.

[brechtsanders]

The version from a few days ago is built with the new MinGW-w64 10.0.0, so if there are patches in there it may be fixed now.

[MortenMacFly]

Just a side-note: I cannot use the bundle you were referring to easily as it does not ship with LLVM (and ccache) for which the first I would like to use to compile C::B plugins; and the latter I use on misc. other projects. The bundled items were one of the main reasons why I was using WinLibs in the first place... :-) Being curious: Is there a reason not to bundle these items?

[brechtsanders]

The bundled version of GCC+LLVM/CLang uses LLVM/CLang built with GCC's standard libraries.
However LLVM/CLang comes with its own versions of these libraries.
Mixing compilers that use different standard libraries would be asking for trouble, so I believe having a pure LLVM package with no GCC references would be a good idea.

A question for you: Do you have any instructions to build Code::Blocks from source (I already have all the prerequisites) using command line build tools (not Code::Blocks itself)?

[MortenMacFly]

Thanks for the clarification. I can understand this.

Do you have any instructions to build Code::Blocks from source

Depends on the platform:

• On Linux, you can use the Makefile-based build system.
• On Windows, its really the easiest to use a pre-build C::B to build C::B
• If that is not an option on Windows, there are patches (not yet in SVN to my knowledge) that allow using the automake / Makefile system on MSYS, alternatively C::B ships with a tool that allows converting C::B project files to Makefiles. But its some effort, unfortunately.

For what purpose? Maybe I can help?

[brechtsanders]

I would just like to have a native Windows 64-bit Code::Blocks, as there is no official download like that.

Maybe some people might even be interested in a Code::Blocks that comes with the winlibs compiler?

[MortenMacFly]

Well there is:
https://forums.codeblocks.org/index.php?topic=24902.0 (Nightly)
...and:
https://www.codeblocks.org/downloads/binaries/ (official).
You could simply use a zipped version (no need to install) here:
http://sourceforge.net/projects/codeblocks/files/Binaries/20.03/Windows/codeblocks-20.03-nosetup.zip

I am the one of the developers/releaser of Code::Blocks. And as TDM is no longer an option (which was standard up to now) WinLibs may really be a good alternative. But I won't promise anything here, as currently we are using MinGW 8.1.0 just fine, too.

[asmwarrior]

The bundled version of GCC+LLVM/CLang uses LLVM/CLang built with GCC's standard libraries. However LLVM/CLang comes with its own versions of these libraries. Mixing compilers that use different standard libraries would be asking for trouble, so I believe having a pure LLVM package with no GCC references would be a good idea.

Hi, brechtsanders, I'm also a C::B dev, and first, thanks for supply your great compiler suit. I use clangd for code completion plugin(see this C::B forum thread: [url=https://forums.codeblocks.org/index.php?topic=24357.0]Code completion using LSP and clangd[/url])

I mainly use the GCC supplied by msys2 projects, and if you look at its packages, there are two kinds of llvm/clang.

the first one is under mingw-w64-clang-x86_64-clang-tools-extra(clang64/bin/clangd.exe)
the second one is under: mingw-w64-x86_64-clang-tools-extra(mingw64/bin/clangd.exe).

I mainly use the second one, and the second one use the same libraries and headers as the gcc under the mingw64 sub folder.

I'm not sure how you build the llvm/clang, I just guess there is a way to share the headers files between gcc and clang.
Thanks.

[asmwarrior]

Another issue I'm concern is that msys2 project will drop the Windows 7 support soon, I'm not sure what is your plan, does winlibs will drop the Win7 support soon? Thanks.