On Tue, 04 Aug 2009, vszak...@users.sourceforge.net wrote:
Hi Viktor,
> 2009-08-04 03:32 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/vm/dynlibhb.c
> ! Fixed to not use dl*() functions on linux/sunpro.
Above modification simply broke working code by disabling all calls to
dl*() functions instead of adding -ldl to linked library list.
List of linked system libraries in linux/sunpro.cf should be taken from
linux/gcc.cf not from sunos/sunpro.cf
dlopen interface comes from SunOS so this code can be enabled for
native SunOS builds too not only for Linux.
Please check if it's also supported by MacOSX. If it's not supported then
we MacOSX developers should add support to native MacOSX interface to
manage dynamic libraries.
BTW Has anyone here access to HP-UX hosts?
I do not have access to such machines for nearly a year and I haven't
made any HP-UX build tests for quite long time with this OS. I would
like to ask Harbour developers/users to make such tests with current
SVN code and report any problems here.
> * config/linux/sunpro.cf
> ! Fixed to include gpm lib.
> ; TOFIX: linux/sunpro linking dies on:
> ../../../../../lib/linux/sunpro/libhbpcre.a(pcrecomp.o): In
> function `check_auto_possessive':
> pcrecomp.c:(.text+0x2952): undefined reference to `.CG4A.3263'
> pcrecomp.c:(.text+0x2959): undefined reference to `.CG4A.3263'
> pcrecomp.c:(.text+0x2b29): undefined reference to `.CG40.3253'
> pcrecomp.c:(.text+0x2b30): undefined reference to `.CG40.3253'
It's the results of mixed -xbuiltin=%all (implied by -fast) used with -KPIC
flag. It's probably bug in Linux port of Sun C compiler which is exploited
by code in source/hbpcre/pcrecomp.c.
Using -fast introduces problems to math operations due to not IEEE safe
FL arithmetic optimizations (it can be seen in hbtest results). It also
strongly reduces portability of created binaries. Code compiled with
-fast uses all local CPU features so cannot be executed by other processors
from the same family (x86 or SPARC). Please also note that -fast is on
the flags which have to be used for compiling and linking: both linker
and compiler have to know about some switches enabled by it.
I also do not understand why we have this setting in linux/sunpro.cf:
HB_ISAOPT ?= -xarch=386
Linux perfectly well works on different 32 and 64 bit SPARC CPUs.
This part for sure have to be removed.
The second thing I do not understand is why we have linux/sunpro64.cf
with:
HB_ISAOPT = -m64
include $(TOP)$(ROOT)config/linux/sunpro.cf
-m32 and -m64 are compile and link time switches to force 32 or 64 bit
model. The default model depends on host CPU and default compiler/OS
settings. In general on 64 bit platforms -m32 can be used to force
32bit memory model and on 32 bit platforms -m64 can be used to force
64bit memory model. In most of cases it means cross compilation though
many of 64bit platforms can execute 32bit binaries so programs compiled
with -m32 can be executed as native binaries. Some of such 64bit platforms
can even use -m32 mode as default. GCC also have above such switches on
most of platforms which supports 32 and 64 bit modes but I do not know
if it works in MS-Windows and MinGW now - 64bit support is quite new
in MinGW so it may not be ready yet.
Can you explain me what is your goal in adding separate linux/sunpro64.cf?
I also suggest to use:
ifeq ($(HB_BUILD_MODE),cpp)
HB_CMP = sunCC
else
HB_CMP = suncc
endif
instead of CC and cc. With above version you do not have keep path to
Sun C compiler at the beginning of PATH envvar so both GCC and Sun C
builds can be easy used. It should work also in SunOS. I hope Tomas
can confirm it.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
