2025-10-18 23:15 UTC+0200 Aleksander Czajczynski (hb fki.pl) ; Zig as LLVM C (cross)compiler

[Aleksander Czajczynski]

2025-10-18 23:15 UTC+0200 Aleksander Czajczynski (hb fki.pl)
+ 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.

[Mario H. Sabado]

HI Aleksander,

Thank you for adding support for the Zig compiler.

I was able to build the compiler (32 and 64 Windows 10) and libraries.  I noticed that during the linking phase of my application, it is trying to link libssleay32 even though the openssl-3.x was built successfully.  The same case is experienced with Clang and MSVC (32 and 64 Windows 10).  Mingw C (32 and 64 Windows 10) does not have this problem.

Best regards,

Mario

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F40897.7060109%40fki.pl.

[Aleksander Czajczynski]

2025-10-19 22:12 UTC+0200 Aleksander Czajczynski (hb fki.pl)
* 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

[Aleksander Czajczynski]

Mario H. Sabado wrote:
> HI Aleksander,
>
> Thank you for adding support for the Zig compiler.
>
> I was able to build the compiler (32 and 64 Windows 10) and
> libraries. I noticed that during the linking phase of my application,
> it is trying to link libssleay32 even though the openssl-3.x was built
> successfully. The same case is experienced with Clang and MSVC (32
> and 64 Windows 10). Mingw C (32 and 64 Windows 10) does not have this
> problem.
>
> Best regards,
> Mario

Hello Mario!

Thanks for the report.

I don't use hbssl / OpenSSL much myself. But to answer your question
I've tried to build current OpenSSL 3.6.0 under MSYS2 shell + Clang. Was
not exactly straightforward, but after applying some fixes, it is usable.

Didn't do anything for MSVC though. If you can tell what minimum version
of Visual Studio is needed to build current OpenSSL, maybe I'll use that
information to not break some ancient toolchains that others may still use.

Best regards, Aleksander

[Mario H. Sabado]

Hi Aleksander,

Many thanks for this fix.  After following your instructions using MSYS2 openssl environment settings, I was now able to build my application and run successfully using Zig Win x86_64 target.

For Zig Win x86 target, I got the following error but I can't trace any reference in my environment

*********************************************************************

lld-link: error: could not open 'libcrt.a': No such file or directory

*********************************************************************

Best Regards,

Mario

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F54B70.1040009%40fki.pl.

[Mario H. Sabado]

Hi Aleksander,

>Didn't do anything for MSVC though. If you can tell what minimum version
>of Visual Studio is needed to build current OpenSSL, maybe I'll use that
>information to not break some ancient toolchains that others may still use.

I'm using VS2022 Community edition.

Thanks and best regards,

Mario

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F54B70.1040009%40fki.pl.

[Mario H. Sabado]

Hi Aleksander,

Just an update:

I can already build my application using CLANG64 and MSVC2022 64 bit after your latest hbssl update.

For MSVC2022 64 bit with OpenSSL 3.x which is looking for ssleay32.lib during linking, I just reference from the HB_USER_LIBPATHS the location of ssleay32.lib (from OpenSSL_Win32_102q) and the build proceeds successfully.  This is currently the workaround that I have tested.

For Zig x86-windows target and MSVC2022 32 bit, both are trying to link libcrt.a and crt.lib respectively.

Thanks and regards,

Mario

[Aleksander Czajczynski]

Mario H. Sabado wrote:
> Just an update:
>
> I can already build my application using CLANG64 and MSVC2022 64 bit
> after your latest hbssl update.
>
> For MSVC2022 64 bit with OpenSSL 3.x which is looking for ssleay32.lib
> during linking, I just reference from the HB_USER_LIBPATHS the
> location of ssleay32.lib (from OpenSSL_Win32_102q) and the build
> proceeds successfully. This is currently the workaround that I have
> tested.

You shouldn't be doing that, apart from security issues from older
versions (likely if used with network connectivity), a mismatched header
and library will be a source of troubles if any of the interfaces changed.

Just changed the rules for MSVC here, recent Visual Studio should be
able to build current OpenSSL anyway.
https://github.com/harbour/core/commit/1b105c2d3d5bb31e01de8d8f2ebd02f2b440435a

>
> For Zig x86-windows target and MSVC2022 32 bit, both are trying to
> link libcrt.a and crt.lib respectively.
>

Haven't seen this one yet.

Best regards, Aleksander

[Mario H. Sabado]

On Mon, Oct 20, 2025 at 5:13 PM Aleksander Czajczynski <h...@fki.pl> wrote:

Mario H. Sabado wrote:
> Just an update:
>
> I can already build my application using CLANG64 and MSVC2022 64 bit
> after your latest hbssl update.
>
> For MSVC2022 64 bit with OpenSSL 3.x which is looking for ssleay32.lib
> during linking, I just reference from the HB_USER_LIBPATHS the
> location of ssleay32.lib (from OpenSSL_Win32_102q) and the build
> proceeds successfully.  This is currently the workaround that I have
> tested.
You shouldn't be doing that, apart from security issues from older
versions (likely if used with network connectivity), a mismatched header
and library will be a source of troubles if any of the interfaces changed.

 

Yes, I agree the unpredictable risk that this may cause.  Thanks 

Just changed the rules for MSVC here, recent Visual Studio should be
able to build current OpenSSL anyway.
https://github.com/harbour/core/commit/1b105c2d3d5bb31e01de8d8f2ebd02f2b440435a

Thanks Alexander, I'll test this. 

>
> For Zig x86-windows target and MSVC2022 32 bit, both are trying to
> link libcrt.a and crt.lib respectively.
>
Haven't seen this one yet.

 

 I think it's the frx fastreport lib that's causing this call.  Works ok with Mingw though.

Best regards,

Mario

Best regards, Aleksander

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F5FD1E.4010303%40fki.pl.

[Mario H. Sabado]

Hi Aleksander,

Below line inside the hbssl.hbc, the libs value that works for me is libssl and libcrypto.  Can this be updated?

>{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER>'1400'}libs=ssl crypto

Thanks,

Mario

[Aleksander Czajczynski]

Mario H. Sabado wrote:
> Hi Aleksander,
>
> Below line inside the hbssl.hbc, the libs value that works for me is
> libssl and libcrypto. Can this be updated?
>
> >{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER>'1400'}libs=ssl crypto
>

You're right, updated. Thank you.

Best regards, AC

[Mario H. Sabado]

Thank you Aleksander!  Very much appreciated.

Best regards,

Mario

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F65904.6020300%40fki.pl.

[Aleksander Czajczynski]

Of course I've typoed the compiler version, C compiler version internally is 19.10 for Visual Studio 2017
{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER<'1910'}libs=ssleay32 libeay32
{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER>'1909'}libs=libssl libcrypto

Can you check if this works for you?

Regards, AC


Mario H. Sabado wrote:

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/CAGuBOFqHH26jUgFGn5ohZMAF7b_EReJpTU71hLP9txkX310Pmw%40mail.gmail.com.

[Mario H. Sabado]

HI Aleksander,

On Tue, Oct 21, 2025 at 12:35 AM Aleksander Czajczynski <h...@fki.pl> wrote:

Of course I've typoed the compiler version, C compiler version internally is 19.10 for Visual Studio 2017
{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER<'1910'}libs=ssleay32 libeay32
{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER>'1909'}libs=libssl libcrypto

Can you check if this works for you?

I need to "set HB_COMPILER_VER=1942" (for VS2022) for me to work.  Without setting the compiler version results in linking of ssleay32/libeay32.

Thanks,

Mario

 

Regards, AC


Mario H. Sabado wrote:

Thank you Aleksander!  Very much appreciated.

Best regards,

Mario

On Mon, Oct 20, 2025 at 11:45 PM Aleksander Czajczynski <h...@fki.pl> wrote:

Mario H. Sabado wrote:
> Hi Aleksander,
>
> Below line inside the hbssl.hbc, the libs value that works for me is
> libssl and libcrypto.  Can this be updated?
>
> >{!HB_DYNBIND_OPENSSL&allmsvc&HB_COMP_VER>'1400'}libs=ssl crypto
>
You're right, updated. Thank you.

Best regards, AC

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F65904.6020300%40fki.pl.

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/CAGuBOFqHH26jUgFGn5ohZMAF7b_EReJpTU71hLP9txkX310Pmw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/68F664D5.5020504%40fki.pl.

[Miroslav Georgiev]

  I compiled Harbour on Windows 11 24H2 x64 for 64-bit Windows.
However, when I run the compiled programs on some older versions of Windows, they sometimes did start with a GPF (General Protection Fault).
Have you noticed this issue?  

[Mario H. Sabado]

Hi Miroslav,

In my case, I experienced the same when my application is compiled with newer C compiler version and ran on older Windows (i.e. Win7).  What works for me so far is MIngw C 7/8.x for older Windows.  I assume VC2015 should work but I have not tested it.

Best regards,

Mario

To view this discussion visit https://groups.google.com/d/msgid/harbour-devel/ed0c9065-6aa0-47fb-8d21-6687b277238bn%40googlegroups.com.

[Aleksander Czajczynski]

Mario H. Sabado wrote:
> Hi Miroslav,
>
> In my case, I experienced the same when my application is compiled
> with newer C compiler version and ran on older Windows (i.e. Win7).
> What works for me so far is MIngw C 7/8.x for older Windows. I assume
> VC2015 should work but I have not tested it.

If you are pointing to OpenSSL, then with MSVC you have to make sure if
it uses applink.c - HB_OPENSSL_HAS_APPLINK should be defined, is it? The
code looks like it only does it for 32-bit builds. Haven't looked at,
apart from recent correcting of libnames. Also it may be a problem when
libcrypto-*.dll, libssl-*.dll from different version than linked is used.

Best regards, Aleksander