Playing around with Clang and CX.

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
Very early this morning as I woke up and couldn't get back to sleep. I though I would have a play around with the current 8.0.1 release of clang and plug it into transcc with a few changes to the glfw template. So far other than warnings about wrapping logical-op-parentheses, the Linux compile times look to be a lot faster than they are with gcc. At some point today I will play around with clang on Windows, which will more than likely be a complete pain. But Visual Studio 2019, according to the MS, supports clang compiler integration, so I will check that out.

Previous version on windows didn't have a working linker and of course you still have to have a number of libraries, header files and build tools that can only be distributed with MinGW/Visual Studio.

Note: WebAssembly in llvm is no longer experimental and is one of the CPU output targets.
LLVM (http://llvm.org/):
LLVM version 8.0.1
Optimized build with assertions.
Default target: x86_64-unknown-linux-gnu
Host CPU: core2

Registered Targets:
aarch64 - AArch64 (little endian)
aarch64_be - AArch64 (big endian)
arm - ARM
arm64 - ARM64 (little endian)
armeb - ARM (big endian)
thumb - Thumb
thumbeb - Thumb (big endian)
wasm32 - WebAssembly 32-bit
wasm64 - WebAssembly 64-bit
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64

Not checked yet to see if there would be any problems with any of the android tools.
 
Last edited:

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
But Visual Studio 2019, according to the MS, supports clang compiler integration, so I will check that out.
I think I spoke a bit too soon. The current VS2019 (16.2) released on the 25th of this month uses cmake. A MSBuild version is suppose to be coming soon in a futures release. So for the time being it will be a MinGW thing or a dodgy 3rd party Visual Studio extension that's not being maintained.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
OK Windows+Clang+MinGW-w64 have hit a snag. And I'm not the only one.
Here's the output
Code:
clang -Xclang -flto-visibility-public-std -m64 -v -target x86_64-pc-windows-gnu -static  -pthread -Wno-macro-redefined -Wno-parentheses -Wno-logical-op-parentheses -Wno-bitwise-op-parentheses -D_CRT_SECURE_NO_WARNINGS -fuse-ld=lld  -O3 -DNDEBUG  -I../curl/include -I../glfw3/include -I../glfw3/src -I../openal/include -I../stb -I../zlib-1.2.8 -I../lpng1610 -c -o build/Release64/input.o ../glfw3/src/input.c
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-gnu
Thread model: posix
InstalledDir: J:\Applications\Compilers\LLVM\bin
"J:\\Applications\\Compilers\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name input.c -static-define -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -coverage-notes-file "C:\\Users\\Jason\\Desktop\\cerberus_clang\\examples\\mojo\\charlie\\blobmonster\\blobmonster.buildv2019-07-05\\glfw3\\clang_winnt\\build/Release64/input.gcno" -resource-dir "J:\\Applications\\Compilers\\LLVM\\lib\\clang\\8.0.0" -D _CRT_SECURE_NO_WARNINGS -D NDEBUG -I ../curl/include -I ../glfw3/include -I ../glfw3/src -I ../openal/include -I ../stb -I ../zlib-1.2.8 -I ../lpng1610 -internal-isystem "J:\\Applications\\Compilers\\LLVM\\lib\\clang\\8.0.0\\include" -internal-isystem "J:\\Applications\\Compilers\\mingw-w64\\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\\mingw64\\x86_64-w64-mingw32/sys-root/mingw/include" -internal-isystem "J:\\Applications\\Compilers\\mingw-w64\\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\\mingw64\\x86_64-w64-mingw32\\include" -internal-isystem "J:\\Applications\\Compilers\\mingw-w64\\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\\mingw64\\include" -O3 -Wno-macro-redefined -Wno-parentheses -Wno-logical-op-parentheses -Wno-bitwise-op-parentheses -fdebug-compilation-dir "C:\\Users\\Jason\\Desktop\\cerberus_clang\\examples\\mojo\\charlie\\blobmonster\\blobmonster.buildv2019-07-05\\glfw3\\clang_winnt" -ferror-limit 19 -fmessage-length 0 -pthread -fno-use-cxa-atexit -fobjc-runtime=gcc -fseh-exceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -flto-visibility-public-std -o build/Release64/input.o -x c ../glfw3/src/input.c -faddrsig
clang -cc1 version 8.0.0 based upon LLVM 8.0.0 default target x86_64-pc-windows-msvc
ignoring nonexistent directory "../zlib-1.2.8"
ignoring nonexistent directory "../lpng1610"
ignoring nonexistent directory "J:\Applications\Compilers\mingw-w64\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32/sys-root/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
../curl/include
../glfw3/include
../glfw3/src
../openal/include
../stb
J:\Applications\Compilers\LLVM\lib\clang\8.0.0\include
J:\Applications\Compilers\mingw-w64\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include
J:\Applications\Compilers\mingw-w64\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\include
End of search list.
In file included from ../glfw3/src/input.c:31:
In file included from J:\Applications\Compilers\LLVM\lib\clang\8.0.0\include\float.h:45:
J:\Applications\Compilers\mingw-w64\x86_64-8.1.0-release-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include\float.h:28:15: fatal error: 'float.h' file not found
#include_next <float.h>
              ^~~~~~~~~
1 error generated.
mingw32-make: *** [Makefile:60: build/Release64/input.o] Error 1
I will have to checkout the latest sources (8.0.1) and any fixes and see if I can build them without too much trouble if it's fixed.

I did figured out a way to be able to use both dwarf and seh versions of MinGW-w64 side by side.

As the default build of the Windows clang is for Visual Studio. I will see if there is a way to use it using this version of make for windows and see I fair better with Visual Studio.

If that fails, then it's a waiting game until the next update to Visual Studio 2019.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
OK first Windows Build. You can build the Linux version via the rebuildall.sh script. See BUILD_CLANG.txt on building for Windows and Linux.
Edit:
First Linux Build.

Should work with VS2015+
Download Clang 8.0.0 for Windows\Linux from here.

Windows Clang is an installer with the option to add it's path to the system or user PATH. In theory Cerberus Clang should work that way, but I haven't tested it. You can set the config variable CLANG_PATH in config.winnt.txt.
Cerberus Clang will also look in the third-party/tools/clang/windows directory. See the readme.txt file in there for the directories to copy over.

For Linux Clang, you can download and extract the archive to any location and use the config variable CLANG_PATH in config.linux.txt.
Or place it in the third-party/tools/clang/linux directory. Again see the readme.txt file in there.

NOTE: CLANG 8.0.0+MINGW-W64+GLFW WILL NOT WORK. SEE POST #4
Side note: Clang 8.0.0+MinGW-w64 will build C++ Tools are hard coded to use the -static switch.

OTHER STUFF:
I've given Ted a bit of a face lift. I've added a few menu items to set clang build options. The verbose and show warning one are not implemented yet. I've also add a new options dialog and added an updated image viewer and audio previewer. Note that you will need audio codecs for some file types. You can also set default applications to launch for files in the options dialog.

I've also added a Visual Studio project file that can be used to easily build Ted via scripts without having to jump through hoops setting up a build environment to use nmake. You just copy the msvc directory to the same directory level as Ted, change directory and call MSBuild with the appropriate parameters. See the clangbuild.ps1 file.

The launcher also has had a bit of a tweak to be able to build with MSBuild and XCodeBuild (may need a bit of work changing the xcode project file paths to look for icons and fully testing).

Ted will need testing out that I haven't broken any thing. Note that the new behaviour is to try and open the systems default applications of file types that are not known in the options dialog. On Linux you must enter the file extension when creating a new file or it will try and start the system's default application. Have to have a think on how to solve that little problem.

On the MinGW side of things. You can install MinGW-w64-dwarf and MinGW-w64-seh versions side by side. Using either 32 or 64 in one of the MSIZE preprocessor options will select the correct version. There is information in the config.winnt.txt file on this.
This has only been tested with MinGW-w64 and not TDM64.

I will upload this to my git repo in a few days in a branch called clang after I've worked out a few things and done a bit of testing, s
uch as the correct build parameters to pass to clang for Visual Studio.
 
Last edited:

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
OK finally got a working version of clang 9.0.0 working. I wouldn't say that it's a black art with all the options and no clear details. But when you get to the point of being prepared to drawing pentagrams in human blood on the floor and sacrificing virgins to make a pact with the devil, it kind of made me wish that I had started out doing that in the first place.

Well after many hour of trying to get the build right (and even now I'm not sure that I did). It turns out that the #include_next <float.h>issue still persists. So the issue is whether a regression has occurred in clang or the MinGW-w64 headers need updating. I will see if any older versions of either MinGW-w64 or clang will work. If it turns out that clang 8+ is the problem, it means WebAssebly generation is out.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
Christ, I cannot win.
As I have VS2019 installed I can't use any LLVM version less than 8 with it.
But MinGW with Clang 7 works. At least it shouldn't be too much trouble now that I've sorted out the GLFW make files if and when the float.h problem is sorted out.:rolleyes:
 

Dubbsta

Active Member
Joined
Jul 13, 2017
OK finally got a working version of clang 9.0.0 working. I wouldn't say that it's a black art with all the options and no clear details. But when you get to the point of being prepared to drawing pentagrams in human blood on the floor and sacrificing virgins to make a pact with the devil, it kind of made me wish that I had started out doing that in the first place.
:p:p:p
Thats all it took...seems like its paying off!
KUTGW
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
Well did a bit of looking into the clang8+mingw-w64 float.h problem.

Looks like the issue is with a change to the clang float.h header guard. The MinGW-w64 developer mailing list have known of this since August 2018. And there is a patch that can be applied. I'm now going to have a go and see if this works.

If it does, then the downside is that normal user MinGW download installs would require them applying the patch manually. Unless the powershell script I knocked up can do it.

RANT: WHY THE HELL DID THEY CHANGE THE HEADER GUARD WHEN THEY ARE GOING TO RELY ON THIRD-PARTY LIBRARIES TO DO THE BLOODY JOB!
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
OK, I'm in several minds here.
Thanks to MinGW yet again (this was the the cause of all the headache I had with the other project I was working on).
Using the current available downloads of MinGW-w64 (5.4.x to 8.1.x) with clang 8.0.0 are going to be a problem. Unless you have MSYS2 installed, then you should be quids in, but with it being a rolling release it could still break CerberusX.

The whole exercise was the hope of being able to use the WebAssembly output at some point. Now I'm wondering:
  • If I should put the clang integration on hold or just make sure that it will work with Clang 7 for now until the MinGW-w64 developer builds a working new stable release.
  • Just use the MinGW-w64 dwarf and seh side by side code and get it into the development branch.
  • Blow MinGW and clang off completely and just get CX to work with Visual Studio (my preferred choice). Makes dealing with CX much simpler if you're only dealing with the one compiler on Windows and not four of them (MinGW32, MinGw64, Clang and VS as it's now free). I'm sure Visual Studio and it's tools will be more tested than any MinGW or Clang compiler. And clang looks like it will always want the latest compiler with each new release.
 

dawlane

Active Member
CX Code Contributor
Joined
Jun 21, 2017
Wow that like jumping through fire and dancing on lava to get it working.
When the tools chains are in sync then clang would be a viable option. But and it's a big `but` as I have discovered. All it takes is for any one of the tool chains to make a few or minor change and the whole lot can come crashing down around your feet.

The current states of the tool chains.

Clang 7.1.0:
Works with MinGW 8.1.0 and Visual Studio 2017. Will not work with a newer version of Visual Studio, but should still work with later versions of MinGW (not confirmed yet).

Clang 8+
Works with MinGW 8.2/8.3+ (not confirmed yet) and Visual Studio 2019 only. The next major release of Visual Studio will more than likely require the latest release of clang which again could break MinGW integration.

TDM-GCC
Looks like it's no longer being maintained, has bugs and showing problems with CX on Windows 10.

MinGW-w64
Now up to version 9 with MSYS2, but the current default download is still at 8.1.0. You could dig around the downloads that are on sourceforge and get one of the multilib crt 7zips to update to 8.3, but you're having to take a chance on a third-party supplied binary. But I would get the sources to build my own, customise it to my liking. But building a 32 bit and a 64 bit release takes a bit of time.

Visual Studio
Well at least you will know that it's going to work well with Windows with the right SDK's and build tools installed.
The current setup of the project files look pretty much the same from 2015 onward. All that's usually wanted now to update is to select the SDK and platform tools. It's relatively easy to use vcxproj files with MSBuild and the current CX templates can be adapted to fit.
There may be a need to fix the warnings generated about `unsafe` functions, such as strcpy sometime in the future.

Clang in general
Clang on paper sounds like a good idea, but in the end, you are still having to write code for different tool chains. There's no one set of parameters that can be passed and you still have to rely on the build systems of the third party tool chain. If clang ever should break it's reliance on third party tool chains and become a full blown compiler with it's own build tools, libraries and header files, then it would be worth it. But I after eight major releases, this doesn't look to be the case.

And then there is Apple........ Who have a habit of doing there own thing with other peoples ideas.

Verdict
So I think for now Clang is going to be off the menu. If I did just a Visual Studio only CX it would make some unhappy, but you wouldn't have to go to extreme lengths building or using some third party shared libraries just to use with MinGW.

So I will do the updates to Ted and the rebuildall.ps1 file and throw in the MinGW dwarf/seh side by side for now.

After all this I'm surprised that I'm still reasonably sane.
 
Last edited:
Top Bottom