+ 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/linux/clang.mk
! fixed rule for dynamic library
* src/3rd/png/Makefile
+ added -DPNG_ARM_NEON_OPT=0 to build flags
* contrib/3rd/sqlite3/sqlite3.c
* contrib/3rd/sqlite3/sqlite3.diff
! pacified warning
* contrib/gtwvg/gtwvgd.c
* contrib/gtwvg/wvgwing.c
! fixed missing break/return in case statements - please verify it.
* contrib/hbct/dattime3.c
* added #define _DEFAULT_SOURCE necessay in new Linux distors
* contrib/hblzf/3rd/liblzf/liblzf.diff
* contrib/hblzf/3rd/liblzf/lzfP.h
* do not use nested #define in #if statements - some C compilers do not
support it
* contrib/hbssl/bio.c
! tuned #if condition
* contrib/hbmisc/hbeditc.c
* simpliefied for condition and pacified warning
* contrib/hbodbc/hbodbc.hbp
* contrib/sddodbc/sddodbc.hbp
+ added check for iodbc library
* utils/hbmk2/hbmk2.prg
+ added support for clang in android builds
* include/hbdefs.h
+ added check for __BYTE_ORDER__ macro used in some new lib C
implementations
* include/hbapi.h
* include/hbdefs.h
* include/hbstack.h
* include/hbvmpub.h
* src/vm/classes.c
* src/vm/dynsym.c
* src/vm/estack.c
* src/vm/memvars.c
+ extended the size of dynamic symbol table from 65535 to 4294967295.
Adopting class code I decided to keep current algorithm of method indexes
hashing with only some minor modifications. It's very fast anyhow it may
cause noticeable (though static) quite big memory allocation for class
definitions in applications using millions of symbols and which increase
dynamic symbol table at runtime loading new classes dynamically form .hrb,
.dll, .so or other dynamic libraries supported by Harbour. It's random
and rather impossible to exploit situation in real life anyhow I cannot
exclude it so I'd like to report it in ChangeLog. The solution is very
simple, i.e. it's enough to use classic divide et impera algorithm using
symbol numbers to find method definition anyhow it will be slower then
current one and address only very seldom hypothetical situations so I
decided to not implement it. Such static memory cost begins to be
completely unimportant in the world of 64-bit architectures and extremely
big memory address space.
The modification was sponsored by TRES company.
* src/vm/estack.c
! fixed __mvClear() in MT builds - due to stupid typo GetList variable
was removed in MT programs by CLEAR MEMORY command (__mvClear())
So far noone reported it and I've found it analyzing the code before
increasing symbol table size.
* contrib/hbwin/hbolesrv.c
* updated for new size of dynamic symbol table
* 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/android/gcc.mk
* config/global.mk
* config/linux/gcc.mk
* config/postinst.hb
* contrib/hbpost.hbm
! removed version number from dynamic libraries for Android.
Pure Linux style dynamic library numbers in Android systems can be used
only with system libraries but it's not supported inside .apk packages
so our dynamic libraries were unusable for Android programmers unless
someone plans to install more then one version of Harbour dynamic
libraries as Android system libraries. It's rather unusual situation
and I believe that in such case he can easy create such libraries
building Harbour for Linux with NDK.
* enabled by default building contrib dynamic libraries in Harbour
Android build.
+ added -Wl,--no-undefined to linker parameters when dynamic libraries
are created to verify if dynamic libraries can be used in Android .apk
packages during Harbour build process.
; After above modification dynamic (*.so) libraries created in Harbour
build process can be used in .apk packages. It means that projects
like HDroidGUI do not longer need their own custom versions of
libharbour.so but can use the one from standard Harbour Android build.
They can also use Harbour contrib dynamic libraries.
; TODO: add support for automatic NDK detection in Harbour build process
; TODO: add to HBMK2 basic support for generating .apk packages
* contrib/gtqtc/gtqtc.hbp
* disabled dynamic GTQTC library in Android builds until we set explicit
bindings with QT/C++ dynamic libs
* 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/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/globsh.mk
* use $(CP) as workaround for missing soft links in NT shell.
I know about mklink but it needs quite new Windows version
and soft links need special privileges. Anyhow better solution
is highly welcome.
* config/postinst.hb
* use hardlinks or copy files if symlinks do not work
* config/linux/gcc.mk
* added support for non SH shells - it allows to create Android
builds in MS-Windows using Android NDK from Google.
* (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
