* config/win/zig.mk
! in some Zig tests, building for Windows from UNIX shell (MSYS2
or cross compiling) resource compiler "zig rc" preferred options
passed with "-" instead of "/"
* contrib/hbssl/hbssl.h
* contrib/hbssl/hbssl.hbm
* contrib/hbssl/ssl.c
! HB_OPENSSL_HAS_APPLINK was never checked,
defining HB_OPENSSL_NO_APPLINK didn't do anything
* make current OpenSSL 3.6.0 build under fresh MSYS2
shell. MSYS2 does not distribute applink.c, claiming
MingGW C runtime is safe for operation without it.
Have to define HB_OPENSSL_NO_APPLINK and additional
workaround for lacking __int64 type when including
ssl.h. If you need similar workround outside of
MSYS2 shell, setenv: HB_USER_CFLAGS=-DHB_OPENSSL_MSYS
packages needed: openssl-devel (for headers)
mingw-w64-x86_64-openssl (for libs)
mingw-w64-aarch64-openssl
* contrib/hbssl/hbssl.hbc
* using Clang or Zig compiler on Windows, build will
now reference libssl and libcrypto instead of old
ssleay32/libeay32 pair when linking.
* config/win/zig.mk
% unnecessary check
+ config/bsd/zig-noauto.mk
+ config/bsd/zig.mk
+ config/common/zig-noauto.mk
+ config/common/zig.mk
+ config/darwin/zig-noauto.mk
+ config/darwin/zig.mk
+ config/linux/zig-noauto.mk
+ config/linux/zig.mk
+ config/win/zig-noauto.mk
+ config/win/zig.mk
* config/global.mk
* utils/hbmk2/hbmk2.prg
! typo fixed in Alpha target (this path was really untested)
+ added support for using Zig as LLVM C compiler frontend. Recent
idea comes from Marcos Gambeta Harbour++ fork, though I haven't
borrowed any code. Here the functionalty is complete, whole
Harbour source tree can be compiled, together with shared libs.
Zig has unique ability of managing cross-compiled builds, mostly
without downloading anything else. For example you should be able
to easily make a Linux+musl libc build of your Harbour application
that will run on any distribution with Linux kernel >= 2.6.39 (untested).
Zig is not auto-detected by the Harbour build process, HB_COMPILER=zig
has to be defined. The only exception is that, hbmk2 on Windows can
locate "zig.exe" while building final Harbour applications. Usually
there are no conflicting tools on PATH on this platform.
After downloading zig from https://ziglang.org/download/
specific to your OS, assuming the tool being unpacked to
/home/user/zig or C:\zig, usage is as follows:
Linux/BSD native build:
PATH=$PATH:/home/user/zig
HB_COMPILER=zig make -j8
Unix to Windows x64 cross:
PATH=$PATH:/home/user/zig
export HB_ZIG_TARGET=x86_64-windows
# (or) export HB_ZIG_TARGET=x86_64-windows-gnu
export HB_CPU=x86_64
# have to build a Harbour for your host first, for a native hbmk2
export HB_HOST_BIN=/home/user/harbour/bin/linux/zig
export HB_PLATFORM=win
export HB_BUILD_NAME=64cross
export HB_COMPILER=zig
make -j16
Windows native build:
PATH=C:\zig;%PATH%
set HB_COMPILER=zig
win-make -j8
Windows to Windows-on-ARM cross:
set HB_ZIG_TARGET=aarch64-windows
set HB_CPU=arm64
set HB_HOST_BIN=C:\harbour\bin\win\zig
set HB_COMPILER=zig
win-make -j8
Windows to Linux ARM64:
set HB_USER_CFLAGS=-fPIC
set HB_ZIG_TARGET=aarch64-linux
set HB_PLATFORM=linux
set HB_CPU=arm64
set HB_HOST_BIN=C:\harbour\bin\win\zig
set HB_COMPILER=zig
win-make -j8
Instead of setting HB_ZIG_TARGET, the less convenient way is:
HB_USER_CFLAGS=-target aarch64-linux
HB_USER_LDFLAGS=-target aarch64-linux
HB_USER_DFLAGS=-target aarch64-linux
Some target platforms need PIC mode even for static builds,
in such case add:
HB_USER_CFLAGS=-fPIC
; TOFIX: shared lib symlinks are not created when cross-building from
Windows to Linux, could copy or adapt modern Windows counterpart
olectl.h is missing when cross-building hbwin contrib from
Linux to Windows (likely needs headers from Windows SDK)
basically a non issue, but HB_CPU and HB_PLATFORM are not guessed
from HB_ZIG_TARGET - conversion table seems to be doable, if
someone is interested in making a patch.
* config/win/clang.mk
+ add resource compiler detection chain to first stage,
now harbour.exe binary should also have manifest resource
compiled in when clang is used. Previously second stage rc
calling was implemented only in hbmk2.
* utils/hbmk2/hbmk2.prg
! fixed disappearing llvm-ar with fallback to ar, spotted
in windows-ci/MSYS2
* config/global.mk
* config/win/clang-noauto.mk
* config/win/clang.mk
* supplemented config for Windows clang cross compilers
distributed in multilib fashion, like Martin Storsjo's:
https://github.com/mstorsjo/llvm-mingw
+ HB_CCPREFIX= support for clang on Windows, you can build
ARM64 Harbour from AMD64 hosts using mentioned toolchain:
set PATH=C:\llvm-mingw\bin;%PATH%
set HB_COMPILER=clang
win-make (build for your host first)
set HB_CCPREFIX=aarch64-w64-mingw32-
set HB_HOST_BIN=<HarbourPath>\bin\win\clang\ (if not autodetected)
win-make
; cross compiling from Unix hosts is not yet tested, but
looks very close to be possible
! fixed typo's
* utils/hbmk2/hbmk2.prg
* changed llvm-ar call to also respect HB_CCPREFIX
* .github/workflows/windows-ci.yml
* update windows MSYS2 integration runner set of
requested packages. PGSQL, Firebird and MariaDB libs
are no longer available in the 32-bit environment
+ add clang x86_64 compiler for testing under this CI
* include/harbour.hbx
* include/hbapi.h
* src/common/hbver.c
* src/harbour.def
* src/rtl/version.c
! fixed Windows 11 detection, by vendor likings it has
NT Kernel Version stamped with 10.0, so now Build Number
is more significant as a recognition factor.
+ new C helper functions hb_winisbuild(), hb_iswin11()
+ added PRG function hb_osIsWin11()
* also try to detect new Windows Server versions
* config/win/clang.mk
* utils/hbmk2/hbmk2.prg
* ChangeLog.txt
! recursion happening in the Makefiles rendered recently
introduced compatibility option unreliable. Changed to
use separate variable: HB_USER_FIXES=--mingw-script
You don't need it, the problem shouldn't exist, but
anyway...
+ config/win/clang-noauto.mk
+ additional clang flavour checking when the compiler is specified
via set HB_COMPILER=clang (not auto-detected)
This is important for distributions of clang that bundle both
gcc and clang in the same directory. Harbour 3.2 by default
prioritize gcc over clang.
For example you should be now able to build from winlibs.com by
Brecht Sanders with environment setup such as:
PATH=C:\winlibs\mingw64\bin;%PATH%
HB_COMPILER=clang
win-make
* config/global.mk
! added workaround for common GNU Make issue with
$(dir path with spaces/file) macro, commonly striking on Windows
systems under "Program Files", but also possible in other setups.
Workaround is to call $(call dir_with_spaces,$(HB_COMP_PATH)).
I have only used this workaround in clang detection, but keep
this in mind while revisiting detection of another compiler.
* config/win/clang.mk
* utils/hbmk2/hbmk2.prg
* another rework of Clang on Windows detection (ARM64, x86_64, x86),
solved problems with different availability of resource compiler,
They are now probed in order: windres, llvm-windres, llvm-rc.
* added option to use MinGW INPUT(file.o) link scripts for old tools
To apply workaround with clang, set HB_USER_DFLAGS=--mingw-script
It is not supported in at least some of current clang toolchains,
but it's still needed to succesfully build on old ones (those
using GNU ld on Windows).
* 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
+ config/win/msvcarm.mk
+ config/win/msvcarm64.mk
* config/global.mk
* include/hbsetup.h
* utils/hbmk2/hbmk2.prg
+ introduced support for Windows (10,11) ARM 64-bit platform
native compilers using Visual Studio 2022 Build Tools
before calling win-make, setup environment with:
<InstallPath>\BuildTools\VC\Auxiliary\Build\vcvarsarm64.bat
toolchain should be autodetected as following:
! HB_HOST_PLAT: win (arm64) HB_SHELL: nt
! HB_PLATFORM: win (arm64) (auto-detected)
! HB_COMPILER: msvcarm64 (auto-detected: C:/Program[...]/ARM64/)
to build final application with hbmk2 adding a valid Windows
Platform SDK / CRT paths to INCLUDE= and/or LIB= variable
is needed
; cross compilation from AMD64 hosts is possible:
vcvars64.bat
win-make (build Harbour for your host first)
set HB_HOST_BIN=<HarbourPath>\bin\win\msvc64
vcvarsamd64_arm64.bat
win-make
+ also added support for Windows for ARM 32-bit
before calling win-make, setup environment using:
<InstallPath>\BuildTools\VC\Auxiliary\Build\vcvarsarm.bat
or when cross compiling from ARM64 host:
<InstallPath>\BuildTools\VC\Auxiliary\Build\vcvarsarm64_arm.bat
; please test Windows CE builds if you're using compiler newer
than VC2003 for ARM for possible regressions
* contrib/hbmlzo/3rd/minilzo/lzodefs.h
! recognize ARM64 architecture on Windows to fix build error
; consider updating to upstream minilzo 2.10, issue is fixed there
* src/common/hbver.c
* changed to add processor architecture for MSVC compiler string
on non-Intel systems, as exposed by hb_compiler(), harbour /build,
finalapp.exe //build
* tests/speedtst.prg
* workaround that processor architecture can now appear
in hb_compiler(), so it's not printed by speed test twice
2023-11-11 19:42 UTC+0100 Phil Krylov (phil a t krylov.eu)
* config/win/mingw.mk
* utils/hbmk2/hbmk2.prg
! Use -D__USE_MINGW_ANSI_STDIO=0 to opt out of C99 printf emulation on
MinGW-W64 10.0+.
* config/dos/watcom.mk
* config/linux/watcom.mk
* config/os2/watcom.mk
* config/win/watcom.mk
* src/compiler/harbour.y
* src/compiler/harbour.yyc
* utils/hbmk2/hbmk2.prg
! fix OpenWatcom disabled warning listings, numeric specifiers have
different meanings in C (wcc386) and C++ mode (wpp386) compiler
executables. "-wcd201" - not fully sure about it, is now assigned
to C mode: "unreachable code". References issue #202.
* ChangeLog.txt
! fix UTF-8 char broken by Maurizio
* config/win/global.mk
* utils/hbmk2/hbmk2.prg
! moved winmm library before kernel32. This fixes Harbour compile and
application run on Win7 and previous Windows versions if latest MinGW
is used.
; Win8+ exports timeGetTime() from both kernel32.dll and winmm.dll.
Previous windows version exports this function only from winmm.dll.
See discussion at https://github.com/msys2/MINGW-packages/issues/4984
* utils/hbmk2/hbmk2.prg
! Fixed dependency detection. Setting HB_WITH_<package>=local was ignored
if packages were detected using pkg-config
* contrib/hbexpat/3rd/expat/siphash.h
! fixed compile error for BCC <= 5.6
* rediffed
* src/common/hbdate.c
* implemented monotonic timers in POSIX and MS-Windows builds
* config/wce/global.mk
* config/wce/mingwarm.mk
* config/win/global.mk
* utils/hbmk2/hbmk2.prg
* added winmm/mmtimer to list of system libraries - required
for timeGetTime()
* ChangeLog.txt
! typos
* config/dyn.mk
* config/win/mingw.mk
* src/dynlib/2nd/Makefile
* src/dynlib/Makefile
+ src/harbour.def
+ use .def file to specify public symbols of harbour.dll
for more details, see:
f238e5f81fb2c9e4a63b
; NOTE: please make sure to add any new public (HB_EXPORT)
symbols to this list. Ordinals are not significant
ATM so the best is to keep alphabetical order.
* config/dos/watcom.mk
* config/win/watcom.mk
* config/linux/watcom.mk
! enabled -bd OpenWatcom switch for code compiled as part of dynamic
libraries
* use CauseWay as default DOS extender for dynamic DOS builds
* config/dyn.mk
* config/lib.mk
* src/Makefile
! fixed list of libraries used to create Harbour DLL in DOS builds
* config/bin.mk
* src/vm/Makefile
* create hbmainstd library for OpenWatcom DOS shared builds
* src/vm/maindllh.c
+ added DLL entry function for CauseWay DLLs in OpenWatcom builds
* src/vm/main.c
* include maindllh.c in OpenWatcom DOS shared builds
* utils/hbmk2/hbmk2.prg
+ added support for dynamic binaries in DOS OpenWatcom builds.
Support for CauseWay DLLs is still broken in current OpenWatcom
builds so it will have to wait for the fix to be usable.
* src/vm/dynlibhb.c
+ added support for dynamic libraries to OpenWatcom DOS builds.
Now it's enabled only in harbour.dll due to problems with
CW and current OW.
* src/3rd/zlib/zconf.h
* src/3rd/zlib/zlib.dif
* use OS2 patch for exporting ZLIB symbols also in DOS builds
* src/rdd/dbf1.c
* pacified warning
* config/win/msvc.mk
* utils/hbmk2/hbmk2.prg
* disabled -nologo option used with resource compiler in MSVC builds.
Compiler version is not enough to detect supported parameters when
Platform SDK rc.exe is used.
* config/win/global.mk
* utils/hbmk2/hbmk2.prg
* src/rtl/hbsocket.c
+ added support for returning NIC MAC address by hb_socketGetIFaces()
in MS-Windows builds.
To see physical device addresses bound with active IP interfaces use:
#include "hbsocket.ch"
PROCEDURE Main()
LOCAL aIFace
FOR EACH aIFace IN hb_socketGetIFaces( , .t. )
? "IP:", aIFace[ HB_SOCKET_IFINFO_ADDR ], ;
" MAC:", aIFace[ HB_SOCKET_IFINFO_HWADDR ]
NEXT
WAIT
RETURN
* (all files)
* stripped svn header
* minor cleanups
; use following command to find out the history of files:
git log
git log --follow
git blame
git annotate
