+ 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/darwin/clang.mk
* config/darwin/gcc.mk
* config/darwin/global.mk
* config/darwin/icc.mk
* config/darwin/libs.mk
* utils/hbmk2/hbmk2.prg
* synced with Viktor's modifications in 3.4 branch:
; 2017-11-11 13:14 UTC Viktor Szakats:
* switch to call the C compiler to link dynamic libs on darwin,
which is the recommended way to do this, as suggested by Apple.
This also aligns the platform better with other *nix platforms.
'libtool' was used before, but that started having intermittent
issues around Sierra (mitigated by disabling parallel build),
which returned and got worse in High Sierra (with no remedy).
The symptom was 'ld: file not found: ' errors with the filename
not shown or appearing as garbage, then a 'libtool: internal link
edit command failed'. This was reported and will be fixed in a
future Xcode release.
Ref: Apple Radar 34944562
* config/global.mk
* config/rules.mk
+ added new user build envvar HB_USER_DCFLAGS
It allows to set C compiler parameters to compile .c code for
dynamic libraries.
* src/rtl/hbsocket.c
! fixed fcntl(F_SETFL) 3-rd parameter in hb_socketSetBlockingIO(),
By mistake I used long instead of int. it created problem on big
endian 64 bit machines.
* include/hbgtcore.h
* src/rtl/hbgtcore.c
+ added new C functions for GT programmers:
void hb_gt_BaseUnlock( PHB_GT pGT );
void hb_gt_BaseLock( PHB_GT pGT );
void hb_gtSleep( PHB_GT pGT, double dSeconds );
* src/rtl/hbgtcore.c
* src/rtl/gtcrs/gtcrs.c
* src/rtl/gtdos/gtdos.c
* src/rtl/gtgui/gtgui.c
* src/rtl/gtos2/gtos2.c
* src/rtl/gtpca/gtpca.c
* src/rtl/gtsln/gtsln.c
* src/rtl/gtstd/gtstd.c
* src/rtl/gttrm/gttrm.c
* src/rtl/gtwin/gtwin.c
* src/rtl/gtwvt/gtwvt.c
* src/rtl/gtxwc/gtxwc.c
* use new functions to unblock GT when low level TONE() code is
executed. It allows other threads to access shared GT driver
when one of them executes TONE()
* contrib/hbexpat/hbexpat.hbx
* regenerated automatically
* (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
