Atualizações feitas por: Aleksander Czajczynski
Código: Selecionar todos
Hello friends of Harbour project!
Today i've commited a rework of Clang support on Windows,Ii hope for the decent results.
I suppose it was not so much a popular choice for Harbour on Windows, but looks like it is competitive now, as it works both in MingW64 compatible environment and as MSVC replacement.
Using clang also has drawbacks, due to so many distributions of it, I've decided to NOT add separate hbmk2 compiler identifiers like {clang,clang64,...}. Right now it follows the path similar single {gcc} seen under unix systems where one identifier covers multiple platforms. This may be rational, because compiler itself seems very portable, it's flags are common on all platforms in compiling stage. There are more problems in linking stage, due to different linking (ld) backends enabled by default. It's where oddities happen.
It means that theoretically we would rather have multiple sets: {mingwclang64}, {mingwclang64arm}, {msclang64}, {msclang64arm}
Feels like too much, though I've spotted in Viktor's tools, that he is using {clang64arm} extended definitions - probably on Mac?
For additional raw notes which I made during this task, see below commit msg.
On one of the future compiler related tasks I've scheduled WebAssembly additions - this may include Clang for wasm, i will rise some questions about in separate thread.
Best regards, Aleksander
Branch: refs/heads/master
Home: https://github.com/harbour/core
Commit: 77d37481beee4f964e90a0ad32bc2e127a6191f7
https://github.com/harbour/core/commit/77d37481beee4f964e90a0ad32bc2e127a6191f7
Date: 2024-10-07 (Mon, 07 Oct 2024)
2024-10-07 11:40 UTC+0200 Aleksander Czajczynski (hb fki.pl)
* config/global.mk
! detect ARM64 CPU on Windows also under non-native shell (MSYS2 sh)
* on unix also recognize aarch64 from uname
* include/hbsetup.h
* __MINGW64__ define is not x86_64 specific anymore
* config/win/clang.mk
* utils/hbmk2/hbmk2.prg
* reworked Clang on Windows detection (ARM64, x86_64, x86),
now it recognizes those flavours in PATH as distributed
by MSYS2 project and also Visual Studio 2022 Build tools.
Starting Harbour build process should be now possible
both from MSYS2 shell (with the special note to use "make"
command instead of "win-make" from sh) and regular batch
script/cmd shell.
Building on Clang distributed by MS x86_64:
PATH=<InstallPath>\BuildTools\VC\Tools\Llvm\x64\bin;%PATH%
win-make
Clang/MS ARM64:
PATH=<InstallPath>\BuildTools\VC\Tools\Llvm\ARM64\bin;%PATH%
win-make
Building on Clang x86_64 distributed by MSYS2 from cmd:
PATH=C:\msys64\clang64\bin;%PATH%
win-make
Clang/MSYS ARM64 called from cmd:
PATH=C:\msys64\clangarm64\bin;%PATH%
win-make
* src/common/hbver.c
* patched clang version string builder to skip duplicate version
number in some builds
* append processor architecture to clang compiler string
on non-Intel systems
--
Installing and using MSYS2
See https://www.msys2.org/wiki/arm64/
1. launch CLANGARM64 shell and execute:
pacman -Suy
pacman -S mingw-w64-clang-aarch64-clang
pacman -S make
2. enter Harbour installation dir or clone Harbour
make (not win-make!)
make -j12 (even better for fresh multi-core systems)
Other clang builds possible:
pacman -S mingw-w64-clang-x86_64-clang (in CLANG64 shell)
pacman -S mingw-w64-clang-i686-clang (needs manual path setting)
Additional notes
1. MSYS2 uses sh shell together with the toolchain, other distributions use native shell.
NOTE: do not use win-make.exe when executing from MSYS2 (sh) shell, install MSYS/GNU make (pacman -S make)
2. Apparently you can use MSYS2 distributed compiler from .bat/.cmd script, though MSYSTEM variable
should be set, Harbour build system tries to detect and set it in Makefiles, if it fails include it yourself
PATH=C:\msys64\clangarm64\bin;%PATH%
set MSYSTEM=CLANGARM64
Optionally you can set the build flavor:
set HB_BUILD_NAME=arm64msys
Then:
win-make
Yes, here you can proceed with win-make as usual.
Possible regressions
1. Lib producing on Windows, llvm-ar.exe is now used instead of ar.exe
2. Modern clang toolchains don't support INPUT(file.o) MingW style linking scripts,
so i resorted to putting whole command-line to a file at dynamic linking stage.
This on the other hand failed on old build of Clang when making harbour-32*.dll,
because clang.exe launches ld.exe as sub-process, using some method that limits
command line length, with file list already unpacked.
3. Keep old config/win/clang.mk(?) or set HB_BUILD_DYN=no if you don't need them.
Saudações,
Itamar M. Lins Jr.
