* src/vm/macro.c
* workaround MinGW/GCC 15+ excessive diagnostics in hb_macroTextSymbol()
to fix strict mode in CI, manifested with either of those messages:
error: 'memcpy' specified bound 4294967295 exceeds maximum object size
2147483647 [-Werror=stringop-overflow=]
error: 'memcpy' accessing 4294967295 bytes at offsets 4 and 0 overlaps
6442450943 bytes at offset -2147483648 [-Werror=restrict]
* utils/hbmk2/hbmk2.prg
* applied bcc64 fixes from hbmk2.prg posted by Carlos Vargas on
harbour-devel (reformatted):
https://groups.google.com/g/harbour-devel/c/vic0m-VVZ8k
; bcc64 support is not tested and purely based on contributions
* utils/hbmk2/hbmk2.prg
* make the MSVC version detection based on paths a little less
trustful. With rolling releases of these MS tools, it's more
likely that "random" numbers will appear in dir names.
* contrib/hbssl/hbssl.hbc
! actually target VS 2017 for libcrypto, libssl
* utils/hbmk2/hbmk2.prg
! slight rework of MSVC version detection, so it actually operates
with empty cPath_CompC variable
* also try to discover version number of future MSVC releases
* with Zig building GUI applications on Windows, hbmk2 will
now pass -Wl,/subsystem:windows to the linker
+ 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/global.mk
* follow up to previous, define __ARCH64BIT__ for .prg files
if applicable during first stage done by GNU Make
* consider Alpha a 64-bit CPU too when it's a cross-build target
(untested)
* utils/hbmk2/hbmk2.prg
* updated stored list of Visual Studio (2013-2022) versions to C comp
revisions, which could be used in .hbp files HB_COMP_VER macro
; https://learn.microsoft.com/en-us/cpp/overview/compiler-versions
more detailed versioning available if someone is interested in that
please submit a patch that would translate C compiler path to
version according to the linked rules - MSVC now has rolling
releases
* utils/hbmk2/hbmk2.prg
* updated approach to define __ARCH64BIT__ at .prg level when
cross-compiling for such architecture.
Thanks to Alexey Zapolskiy for noticing.
+ local hb_RightEq() deployed as macro
* 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/wasm/global.mk
+ config/wasm/libs.mk
+ config/wasm/emcc.mk
* utils/hbmk2/hbmk2.prg
* contrib/hbrun/hbrun.hbp
+ add basic support for build Harbour into JS/WebAssembly using
emscripten, using these settings:
HB_PLATFORM=wasm HB_COMPILER=emcc HB_BUILD_3RDEXT=no
* {abstr} is now a hbmk2 keyword to possibly group all
toolsets similar in flavour: WASI/clang, JS/emscripten
These most likely will be targeting plaforms which are not
full operating-systems, they are also commonly qualified as
sandbox solutions.
* introduced __PLATFORM__WASM and __PLATFORM__ABSTRACT .prg defines
* utils/hbmk2/hbmk2.prg
+ allow to specify hb_ProgName() value at build-time for platforms
where the function cannot return a meaningful value (f.e.
JS/WebAssembly)
; TODO: Add support for passing hb_ProgName() value command-line
parameter, f.e. `--hb:self=hbrun`
* config/global.mk
* include/hbsetup.h
* consider abstract/emscripten targets similar to linux-like
* src/rtl/arc4.c
! fix to build under emscripten (which is assumed to be a
linux-like environment)
; though platform/compiler names are not currently compatible
with origin, this WebAssembly platform support was guided by
Harbour 3.4:
2017-06-09 01:10 UTC Viktor Szakats (vszakats users.noreply.github.com)
as usual Viktor was here before, many thanks!
; example project, how to make a multi-platform GUI application which
also targets WebAssembly, can be found here:
https://github.com/alcz/harbour-cimgui-sokol-starterkit/
2025-01-24 19:15 UTC-0300 Mario Wan Stadnik (wanstadnik gmail.com)
* utils/hbmk2/hbmk2.prg
* http://timestamp.verisign.com/scripts/timstamp.dll has limped
along for the last few years and had been working in a sort
of depreciated state, but the new owners of the certificate
issuing business, DigiCert, have issued a migration alert so
we are switching to: http://timestamp.comodoca.com/authenticode
; It allows the user to choose the algorithm: SHA256 or SH1
* utils/hbmk2/hbmk2.prg
* do not interrupt whole build process when optional dependency package
is disabled explicitly by -depcontrol=<optdeppkg>:no
* contrib/gtqtc/gtqtc.hbc
* contrib/gtqtc/gtqtc.hbp
* respect QT_SELECT envvar looking for QT dependencies
* 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
Missing feature, can't find windres.exe for MingW64 14.2.0
With this mod it will find it automatically otherwise it will give the resource not find error because it will look for i686-w64-mingw32-windres.exe instead of windres.exe.
* .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
* debian/compat
* set 10 as compatibility level
* contrib/3rd/sqlite3/sqlite3.c
* contrib/3rd/sqlite3/sqlite3.diff
* do not use noinline function attribute in GCC prior 3.1
* contrib/xhb/xhberror.c
* src/rtl/gtdos/gtdos.c
! fixed format specifiers in HB_TRACE() messages
* src/common/expropt1.c
* src/rtl/langapi.c
* pass explicitly "(null)" string instead of NULL string pointer
to HB_TRACE() messages, some C compilers can autoinline functions
and generate warning detecting such situation
* src/pp/hbpp.c
* cast revision number to ( HB_ULONG ) to avoid warnings in some
compilers which do not understand %I64u format specifier
* utils/hbmk2/hbmk2.prg
* preffer HB_WITH_* settings then platform native pkg-config,
giving pkg-config precedence breaks cross and custom builds
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/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
* src/vm/fm.c
* src/macro/macro.y
* src/macro/macro.yyc
! guarded more C++ mode only pragmas for OpenWatcom. Issue #202
* utils/hbmk2/hbmk2.prg
! reverted C++ check
* 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
* bin/commit.hb
! fixed UTC offset formatting
* contrib/hbwin/win_os.prg
* updated win_osNetRegOk() for modern MS-Windows versions:
- on Win7 and upper set
System\CurrentControlSet\Services\LanmanServer\Parameters\DisableLeasing
to disable opportunistic locks.
- do not force SMB1 to disable oplocks on Win7 and upper - new MS-Win10
does not support SMB1 at all so this setting on the server with
such system completely disables SMB network and forcing SMB1 on the
client side blocks access to new Win10 servers.
Warning! this setting is still activated on Vista so it cannot
connect work with new Win10 but I do not know any other
working method to disable oplocks in Windows Vista.
* synced with Viktor's branch
* contrib/xhb/hbserv.c
! added missing return
* include/harbour.hbx
* src/harbour.def
* src/rtl/version.c
+ added new PRG functions:
hb_osIsWin7(), hb_osIsWin8(), hb_osIsWin81(), hb_osIsWin10()
* src/rtl/gttrm/gttrm.c
+ added autodetection for few other XTerm compatible terminals
+ respect color extension in TERM name of all XTerm compatible
terminals
* utils/hbmk2/hbmk2.prg
+ added support for -cpp=isoXX borowed from Viktor's branch
* contrib/gtqtc/gtqtc.hbc
* contrib/gtqtc/gtqtc.hbp
* use -cpp=iso11 required for QT 5.7.0 or upper
* extended QT detection and partial syncing with Viktor's branch
* include/harbour.hbx
* include/hbchksum.h
* src/harbour.def
* src/rtl/hbmd5.c
+ added new C function
void hb_hmac_md5( const void * key, HB_SIZE nKeyLen,
const void * message, HB_SIZE nMsgLen,
char * digest );
+ added new PRG function
HB_HMAC_MD5( <cMessage>, <cKey> ) -> <cMAC>
; HMAC MD5 is used in some authentication methods i.e. CRAM-MD5
authentication in SMTP protocol
* src/rtl/gttrm/gttrm.c
+ enable extended XTERM colors automatically when xterm-16color,
xterm-256color, xterm+256color, xterm-88color, rxvt-16color,
rxvt-256color, rxvt-98color or putty terminal is detected
+ added support for HB_GTI_SCREENDEPTH
* contrib/gtqtc/gtqtc1.cpp
+ set clipboard data also into selection buffer on platforms which
support it
+ when main clipboard buffer is empty retrieve clipboard data from
selection buffer and if it's empty too from find buffer
* include/harbour.hbx
* src/harbour.def
* src/vm/memvars.c
+ added new PRG function
__mvGetDef( <cMemvar> [, <xDefault> ] ) -> <xValue>
it works in similar way to __mvGet() but if <cMemvar> does
not exist then it returns <xDefault> or NIL instead of RTE
* contrib/hbwin/hbwin.hbx
+ added missing declarations for win_osIs10() and win_osIs81()
* contrib/hbssl/ssl.c
! fixed compilation with OpenSSL < 0.9.8k
* contrib/sddodbc/core.c
* pacified warning
* contrib/xhb/hbxml.c
* contrib/xhb/hbxml.h
! fixed CDATA terminator, it should be "]]>" instead of " ]]>"
+ added support for HBXML_STYLE_NONEWLINE flag
* src/3rd/pcre/Makefile
! typo wince -> wce
* src/main/Makefile
* use harbour.rc only in MS-Windows builds - it fixes OS2 OpenWatcom
builds
* config/global.mk
! in DOS builds check if the 'uname' exists before running it
* include/hbapigt.h
* include/hbgtcore.h
* src/rtl/hbgtcore.c
* src/rtl/inkey.c
* src/rtl/inkeyapi.c
* contrib/xhb/xhbfunc.c
+ added 3-rd parameter to hb_inkeySetText() function. When this parameter
is true then ';' is not translated to Chr( 13 ) but DOS and UNIX EOLs
are translated to Chr( 13 )
+ added logical parameter to HB_GTI_CLIPBOARDPASTE which allows to set
text without ';' translation but with platform independent EOLs
* src/rtl/memoedit.prg
* utils/hbmk2/hbmk2.prg
* contrib/hbnetio/utils/hbnetio/_console.prg
* extras/dbu/dbu52.patch
* extras/dbu/dbu53.patch
* use hb_gtInfo( HB_GTI_CLIPBOARDPASTE, .T. ) instead of
hb_gtInfo( HB_GTI_CLIPBOARDPASTE ) for pasting data from clipboard
with platform independent EOLs and ';' characters
* package/harbour.mft
+ added version manifest to Harbour compiler binaries, which is more
important on Windows 10 builds, to not include false Windows version
in build info.
This doesn't affect programs built with Harbour, where similar manifest
should be included or not, according to your needs.
* utils/hbmk2/hbmk2.prg
* define _UNICODE (activates unicode C RTL functions in OpenWatcom
and some MS C compilers) together with UNICODE in -winuni mode.
Similar change was done in Viktor's forked Harbour 3.4. Harbour
core/contrib code doesn't use any of these C RTL, but in most 3rd
party code it's expected that these are enabled both.
* 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
* contrib/hbrun/hbrun.hbp
* ChangeLog.txt
* package/harbour-wce.spec.in
* package/harbour-win.spec.in
* package/harbour.spec
* package/mpkg_rpm_wce.sh
* package/mpkg_rpm_win.sh
* package/mpkg_rpm.sh
* package/mpkg_src.sh
* package/mpkg_ver.sh
* package/mpkg_win.nsi
* package/winuni/mpkg_win_uni.nsi
* utils/hbmk2/hbmk2.hbp
* utils/hbmk2/hbmk2.prg
* utils/hbmk2/Makefile
* package/harb_osx.icns -> package/harbour.icns
* package/harb_win.ico -> package/harbour.ico
* package/harb_win.mft -> package/harbour.mft
* package/harb_win.rc -> package/harbour.rc
* utils/hbmk2/hbmk2.rc -> utils/hbmk2/harbour.rc
* sync more file renames with the 3.4 fork
NOTE: some projects used to rely on harb_win.ico. This will
not work anymore and these will need to be updated or even
better fixed to rely on it local .ico file instead.
* sync bash formatting and fixes. Formatting guidelines here
https://google.github.io/styleguide/shell.xml
* sync two hbmk2 macro names
* *
* partial sync with the 3.4 fork codebase. These are the things
synces for the most part:
- copyright headers
- grammar/typos in comments and some readmes
- comment/whitespace/decorations
- variable scoping in C files
- DO CASE/SWITCH and some other alternate syntax usage
- minimal amount of human readable text in strings
- minor code updates
- HB_TRACE() void * casts for pointers and few other changes to
avoid C compiler warnings
- various other, minor code cleanups
- only Harbour/C code/headers were touched in src, utils, contrib,
include. No 3rd party code, no make files, and with just a few
exceptions, no 'tests' code was touched.
- certain components were not touched were 3.4 diverged too much
already, like f.e. hbmk2, hbssl, hbcurl, hbexpat
- the goal was that no actual program logic should be altered by
these changes. Except some possible minor exceptions, any such
change is probably a bug in this patch.
It's a massive patch, if you find anything broken after it, please
open an Issue with the details. Build test was done on macOS.
The goal is make it easier to see what actual code/logic was changed
in 3.4 compared to 3.2 and to make patches easier to apply in both
ways.
* utils/hbmk2/hbmk2.prg
* remove `_HBSHELL_EXEC_PRE` macro
+ add `_HBSHELL_EXTRA_HEADER` macro that can be defined to a header
(.ch) filename which will be included in all dot prompt and script
execution sessions. The header will also be embedded in
hbmk2/hbrun at build-time, so it's not necessary to be present at
runtime. The macro may also be defined in the `hbmk2_extra.prg`
source.
* utils/hbmk2/hbmk2.prg
+ add ability to inject extra code/directives to the hbmk2/hbrun source
code at build time. It can be enabled by defining
`_HBMK2_EXTRA_CODE`, when a source file named `hbmk2_extra.prg` will
be included between the header and code section of hbmk2.prg.
+ display note when above option is enabled
+ add ability to prepend extra code before the shell execution stub via
the `_HBSHELL_EXEC_PRE` macro. It's initialized by an empty string in
a default build. This macro can be redefined at will by
`hbmk2_extra.prg`.
; commit backported to 3.2 from the 3.4 fork:
2017-05-14 19:35 UTC Viktor Szakats (vszakats users.noreply.github.com)
1ee9a9c6dc
* 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
* *
% remove brandings and homepage [1] from copyright header. Pass 1 - using script.
[1] nobody has access to it anymore AFAIK - and it's also just
a redirect since long
! update url in copyright header
; this should make the diff between 3.4 and 3.2 easier to manage
+ src/3rd/hbdossrl/Makefile
+ src/3rd/hbdossrl/serial.c
+ src/3rd/hbdossrl/serial.h
+ src/3rd/hbdossrl/README
+ added DOS Serial Library - it's much cleaner and simpler then COMLib
we used so far in DOS builds. It also supports hardware and software
flow control. Many thanks for Karl Stenerud for his wonderful job.
* src/rtl/hbcom.c
+ added support for DOS Serial Library used as low level backend in
Harbour DOS builds.
* config/dos/djgpp.mk
* config/dos/watcom.mk
* config/dyn.mk
* config/lib.mk
* src/3rd/Makefile
* src/Makefile
* utils/hbmk2/hbmk2.hbp
* utils/hbmk2/hbmk2.prg
* use DOS Serial Library (hbdossrl) instead of COMLib (hbpmcom)
* 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
