Compiling Harbour 3.4 in FreeBSD 11.1 amd64 - A full report

934 views
Skip to first unread message

Mario Lobo

unread,
Oct 24, 2017, 7:54:56 PM10/24/17
to Harbour Users
Hello to all.

First let me state that I succeeded in compiling harbour with all supported contribs under FreeBSD, and the apps and libraries of qtcontribs.
I'll post a similar report in the qtcontribs group.

Since I spent the month of October zeroed in on this (and qtcontribs also), I decided to post the most accurate report I could, describing the problems
I found and the steps I took to resolve them.


*** My system:

Platform: FreeBSD 11.1-STABLE amd64
Compiler: LLVM/Clang C 4.0.1 (tags/RELEASE_401/final) (64-bit)

Harbour 3.4 git pulled today.


=== Problems found ===

*** compile errors

1) I was having trouble compiling the following files:

contrib/xhb/filestat.c:
contrib/hbmzip/mzip.c
src/common/hbffind.c
src/common/hbfsapi.c
src/rtl/filebuf.c
src/rtl/filesys.c
src/rtl/fssize.c

because HB_USE_LARGEFILE64 is defined, and is triggering
the use of lseek64()/flock64()/ftruncate64()/stat64,
which do not exist on any FreeBSD amd64, and compilation stops
with:

stat64 undefined symbol

The terrible and completely ugly workaround I made to solve my
particular compilation problem was to edit all of the above .c files
and replaced all occurrences of:

#if defined( HB_USE_LARGEFILE64 )

with

#if defined( HB_USE_LARGEFILE64 ) && !defined( HB_OS_BSD )  

With these changes, compilation finishes without errors, and
everything works.

Although this solution solves a FreeBSD arch amd64 problem,
I'm sure it will cause problems for FreeBSD arch i386 compilation.

I know the intention in ChangeLog.txt:

2007-11-22 01:44 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

was to solve a problem but it created this one on BSD amd64 machines.

In bsd's case, the definition of HB_USE_LARGEFILE64 could be conditioned
to a detection of 'amd64' or 'i386'.

Perhaps

! HB_HOST_PLAT: bsd (x86_64)
! HB_PLATFORM: bsd (x86_64) (auto-detected)

could be used for this.



2) contribs hbmysql, sddmy and rddsql were not finishing compilation because
   they were not finding -lmysqlclient lib so I edited:
  
- added to contrib/hbmysql/hbmysql.hbc and contrib/sddmy/sddmy.hbc

{bsd}libpaths=/usr/local/lib/mysql

- added to contrib/rddsql/rddsql.hbc

libpaths=/usr/local/lib/mysql


3) found a small discrepancy: hbcups and hbicu were being skipped because hbmk was reporting
   it could no find the include files, despite:
  
export HB_WITH_ICU=/usr/local/include/unicode
export HB_WITH_CUPS=/usr/local/include/cups

Well, the project asks for:

export HB_WITH_MYSQL=/usr/local/include/mysql
export HB_WITH_CURL=/usr/local/include/curl
export HB_WITH_CAIRO=/usr/local/include/cairo
export HB_WITH_GS=/usr/local/include/ghostscript
export HB_WITH_MINIZIP=/usr/local/include/minizip

but in case of ICU and CUPS, it adds cups/cups.h and unicode/utypes.h
by itself. So in the case of these two, the correct form is:

export HB_WITH_ICU=/usr/local/include
export HB_WITH_CUPS=/usr/local/include

My small suggestion for consistency is to make these two have the same form as all the others but
it is not at all critical. It just took me a while to find out why they were not compiling since
I had everything needed by them.


-------------------------------------------------------------------------

*** Libs linking errors (when compiling qtcontribs57.hbp)

A lot of qtcontribs link to libgtqtc.(so | a), and gtqt.hbp was not linking to Qt libraries,

so I edited contrib/gtqtc/gtqtc.hbc.

Changed

{bsd|darwin}libs=stdc++

to

{darwin}libs=stdc++
{bsd}libs=stdc++ Qt5Core Qt5Gui Qt5Widgets

and added the following lines to it.

{HBMK_HAS_QT5&bsd}ldflags=-L${HB_QT_DIR}
{HBMK_HAS_QT5&bsd}dflags=-L${HB_QT_DIR}

-------------------------------------------------------------------------

After that, i exported the following:

export HB_OS_BSD=yes
export HB_USER_PRGFLAGS=-d__HB_QT_MAJOR_VER_5__
export HB_ARCHITECTURE=bsd
export HB_BUILD_VERBOSE=yes
export HB_BUILD_SHARED=yes
export HB_BUILD_UNICODE=yes
export HB_TR_SYSOUT=yes
export HB_BUILD_CONTRIB_DYN=yes
export HB_BUILD_PARTS=all
export HB_INSTALL_PREFIX=/usr/local/harbour
export HB_INSTALL_BIN=/usr/local/harbour/bin
export HB_INSTALL_LIB=/usr/local/harbour/lib
export HB_INSTALL_ETC=/usr/local/harbour/etc
export HB_INSTALL_INC=/usr/local/harbour/include
export HB_INSTALL_DOC=/usr/local/share/harbour
#
export HB_WITH_X11=/usr/local/include
export HB_WITH_MYSQL=/usr/local/include/mysql
export HB_WITH_CURL=/usr/local/include/curl
export HB_WITH_CAIRO=/usr/local/include/cairo
export HB_WITH_GS=/usr/local/include/ghostscript
export HB_WITH_GD=/usr/local/include
export HB_WITH_SLANG=/usr/local/include
export HB_WITH_PCRE=/usr/local/include
export HB_WITH_PCRE2=/usr/local/include
export HB_WITH_MINIZIP=/usr/local/include/minizip
export HB_WITH_SQLITE3=/usr/local/include
export HB_WITH_ICU=/usr/local/include
export HB_WITH_CUPS=/usr/local/include
#
export HB_WITH_QT=/usr/local/include/qt5
export HB_QT_MAJOR_VER=5
export HBMK_DIR_QT5=/usr/local/lib/qt5/bin
export HB_QTPATH=/usr/local/lib/qt5/bin
export HB_QT_DIR=/usr/local/lib/qt5
export HB_BUILD_ADDONS=qtcontribs57.hbp


I didn't need/want these:

export HB_WITH_ALLEGRO=no
export HB_WITH_FREEIMAGE=no
export HB_WITH_PGSQL=no
export HB_WITH_FIREBIRD=no
export HB_WITH_OCILIB=no



then gmake and gmake install

Log excerpt:

! Building Harbour 3.4.0dev from source
! MAKE: gmake 4.2.1 '/bin/sh'  
! HB_USER_PRGFLAGS: -d__HB_QT_MAJOR_VER_5__
! HB_INSTALL_PREFIX: /usr/local/harbour
! HB_INSTALL_BIN: /usr/local/harbour/bin
! HB_INSTALL_LIB: /usr/local/harbour/lib
! HB_INSTALL_INC: /usr/local/harbour/include
! HB_INSTALL_DOC: /usr/local/share/harbour
! HB_INSTALL_ETC: /usr/local/harbour/etc
! HB_BUILD_CONTRIB_DYN: yes
! HB_BUILD_SHARED: yes
! HB_BUILD_PARTS: all
! HB_HOST_PLAT: bsd (x86_64)  HB_SHELL: sh
! LD_LIBRARY_PATH: /Apps/Dbase/harbour/harbour4/lib/bsd/clang:
! HB_PLATFORM: bsd (x86_64) (auto-detected)
! HB_COMPILER: clang (v0400) (auto-detected: /usr/bin/)
! HB_HOST_PKGM: pkg
! Component: 'zlib' found in /usr/include
! Component: 'pcre2' found in /usr/local/include
! Component: 'gpm' not supported on bsd platform
! Component: 's-lang' found in /usr/local/include
! Component: 'curses' found in /usr/include
! Component: 'x11' found in /usr/local/include
! Component: 'wattcp/watt-32' not supported on bsd platform
! Source code: 2424d10cd6 master https://github.com/vszakats/harbour-core.git
gmake[1]: Nothing to be done for 'all'.
gmake[1]: Nothing to be done for 'all'.
! 'hbdossrl' library skipped (platform or compiler not supported)
! 'png' library skipped (local copy unused)
! 'hbpcre' library skipped (local copy unused)
! 'hbpcre2' library skipped (local copy unused)
! 'hbzlib' library skipped (local copy unused)


OBS - despite export HB_BUILD_ADDONS=qtcontribs57.hbp, qtcontribs doesn't build from here.

../bin/bsd/clang/hbmk2 ../bin/make.hb . first
! Harbour root: '../'  Project store: './'  Core build: yes  Addon: no
! Warning: Project not found, cannot be added: ./qtcontribs57/qtcontribs57.hbp
! Started build...
! Calculating build order for 72 projects...

I tried the full path /usr/local/harbour/addons/qtcontribs57.hbp but it was a no go.


In the end, there it is!

[~]>harbour -build

Harbour 3.4.0dev (2424d10cd6) (2017-10-24 18:00)
Copyright (c) 1999-2017, https://github.com/vszakats/harbour-core/

Harbour Build Info
---------------------------
Version: Harbour 3.4.0dev (2424d10cd6) (2017-10-24 18:00)
Compiler: LLVM/Clang C 4.0.1 (tags/RELEASE_401/final) (64-bit)
Platform: FreeBSD 11.1-STABLE amd64
PCode version: 0.3
Commit info: 2017-10-24 18:00:54 +0000
Commit ID: 2424d10cd609d077729bf9e762cc74dbc70bd7e5
Extra Harbour compiler options: -d__HB_QT_MAJOR_VER_5__
Build options:
---------------------------

[~]ls /usr/local/harbour/bin

3rdpatch.hb     harbour         hbformat        hbmk2           hbpp            hbspeed
commit.hb       hbdoc           hbi18n          hbnetio         hbrun           hbtest


And added this path to ldconfig

[~]ls /usr/local/harbour/lib

bsd                     libhbcrypto.so.3.4.0    libhbhttpd.a            libhbodbc.so.3.4.0      libhbxpp.so.3.4.0
libbz2.a                libhbct.a               libhbhttpd.so           libhboslib.a            libhbyaml.a
libed25519.a            libhbct.so              libhbhttpd.so.3.4       libhboslib.so           libhbyaml.so
libexpat.a              libhbct.so.3.4          libhbhttpd.so.3.4.0     libhboslib.so.3.4       libhbyaml.so.3.4
libgtcgi.a              libhbct.so.3.4.0        libhbicu.a              libhboslib.so.3.4.0     libhbyaml.so.3.4.0
libgtcrs.a              libhbcups.a             libhblang.a             libhbpipeio.a           libhbzebra.a
libgtpca.a              libhbcups.so            libhblzf.a              libhbpipeio.so          libhbzebra.so
libgtqtc.a              libhbcups.so.3.4        libhblzf.so             libhbpipeio.so.3.4      libhbzebra.so.3.4
libgtqtc.so             libhbcups.so.3.4.0      libhblzf.so.3.4         libhbpipeio.so.3.4.0    libhbzebra.so.3.4.0
libgtqtc.so.3.4         libhbcurl.a             libhblzf.so.3.4.0       libhbpp.a               libhbziparc.a
libgtqtc.so.3.4.0       libhbcurl.so            libhbmacro.a            libhbrdd.a              libhbziparc.so
libgtsln.a              libhbcurl.so.3.4        libhbmagic.a            libhbrtl.a              libhbziparc.so.3.4
libgtstd.a              libhbcurl.so.3.4.0      libhbmagic.so           libhbsix.a              libhbziparc.so.3.4.0
libgttrm.a              libhbdebug.a            libhbmagic.so.3.4       libhbsms.a              libhpdf.a
libgtxwc.a              libhbexpat.a            libhbmagic.so.3.4.0     libhbsms.so             libhwgdebug.a
libharbour.so           libhbexpat.so           libhbmemio.a            libhbsms.so.3.4         liblzf.a
libharbour.so.3.4       libhbexpat.so.3.4       libhbmemio.so           libhbsms.so.3.4.0       libminilzo.a
libharbour.so.3.4.0     libhbexpat.so.3.4.0     libhbmemio.so.3.4       libhbsqlit3.a           libminizip.a
libhbamf.a              libhbextern.a           libhbmemio.so.3.4.0     libhbssl.a              libmxml.a
libhbamf.so             libhbformat.a           libhbmisc.a             libhbssl.so             librddbm.a
libhbamf.so.3.4         libhbformat.so          libhbmisc.so            libhbssl.so.3.4         librddbm.so
libhbamf.so.3.4.0       libhbformat.so.3.4      libhbmisc.so.3.4        libhbssl.so.3.4.0       librddbm.so.3.4
libhbblink.a            libhbformat.so.3.4.0    libhbmisc.so.3.4.0      libhbtcpio.a            librddbm.so.3.4.0
libhbblink.so           libhbfoxpro.a           libhbmlzo.a             libhbtcpio.so           librddcdx.a
libhbblink.so.3.4       libhbfoxpro.so          libhbmlzo.so            libhbtcpio.so.3.4       librddfpt.a
libhbblink.so.3.4.0     libhbfoxpro.so.3.4      libhbmlzo.so.3.4        libhbtcpio.so.3.4.0     librddmisc.a
libhbbz2.a              libhbfoxpro.so.3.4.0    libhbmlzo.so.3.4.0      libhbtest.a             librddmisc.so
libhbbz2.so             libhbfship.a            libhbmxml.a             libhbtest.so            librddmisc.so.3.4
libhbbz2.so.3.4         libhbfship.so           libhbmxml.so            libhbtest.so.3.4        librddmisc.so.3.4.0
libhbbz2.so.3.4.0       libhbfship.so.3.4       libhbmxml.so.3.4        libhbtest.so.3.4.0      librddnsx.a
libhbbz2io.a            libhbfship.so.3.4.0     libhbmxml.so.3.4.0      libhbtip.a              librddntx.a
libhbbz2io.so           libhbgd.a               libhbmysql.a            libhbtip.so             librddsql.a
libhbbz2io.so.3.4       libhbgd.so              libhbmysql.so           libhbtip.so.3.4         librddsql.so
libhbbz2io.so.3.4.0     libhbgd.so.3.4          libhbmysql.so.3.4       libhbtip.so.3.4.0       librddsql.so.3.4
libhbcairo.a            libhbgd.so.3.4.0        libhbmysql.so.3.4.0     libhbtpathy.a           librddsql.so.3.4.0
libhbcairo.so           libhbgs.a               libhbmzip.a             libhbtpathy.so          libscrypt.a
libhbcairo.so.3.4       libhbgs.so              libhbmzip.so            libhbtpathy.so.3.4      libsddmy.a
libhbcairo.so.3.4.0     libhbgs.so.3.4          libhbmzip.so.3.4        libhbtpathy.so.3.4.0    libsddmy.so
libhbcomio.a            libhbgs.so.3.4.0        libhbmzip.so.3.4.0      libhbunix.a             libsddmy.so.3.4
libhbcomio.so           libhbgt.a               libhbnetio.a            libhbunix.so            libsddmy.so.3.4.0
libhbcomio.so.3.4       libhbgt.so              libhbnetio.so           libhbunix.so.3.4        libsddodbc.a
libhbcomio.so.3.4.0     libhbgt.so.3.4          libhbnetio.so.3.4       libhbunix.so.3.4.0      libsddodbc.so
libhbcomm.a             libhbgt.so.3.4.0        libhbnetio.so.3.4.0     libhbusrrdd.a           libsddodbc.so.3.4
libhbcomm.so            libhbgzio.a             libhbnf.a               libhbvm.a               libsddodbc.so.3.4.0
libhbcomm.so.3.4        libhbgzio.so            libhbnf.so              libhbvmmt.a             libsddsqlt3.a
libhbcomm.so.3.4.0      libhbgzio.so.3.4        libhbnf.so.3.4          libhbxdiff.a            libxdiff.a
libhbcommon.a           libhbgzio.so.3.4.0      libhbnf.so.3.4.0        libhbxdiff.so           libxhb.a
libhbcpage.a            libhbhpdf.a             libhbnortl.a            libhbxdiff.so.3.4       libxhb.so
libhbcplr.a             libhbhpdf.so            libhbnulrdd.a           libhbxdiff.so.3.4.0     libxhb.so.3.4
libhbcrypto.a           libhbhpdf.so.3.4        libhbodbc.a             libhbxpp.a              libxhb.so.3.4.0
libhbcrypto.so          libhbhpdf.so.3.4.0      libhbodbc.so            libhbxpp.so             libyaml.a
libhbcrypto.so.3.4      libhbhsx.a              libhbodbc.so.3.4        libhbxpp.so.3.4


I have attached the full compilation log, hbide and hbdbu screens, all natively compiled in FreeBSD 11.1

Please let me know your opinions and suggestions, and if I can be of any help or assistance.

I cannot thank Victor and Pitpal enough for providing these wonderful softwares.

Piece!

Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio.... YET!!]
 
"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."


compile.txt
hbide.jpg
hbdbu.jpg

Mario Lobo

unread,
Oct 24, 2017, 8:33:36 PM10/24/17
to Harbour Users
I meant Peace!

Mario Lobo

unread,
Oct 25, 2017, 5:40:33 PM10/25/17
to Harbour Users
I just found one extra error:

When compiling contribs/hbicu i was getting:

/usr/bin/ld: cannot find -licucore

The reason is that the shared libray libicucore.so doesn't exist in FreeBSD, and
this was causing the shared libs libsddsqlt3.so.3.4.0,  libhbsqlit3.so.3.4.0 and libhbicu.so.3.4.0
not to be generated.

Corrective action:

Edit  contrib/hbicu/hbicu.hbc and replace:

{HBMK_HAS_ICU&unix&!darwin}libs=icucore
{HBMK_HAS_ICU&unix&darwin}libs=icuuc icui18n icudata

with

{HBMK_HAS_ICU&unix&!(darwin|bsd)}libs=icucore
{HBMK_HAS_ICU&unix&(darwin|bsd)}libs=icuuc icui18n icudata


Att,

vszakats

unread,
Oct 25, 2017, 7:12:22 PM10/25/17
to Harbour Users
Hi Mario,

Thank you for all the info, it's clear and useful!
I'm going to process it into a commit and a reply
in the next few days.

-Viktor

vszakats

unread,
Oct 26, 2017, 12:06:46 PM10/26/17
to Harbour Users
Hi Mario,


On Wednesday, October 25, 2017 at 1:54:56 AM UTC+2, Mario Lobo wrote:
Hello to all.

First let me state that I succeeded in compiling harbour with all supported contribs under FreeBSD, and the apps and libraries of qtcontribs.
I'll post a similar report in the qtcontribs group.

Since I spent the month of October zeroed in on this (and qtcontribs also), I decided to post the most accurate report I could, describing the problems
I found and the steps I took to resolve them.

Thanks for your tests and writing this report —
it really does help adjusting the source for this
platform.
 
*** My system:

Platform: FreeBSD 11.1-STABLE amd64
Compiler: LLVM/Clang C 4.0.1 (tags/RELEASE_401/final) (64-bit)

Harbour 3.4 git pulled today.


=== Problems found ===

*** compile errors

1) I was having trouble compiling the following files:

contrib/xhb/filestat.c:
contrib/hbmzip/mzip.c
src/common/hbffind.c
src/common/hbfsapi.c
src/rtl/filebuf.c
src/rtl/filesys.c 
src/rtl/fssize.c

because HB_USE_LARGEFILE64 is defined, and is triggering
the use of lseek64()/flock64()/ftruncate64()/stat64,
 
Since it's also unclear for me and have no FreeBSD to test it,
I'd prefer to leave this untouched for now and let someone
come up with the optimal way to handle this out-of-the-box.

2) contribs hbmysql, sddmy and rddsql were not finishing compilation because
   they were not finding -lmysqlclient lib so I edited:
  
- added to contrib/hbmysql/hbmysql.hbc and contrib/sddmy/sddmy.hbc

{bsd}libpaths=/usr/local/lib/mysql

I'm going to add these.
 
- added to contrib/rddsql/rddsql.hbc

libpaths=/usr/local/lib/mysql

rddsql.hbc is meant for the backend-agnostic engine code,
so it's not supposed to containe anything SQL backend
specific — it's probably unnecessary if the libpaths= in the
previous point are present. Similar should probably added
for PostgreSQL and MariaDB as well.
 
3) found a small discrepancy: hbcups and hbicu were being skipped because hbmk was reporting
   it could no find the include files, despite:
  
export HB_WITH_ICU=/usr/local/include/unicode
export HB_WITH_CUPS=/usr/local/include/cups

Harbour uses the canonical name to access library headers
and some projects do it like mylib/mylib.h. You can find it
out from the -depkeyhead= .hbp setting, or the .c sources.

export HB_WITH_MYSQL=/usr/local/include/mysql

export HB_WITH_CAIRO=/usr/local/include/cairo
export HB_WITH_GS=/usr/local/include/ghostscript
export HB_WITH_MINIZIP=/usr/local/include/minizip

I believe these would have been auto-detected without
these settings. The rest: I've added them to auto-detection.
 
*** Libs linking errors (when compiling qtcontribs57.hbp)

A lot of qtcontribs link to libgtqtc.(so | a), and gtqt.hbp was not linking to Qt libraries,
{darwin}libs=stdc++
{bsd}libs=stdc++ Qt5Core Qt5Gui Qt5Widgets

Fixed.
 
and added the following lines to it.

{HBMK_HAS_QT5&bsd}ldflags=-L${HB_QT_DIR}
{HBMK_HAS_QT5&bsd}dflags=-L${HB_QT_DIR}

Fixed, but differently. (HB_QT_DIR is user-defined, so
it's best not to rely on it)

export HB_OS_BSD=yes
export HB_ARCHITECTURE=bsd

The above can be safely deleted. 
 
export HB_QT_MAJOR_VER=5
export HBMK_DIR_QT5=/usr/local/lib/qt5/bin
export HB_QTPATH=/usr/local/lib/qt5/bin
export HB_QT_DIR=/usr/local/lib/qt5

If any of the above is necessary on a default system, it's a bug.
Only HB_WITH_QT should be needed. HBMK_DIR_QT5 is 
defined by hbmk2, so if manually setting fixes anything, it's a
bug as well.
 
export HB_BUILD_ADDONS=qtcontribs57.hbp 

OBS - despite export HB_BUILD_ADDONS=qtcontribs57.hbp, qtcontribs doesn't build from here.
 
I tried the full path /usr/local/harbour/addons/qtcontribs57.hbp but it was a no go.

This feature seems to have accumulated some regressions.
It was an experiment from 2010 that went nowhere, so I'm going
to remove it to make the core/contrib builds to unbundle it from
3rd party issues.

3.4 supports running `make.hb .` from any non-Harbour directory
to build projects just like it is utilized to build contribs, which is
a better answer to the problem.


-Viktor

vszakats

unread,
Oct 26, 2017, 3:16:58 PM10/26/17
to Harbour Users
Mario,

You can use the hbmk2 filter {lngcpp} to detect when C++ mode is enabled.


Maybe it helps with QT projects.

-Viktor

Mario Lobo

unread,
Oct 27, 2017, 2:26:07 PM10/27/17
to Harbour Users
Thanks for the update, Viktor!

Things are pretty hectic at work so I haven't had the time to try all your changes
but I'll git pull it tonight and  report my findings with details as soon as I have them.

Mario

Mario Lobo

unread,
Oct 27, 2017, 6:34:20 PM10/27/17
to Harbour Users
Hi Victor!

Here are the results I got from your last commit.


[/Apps/Dbase/harbour/harbour4]>git pull
Updating 2424d10cd6..afd7fa31b5
Fast-forward
 ChangeLog.txt                    |  140 ++-
 README.md                        |   27 +-
 bin/3rdpatch.hb                  |    6 +-
 bin/make.hb                      |   11 -
 config/detect.mk                 |    8 +-
 config/hbpost.hbm                |    1 +
 contrib/3rd/sqlite3/sqlite3.c    | 6110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------
 contrib/3rd/sqlite3/sqlite3.diff |    8 +-
 contrib/3rd/sqlite3/sqlite3.h    |  191 ++--
 contrib/3rd/sqlite3/sqlite3.hbp  |    2 +-
 contrib/3rd/sqlite3/sqlite3ext.h |   10 +-
 contrib/gtqtc/gtqtc.hbc          |   13 +-
 contrib/gtqtc/gtqtc.hbp          |    5 +-
 contrib/gtwvw/doc/en/gtwvw.txt   |    2 +-
 contrib/gtwvw/doc/intro.en.md    |    4 +-
 contrib/gtwvw/gtwvwd.c           |    6 +-
 contrib/gtwvw/tests/demo.prg     |    4 +-
 contrib/hbamqp/core.c            |    2 +
 contrib/hbamqp/hbamqp.hbp        |    1 +
 contrib/hbbz2/hbbz2.hbp          |    2 +-
 contrib/hbbz2io/hbbz2io.hbp      |    2 +-
 contrib/hbcairo/hbcairo.h        |    4 -
 contrib/hbcairo/hbcairo.hbp      |    2 +-
 contrib/hbct/cterror.ch          |    2 +-
 contrib/hbcups/hbcups.hbp        |    2 +
 contrib/hbcurl/hbcurl.ch         |    2 +-
 contrib/hbcurl/hbcurl.hbp        |    3 +-
 contrib/hbexpat/hbexpat.hbp      |    2 +-
 contrib/hbfbird/firebird.c       |    9 +
 contrib/hbfbird/hbfbird.hbp      |    2 +
 contrib/hbfimage/hbfimage.hbp    |    2 +-
 contrib/hbgd/hbgd.hbp            |    1 +
 contrib/hbgs/hbgs.hbp            |    1 +
 contrib/hbhpdf/hbhpdf.hbp        |    2 +-
 contrib/hbicu/hbicu.hbp          |    2 +
 contrib/hbmagic/hbmagic.hbp      |    1 +
 contrib/hbmlzo/hbmlzo.hbp        |    1 +
 contrib/hbmxml/hbmxml.hbp        |    1 +
 contrib/hbmysql/hbmysql.hbc      |    1 +
 contrib/hbmysql/hbmysql.hbp      |    2 +
 contrib/hbmzip/hbmzip.hbp        |    2 +-
 contrib/hbmzip/mzip.c            |    2 +-
 contrib/hbnf/doc/en/aredit.txt   |    2 +-
 contrib/hbnf/doc/en/ntow.txt     |    2 +-
 contrib/hbnf/doc/en/nwsem.txt    |    4 +-
 contrib/hbnf/popadder.prg        |    6 +-
 contrib/hbodbc/hbodbc.hbp        |    1 +
 contrib/hbpgsql/hbpgsql.hbp      |    1 +
 contrib/hbsqlit3/hbsqlit3.hbp    |    2 +
 contrib/hbssl/hbssl.hbp          |    3 +-
 contrib/hbwin/hbwin.hbp          |    2 +-
 contrib/hbwin/tests/oletst1.prg  |    2 +-
 contrib/hbwin/tests/oletst2.prg  |    2 +-
 contrib/hbwin/tests/oletst3.prg  |    2 +-
 contrib/hbwin/tests/oletst4.prg  |    2 +-
 contrib/hbxdiff/hbxdiff.hbp      |    2 +-
 contrib/hbyaml/hbyaml.hbp        |    2 +-
 contrib/rddsql/sqlmix.c          |    2 +-
 contrib/sddfb/core.c             |    9 +
 contrib/sddfb/sddfb.hbp          |    2 +
 contrib/sddmy/sddmy.hbc          |    1 +
 contrib/sddmy/sddmy.hbp          |    2 +
 contrib/sddoci/core.c            |    4 -
 contrib/sddodbc/sddodbc.hbp      |    1 +
 contrib/sddpg/sddpg.hbp          |    1 +
 contrib/sddsqlt3/sddsqlt3.hbp    |    2 +
 contrib/xhb/WARNING.txt          |    2 +-
 doc/en/file.txt                  |    2 +-
 doc/en/hbinet.txt                |    4 +-
 doc/en/set.txt                   |    2 +-
 doc/gtslang.txt                  |   14 +-
 docs/faq.html                    |   14 +-
 include/hbapifs.h                |    2 +-
 include/hbarc4.h                 |    2 +-
 include/hbclass.ch               |    2 +-
 src/rtl/arc4.c                   |    2 +-
 src/rtl/gtsln/gtsln.h            |    2 +-
 src/rtl/memoedit.prg             |    2 +-
 src/rtl/tobject.prg              |    2 +-
 src/vm/classes.c                 |    2 +-
 80 files changed, 3907 insertions(+), 2807 deletions(-)
 

Here are all I exported this time:


export HB_BUILD_VERBOSE=yes
export HB_BUILD_SHARED=yes
export HB_BUILD_UNICODE=yes
export HB_TR_SYSOUT=yes
export HB_BUILD_CONTRIB_DYN=yes
export HB_BUILD_PARTS=all
export HB_INSTALL_PREFIX=/usr/local/harbour
export HB_INSTALL_BIN=/usr/local/harbour/bin
export HB_INSTALL_LIB=/usr/local/harbour/lib
export HB_INSTALL_ETC=/usr/local/harbour/etc
export HB_INSTALL_INC=/usr/local/harbour/include
export HB_INSTALL_DOC=/usr/local/share/harbour
#
export HB_WITH_QT=/usr/local/include/qt5
#

export HB_WITH_ALLEGRO=no
export HB_WITH_FREEIMAGE=no
export HB_WITH_PGSQL=no
export HB_WITH_FIREBIRD=no
export HB_WITH_OCILIB=no


Here are the errors that still vame up:

1)
adding this line

-deppkgname=minilzo:lzo2{pkg}

in hbmlzo.hbp caused the error bellow.

../../../../../contrib/hbmlzo/core.c:54:10: fatal error: 'minilzo.h' file not found
#include "minilzo.h"

in FreeBSD. The contrib/hbmlzo/3rd/minilzo doesn't get build, and there is no
minilzo port for FreeBSD any longer. It reports that it found minilzo in /usr/local/include/lzo
but thereis no minilzo.h there. The build fully stops here, so it is a no-go for BSD.

Erasing the above line from the .hbc normalizes everything.


2)
the lines bellow in contrib/hbicu/hbicu.hbc


{HBMK_HAS_ICU&unix&!darwin}libs=icucore
{HBMK_HAS_ICU&unix&darwin}libs=icuuc icui18n icudata

still couses hbicu libraries not to be build in FreeBSD.
They should be changed to:


{HBMK_HAS_ICU&unix&!(darwin|bsd)}libs=icucore
{HBMK_HAS_ICU&unix&(darwin|bsd)}libs=icuuc icui18n icudata


Other than these, all the other problems I reported are fixed!

I'll try to come up with an elegant solution for the

#if defined( HB_USE_LARGEFILE64 ) problem.

I will also test the lngcpp in qtcontribs (Thanks for the tip!)

Mario Lobo

Mario Lobo

unread,
Oct 27, 2017, 9:48:19 PM10/27/17
to Harbour Users
Victor;

Since my last response I've been trying to implement the use "lngcpp" in qtcontribs for almost 4 hours
without getting anywhere, so I took a more radical approach. I hope that my tampering with your code doesn't upset you but
it really solved the problem I was having.

The changess are very small and it worked beatifully.

I implemented a new HB_USER_CPPFLAGS environment variable option in hbmk2.prg to be used only when a C++ compiler is invoked.



Here is the diff file:

---------------------------------------------------------------------------------------------------------------------------
--- hbmk2.prg.ori     2017-10-24 19:24:33.000000000 -0300
+++ hbmk2.prg  2017-10-27 21:57:05.332462000 -0300
@@ -7984,13 +7984,23 @@
                   tmp4 := iif( tmp3 == _CCOMP_PASS_C .AND. ( hbmk[ _HBMK_lCPP ] == NIL .OR. ! hbmk[ _HBMK_lCPP ] ), hbmk[ _HBMK_aOPTCX ], hbmk[ _HBMK_aOPTCPPX ] )
                   cOpt_CompCPass := cOpt_CompC
 
-                  /* TODO: eliminate recursive macros from hbmk[ _HBMK_aOPTC ] */
-                  cOpt_CompCPass := StrTran( cOpt_CompCPass, "{FC}", ;
-                     iif( hbmk[ _HBMK_lBLDFLGC ], hb_Version( HB_VERSION_FLAG_C ) + " ", "" ) + ;
-                     GetEnv( "HB_USER_CFLAGS" ) + ;
-                     iif( Empty( hbmk[ _HBMK_aOPTC ] ), "", " " + ArrayToList( hbmk[ _HBMK_aOPTC ] ) ) + ;
-                     iif( Empty( tmp4 ), "", " " + ArrayToList( tmp4 ) ) + ;
-                     iif( Empty( hbmk[ _HBMK_aOPTCUSER ] ), "", " " + ArrayToList( hbmk[ _HBMK_aOPTCUSER ] ) ) )
+                  IF tmp3 == _CCOMP_PASS_C
+                     /* TODO: eliminate recursive macros from hbmk[ _HBMK_aOPTC ] */
+                     cOpt_CompCPass := StrTran( cOpt_CompCPass, "{FC}", ;
+                        iif( hbmk[ _HBMK_lBLDFLGC ], hb_Version( HB_VERSION_FLAG_C ) + " ", "" ) + ;
+                        GetEnv( "HB_USER_CFLAGS" ) + ;
+                        iif( Empty( hbmk[ _HBMK_aOPTC ] ), "", " " + ArrayToList( hbmk[ _HBMK_aOPTC ] ) ) + ;
+                        iif( Empty( tmp4 ), "", " " + ArrayToList( tmp4 ) ) + ;
+                        iif( Empty( hbmk[ _HBMK_aOPTCUSER ] ), "", " " + ArrayToList( hbmk[ _HBMK_aOPTCUSER ] ) ) )
+                  ELSE
+                     /* TODO: eliminate recursive macros from hbmk[ _HBMK_aOPTC ] */
+                     cOpt_CompCPass := StrTran( cOpt_CompCPass, "{FC}", ;
+                        iif( hbmk[ _HBMK_lBLDFLGC ], hb_Version( HB_VERSION_FLAG_C ) + " ", "" ) + ;
+                        GetEnv( "HB_USER_CPPFLAGS" ) + ;
+                        iif( Empty( hbmk[ _HBMK_aOPTC ] ), "", " " + ArrayToList( hbmk[ _HBMK_aOPTC ] ) ) + ;
+                        iif( Empty( tmp4 ), "", " " + ArrayToList( tmp4 ) ) + ;
+                        iif( Empty( hbmk[ _HBMK_aOPTCUSER ] ), "", " " + ArrayToList( hbmk[ _HBMK_aOPTCUSER ] ) ) )
+                  ENDIF
 
                   hReplace := { ;
                      "{OD}" => FNameEscape( hb_FNameDir( hbmk[ _HBMK_cPROGNAME ] ), nOpt_Esc, nOpt_FNF ), ;
@@ -19227,6 +19237,7 @@
       { "HB_USER_LIBPATHS"   , hb_StrFormat( I_( "accepts same values (space separated) as %1$s option" ), "-L" ) }, ;
       { "HB_USER_PRGFLAGS"   , H_( "options to be passed to Harbour compiler (before command-line options)" ) }, ;
       { "HB_USER_CFLAGS"     , I_( "options to be passed to C compiler (before command-line options)" ) }, ;
+      { "HB_USER_CPPFLAGS"   , I_( "options to be passed to C++ compiler (before command-line options)" ) }, ;     
       { "HB_USER_RESFLAGS"   , I_( "options to be passed to resource compiler (before command-line options) (Windows only)" ) }, ;
       { "HB_USER_LDFLAGS"    , I_( "options to be passed to linker (executable) (before command-line options)" ) }, ;
       { "HB_USER_DFLAGS"     , I_( "options to be passed to linker (dynamic library) (before command-line options)" ) }, ;
---------------------------------------------------------------------------------------------------------------------------

Please let me know what you think.      

Mario

vszakats

unread,
Oct 28, 2017, 3:06:27 AM10/28/17
to Harbour Users
Hi Mario,

Thanks for the fixes, I've committed them.


On Saturday, October 28, 2017 at 3:48:19 AM UTC+2, Mario Lobo wrote:
Victor;

Since my last response I've been trying to implement the use "lngcpp" in qtcontribs for almost 4 hours
without getting anywhere, so I took a more radical approach. I hope that my tampering with your code doesn't upset you but
it really solved the problem I was having.

The changess are very small and it worked beatifully.

I implemented a new HB_USER_CPPFLAGS environment variable option in hbmk2.prg to be used only when a C++ compiler is invoked.

Did you try this option?:
   -cpp=iso11

[ I'd like to avoid a parallel set of flags for C and C++. It creates
all sort of problems and misconfigurations and besides this
particular case, so far it was never needed. ]

-Viktor

vszakats

unread,
Oct 28, 2017, 3:54:20 AM10/28/17
to Harbour Users
Hi Mario,


On Saturday, October 28, 2017 at 12:34:20 AM UTC+2, Mario Lobo wrote:
I'll try to come up with an elegant solution for the

#if defined( HB_USE_LARGEFILE64 ) problem.

Not sure why, but in my tests the only problematic source
was mzip.c (before 2017-10-26 21:08 UTC), the rest built
fine as-is (amd64 FreeBSD 11.1-STABLE).

-Viktor

Mario Lobo

unread,
Oct 28, 2017, 9:44:32 AM10/28/17
to Harbour Users
Hi Viktor.

On Saturday, October 28, 2017 at 4:54:20 AM UTC-3, vszakats wrote:
Hi Mario,
 
Not sure why, but in my tests the only problematic source
was mzip.c (before 2017-10-26 21:08 UTC), the rest built
fine as-is (amd64 FreeBSD 11.1-STABLE).

-Viktor


I confirm that!

Just to make sure that no dangling files of mines were left,
I git checkout to a clean directory and made no changes to anything.

Everything compiled just fine without any errors whatsoever.

Thank you!

Mario

Mario Lobo

unread,
Oct 28, 2017, 10:14:46 AM10/28/17
to Harbour Users


On Saturday, October 28, 2017 at 4:06:27 AM UTC-3, vszakats wrote:
Hi Mario,
 
Did you try this option?:
   -cpp=iso11


Yes! I have tried it before and tried it again. No-go. The problem persists.
 
[ I'd like to avoid a parallel set of flags for C and C++. It creates
all sort of problems and misconfigurations and besides this
particular case, so far it was never needed. ]

-Viktor


 In *nixes is absolutely common to have several env vars to fine tune compilation processes
so it is normal for them to deal with those different vars all the time.

You find things like CPUTYPE,  CFLAGS, CXXFLAGS, COPTFLAGS, CC and CXX.

Like I said, In FreeBSD, clang won't run with an option meant for clang++. I know linux's
clang has an option -Wunused_command_line to turn the error into a warning and compilation can proceed but
it is not default. BSD clang doesn't have it.

FreeBSD's gcc/g++ has this behavior by default (no error, just a warning) but clang has been FBSD's default compiler for a while and,
in my humble opinion, is visibly faster and better.

I personally don't see an inconvenience of having HB_USER_CFLAGS and HB_USER_CPPFLAGS. If either is blank, it won't get set.
If you need the same option for both, just set both. I think of it as an extra flexibility. Yes, is is an opportunity for misconfiguration.
But assuming HB_USER_CFLAGS is good for both C and C++ also is, at least for BSD and linux.

In the *nix world there is a saying:


"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."

But I'm aware that you have to converge a LOT of OS possibilities in your project, of which
I have no knowledge of, so I'll respect and submit to your much better judgment.

Regards,

Mario Lobo

vszakats

unread,
Oct 28, 2017, 11:20:02 AM10/28/17
to Harbour Users


On Saturday, October 28, 2017 at 4:14:46 PM UTC+2, Mario Lobo wrote:


On Saturday, October 28, 2017 at 4:06:27 AM UTC-3, vszakats wrote:
Hi Mario,
 
Did you try this option?:
   -cpp=iso11


Yes! I have tried it before and tried it again. No-go. The problem persists.
 
[ I'd like to avoid a parallel set of flags for C and C++. It creates
all sort of problems and misconfigurations and besides this
particular case, so far it was never needed. ]

-Viktor


 In *nixes is absolutely common to have several env vars to fine tune compilation processes
so it is normal for them to deal with those different vars all the time.

You find things like CPUTYPE,  CFLAGS, CXXFLAGS, COPTFLAGS, CC and CXX.

Like I said, In FreeBSD, clang won't run with an option meant for clang++. I know linux's
clang has an option -Wunused_command_line to turn the error into a warning and compilation can proceed but
it is not default. BSD clang doesn't have it.

FreeBSD's gcc/g++ has this behavior by default (no error, just a warning) but clang has been FBSD's default compiler for a while and,
in my humble opinion, is visibly faster and better.

I personally don't see an inconvenience of having HB_USER_CFLAGS and HB_USER_CPPFLAGS. If either is blank, it won't get set.
If you need the same option for both, just set both. I think of it as an extra flexibility. Yes, is is an opportunity for misconfiguration.
But assuming HB_USER_CFLAGS is good for both C and C++ also is, at least for BSD and linux. 

In the *nix world there is a saying:

"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
 
The proposed -cpp= option is supposed to pass the option you
need _only in C++ mode_ and it was implemented to address this
very problem with passing C++ flavours. It is already being used
when building GTQTC, and it does build correctly on FreeBSD
with this option.

[ See commit 9b27f5e7074d736fb6e1908f84ad6555dbfbde5f
@ 2011-04-21 03:11 ]

Assuming that the requirement should be the same for any
code built against QT5, the GTQTC build config should work
with e.g. HBQT.

So what I'd like to understand is why it isn't, and how come
the -cpp= option passes its flag even in C mode, if this is the
case.

-Viktor

vszakats

unread,
Oct 28, 2017, 11:56:38 AM10/28/17
to Harbour Users
hbmk2: Compiling...
hbmk2: 'cd' to: ../lib/bsd/clang/.hbmk/gtqtc
hbmk2: C/C++ compiler command:
clang -c -O3  -DHBMK_HAS_QT5 -D_FORTIFY_SOURCE=2 -Wno-documentation-unknown-command -Wmissing-braces -Wreturn-type -Wformat -fPIC -I../../../../../include -I/usr/local/include/qt5 ../../../../../lib/bsd/clang/.hbmk/gtqtc/gtqtc.c
hbmk2: 'cd' back.
hbmk2: Compiling C++...
hbmk2: 'cd' to: ../lib/bsd/clang/.hbmk/gtqtc
hbmk2: C/C++ compiler command:
'clang++' -c -O3  -DHBMK_HAS_QT5 -D_FORTIFY_SOURCE=2 -Wno-documentation-unknown-command -Wmissing-braces -Wreturn-type -Wformat -fPIC -I../../../../../include -I/usr/local/include/qt5 -std=c++11 ../../../../../contrib/gtqtc/gtqtc1.cpp '../../../../../lib/bsd/clang/.hbmk/gtqtc/moc_gtqtc.cpp'

Mario Lobo

unread,
Oct 28, 2017, 12:56:48 PM10/28/17
to Harbour Users
Like I said to Pritpal, I am not able to find where in the qtcontribs.hbp hierarchy where should the -cpp option go.

Mario Lobo

unread,
Oct 28, 2017, 1:25:24 PM10/28/17
to Harbour Users
Ok! Found it. Inserting -cpp=iso11 on any of the projetct files worked so I tried the only thing (and most obvious thing) I haven't tried:

hbmk2 -cpp=iso11 qtcontribs57.hbp

And it worked!!

Please forgive my previous dumb attempts.

Mario

vszakats

unread,
Oct 28, 2017, 2:16:11 PM10/28/17
to Harbour Users

Like I said to Pritpal, I am not able to find where in the qtcontribs.hbp hierarchy where should the -cpp option go.


Ok! Found it. Inserting -cpp=iso11 on any of the projetct files worked so I tried the only thing (and most obvious thing) I haven't tried:

hbmk2 -cpp=iso11 qtcontribs57.hbp

And it worked!!

Please forgive my previous dumb attempts.

No worries, I'm glad it works now.

I think it should be added to hbqt/hbqt_common.hbm.

(It's already present in hbqt_common.hbc — for app —,
so that should be okay.)

-Viktor
 

Mario Lobo

unread,
Oct 29, 2017, 11:42:45 AM10/29/17
to Harbour Users

No worries, I'm glad it works now.

I think it should be added to hbqt/hbqt_common.hbm.

-Viktor
 

Yes!! That did it!

Thank you!!

Mario Lobo

unread,
Oct 29, 2017, 4:56:29 PM10/29/17
to Harbour Users
Viktor;

My next step is to create an official port of harbour for FreeBSD
and submit it to the FBSDF team for approval to be incorporated
in the ports tree.

The port will be based solely on your fork.
Please let me know if you have any objections to that.

Regards,

Mario

vszakats

unread,
Oct 29, 2017, 7:36:31 PM10/29/17
to Harbour Users
Hi Mario,
No objections from my part.

It raises the question of what name to use. Since I haven't
come up with any distinct name to differentiate my fork —
one solution is just to regard it as a subset/continuation of
mainline (non-fork) Harbour.

-Viktor

vszakats

unread,
Oct 29, 2017, 7:38:48 PM10/29/17
to Harbour Users

No objections from my part.

It raises the question of what name to use. Since I haven't
come up with any distinct name to differentiate my fork —
one solution is just to regard it as a subset/continuation of

I mean: superset

-Viktor

Mario Lobo

unread,
Oct 30, 2017, 12:31:47 PM10/30/17
to Harbour Users

Since there is already a port for harbour under lang/harbour (but it is
still the 3.0.0 version), I think harbour-devel could be a good name for it,
as it is the standard call in freeBSD ports, and it also fits the subset/continuation
quality you wish for it.

Mario
 

vszakats

unread,
Oct 30, 2017, 12:47:53 PM10/30/17
to Harbour Users
Ouch, that's pretty bad.

I'd think the 3.0.0 is worse as if there wasn't there anything.
It's an old version with a million issues fixed since.

-Viktor

Mario Lobo

unread,
Oct 30, 2017, 1:24:04 PM10/30/17
to Harbour Users
Tell me about it!

That's why I want to rush with this port.

Mario

Michael Green

unread,
May 25, 2018, 11:16:31 AM5/25/18
to Harbour Users
What is the status of harbour-devel, I can't find it in Freshports. Thanks.

Michael Green

unread,
Jun 24, 2018, 5:09:44 PM6/24/18
to Harbour Users


On Friday, May 25, 2018 at 4:16:31 PM UTC+1, Michael Green wrote:
What is the status of harbour-devel, I can't find it in Freshports. Thanks.
Shameless bump 

Mario Lobo

unread,
Jun 25, 2018, 8:41:29 AM6/25/18
to harbou...@googlegroups.com
Man .. I haven't had the time to prepare the port since I started this thread. Things have been hectic and I'm really busy at work.
But as sson as it slows down I'll do it. Hopefully during an upcoming vacation.

br,

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-users+unsubscribe@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!]

Michael Green

unread,
Jun 28, 2018, 11:47:37 AM6/28/18
to Harbour Users


On Monday, June 25, 2018 at 1:41:29 PM UTC+1, Mario Lobo wrote:
Man .. I haven't had the time to prepare the port since I started this thread. Things have been hectic and I'm really busy at work.
But as sson as it slows down I'll do it. Hopefully during an upcoming vacation.

No worries, as they say in the antipodes. I'm on 3.0.0 from the FreeBSD ports collection and it seems to work ok, but someone here said something about bugs, so I though I'd enquire.  

Michael Green

unread,
Aug 17, 2018, 8:07:27 AM8/17/18
to Harbour Users
Any news regarding a FreeBSD port of 3.4?



Reply all
Reply to author
Forward
0 new messages