Hi Przemek,
Thanks a lot for these extensive tests and suggestions.
I've just committed last fixes targeting the issues found.
Pls retest.
Brgds,
Viktor
On 2009 Sep 20, at 12:03, Przemyslaw Czerpak wrote:
Hi Viktor,
I made some build tests with Harbour source code:
2009-09-19 14:43 UTC+0200 Przemyslaw Czerpak (druzus/at/
priv.onet.pl)
using different *nix system and C compilers and I have few notes.
I HAIKU builds I set HB_INSTALL_PREFIX=$HOME/hb and:
make install harbour in:
$HOME/hb/bin/
$HOME/hb/lib/harbour/
$HOME/hb/include/harbour/
in other *nixes for such setting Harbour is instaled in
$HOME/hb/bin/
$HOME/hb/lib/
$HOME/hb/include/
HOME in HAIKU is set to /boot/home.
HAIKU uses a little bit different localizations then other *nixes.
Looking at its dir structure I'm finding the following analogies:
/boot/common/{bin,lib,include,etc} => /usr
/boot/system/{bin,lib,etc} => /
/boot/home/config/{bin,lib,etc} => /usr/local
of course they are not exactly the same anyhow these localization
we can use as system wide. They are in default PATH and LIBRARY_PATH
(HAIKU does not use LD_ prefix). So to keep HAIKU synced with other
*nixes rules we should not add /harbour lib and inc suffix
unconditionally
but rather use sth like:
ifneq ($(foreach dir,/boot/common /boot/system /boot/home/config,
$(findstring |$(dir),|$(HB_INSTALL_PREFIX))),)
LIBPOSTFIX := $(DIRSEP)harbour
INCPOSTFIX := $(DIRSEP)harbour
endif
The -fixshared trick is GCC only specific feature and does not work
with other compilers I used: ICC, SUNCC.
It causes problems with HBMK2 which by default redirects -shared
switch to -fixshared for non system library directory so
it ends with error.
It should be changed and for non GCC *nix compilers -shared should
be redirected to -fullshared.
I tested that -fixshared works in g...@x86@32 builds on the following
OS-es: Linux, SunOS, HAIKU, FreeBSD, NetBSD and OpenBSD.
In HAIKU builds system library directory should be verified using
LIBRARY_PATH envvar instead of using hardcoded paths.
Probably in other *nixes it's good to extend hardcoded paths using
LD_LIBRARY_PATH to detect system localization.
In OpenBSD during linking external libraries bound indirectly by
linked
.so libraries (harbour.so in our case) are scanned only in /lib or /
usr/lib.
Other localizations supported by dynamic linker at runtime are
ignored by
default during linking.
For hbmk2 it means that in -shared mode if harbour.so is linked with
dynamic components from different localizations (i.e. /usr/X11R6/lib
for
X11 or /usr/local/lib for SLANG or PCRE) then during linking such
paths
have to be passed using -L GCC option.
Now hbmk2 shared linking in OpenBSD works only if necessary -L<path>
are manually specified by user.
HBMK2 does not support -fullstatic in SunPRO builds. To force static
mode
in SunPRO it's necessary to use '-B static' compiler switch. Of
course it's
possible that such final static binaries cannot be created or will
not work
as expected anyhow it's out of hbmk2 control which should only pass
valid
switches to compiler/linker.
In NetBSD builds (GCC 4.1.3) MT application linked in -fullstatic mode
GPFs. This is probably bound with __thread variable support but I'm
haven't checked it deeper but I had such problem with some older Linux
distributions.
In general in some OS-es/C compiler -fullstatic mode may not be fully
functional and it's out of our control. Just simply some functionality
may not be implemented in static system libraries.
In SunPROC Linux builds __constructor__ function attribute is ignored
sometimes and startup code is not executed. It means that some symbol
tables may not be registered in HVM and later we have GPF when such
code is executed. I can replicate the problem with hbtest which GPFs
because startup code from HBRTL is not executed.
It looks like compiler bug anyhow it's possible that we exploited
the problem recently. I'm not 100% sure but I think that over month
ago hbtest in sunp...@linux builds was working for me. If we can find
the exact reason which exploits the problem then we can try to add
workaround for it.
In ICC Linux builds HVMALL MT cannot be compiled with -fpic switch.
It ends with:
../../../../itemapi.c(1047) (col. 1): internal error: 0_1301
compilation aborted for ../../../../hvmall.c (code 4)
Looks that we exploited bug inside ICC compiler. The easiest
workaround
is setting HB_VM_ALL=no when ICC compiles HBVMMT library.
All other things worked as expected.
I tested native builds for Linux(GCC,ICC,SunPRO), SunOS(GCC,SunPRO),
HAIKU(GCC), FreeBSD(GCC), OpenBSD(GCC), NetBSD(GCC).
I checked basic harbour tools like hbrun or hbtest and speedtst in
MT mode (-thread switch to force parallel execution).
I also tested hbmk and hbmk2 using -[{fix,full}]shared and -[full]
static
switches.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
