On Mon, 10 Aug 2009, Tamas TEVESZ wrote:
Hi,
> > > > * 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'll revisit the use of -fast then. the current flags were taken
> verbatim from the blastwave docs as a starting point, though it is
> true that they are using a quite different build environment than i do
> (i'm still in the process of coughing up something that resembles
> theirs).
> it is also true that they only do solaris, and frankly, linux/sunpro
> was a complete accident ;), but it can't be worse by more people
> keeping an eye on it.
I've just check that exactly the same link time problem exist in
su...@x86:
ld: fatal: relocation error: R_386_GOTOFF: file
../../../../../lib/sunos/sunpro/libhbpcre.a(pcrecomp.o): symbol .CG44.3465: a
GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file
../../../../../lib/sunos/sunpro/libhbpcre.a(pcrecomp.o): symbol .CG44.3465: a
GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file
../../../../../lib/sunos/sunpro/libhbpcre.a(pcrecomp.o): symbol .CG3A.3455: a
GOT relative relocation must reference a local symbol
ld: fatal: relocation error: R_386_GOTOFF: file
../../../../../lib/sunos/sunpro/libhbpcre.a(pcrecomp.o): symbol .CG3A.3455: a
GOT relative relocation must reference a local symbol
so it seems to be bug in x86 port of Sun C compiler.
I had to add -xbuiltin=%none to HB_USER_CFLAGS as workaround.
> > > 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 has nothing to do with sparclinux. there is no sunpro for
> sparclinux, so that combination wouldn't fly at all. linux/sunpro* is
> only for ia32 and x86_64 targets.
so it does not make anything and it may only create problems if sunpro C
is released for li...@sparc.
In such case it should be removed. Now real problem is created by
HB_ISAOPT ?= -xarch=v8
in sunos/sunpro.cf when you try to use sunpro with su...@x86.
I also see that -xstrconst and sunpro manual says that it's depreciated
and read only strings are default now so probably this also can be removed.
> > > 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
> i've played with this stuff quite extensively (on linux), and while
> basically true, practically it's a can of worms. the thing is, unless
> you pick a platform that is well supplied with both 32- and 64-bit
> binaries (libs, mostly, of course), you can hardly build even core hb
> - i had absolutely no luck with ubuntu (simply too much ia32-* stuff
> are missing for a hb build to be even remotely useful), whereas
> centos5 (rhel5) is much more friendly in this regard (i wouldn't mind
> someone with some suse-experience chiming in).
> i had INSTALL diffs somewhere explaining this, but they seemingly got
> lost; will redo them in due course.
Yes not all distributions gives full support for both modes.
Anyhow from sunpro manual:
Note that in previous compiler releases, the memory model, ILP32
or LP64, was implied by the choice of the instruction set with
-xarch. Starting with the Sun Studio 12 compilers, this is no
longer the case. On most platforms, just adding -m64 to the com-
mand line is sufficient to create 64-bit objects.
On Solaris, -m32 is the default. On Linux systems supporting
64-bit programs, -m64 -xarch=sse2 is the default.
so for su...@x86 sunpro64.cf is usable only if you wany to force compilation
of 64bit binaries using 32bit computer. It's a cross compilation which cannot
work because 32 bit computers cannot execute 64bit harbour compiler binaries.
It also have to be fixed.
IMHO pure sunpro.cf for Linux and SunOS should not have any switches which
will force given CPU type for cross compilation or memory model. Instead
it should always produce native binaries so anyone can simply use it on
any computer. Then if you want you can add many different sunpro*.cf files
with customized for CPU or cross compilation settings though it will make
compiler autodetection harder. I hope that we agreed it two weeks ago.
> > > 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?
> that you can (given you have the necessary libs n stuff) compile
> 32-bit target on a 64-bit system. this is what the variants without
> *64 do, on both linux and solaris.
no it doesn't. Documentation says that using sunpro for x86 (both linux
and sunos) it's necessary to explicitly set -m32 to force 32 bit mode.
It has to be redesigned.
> i wouldn't think this to be bad, though i am completely open to do it
> by other means. just kick me in the direction that fits your idea.
1-st of all sunpro.cf have to be usable for any hardware and OS
combination supported by sunpro C compiler and produce default
native binaries.
Then for users who do not like to use HB_USER_CFLAGS/HB_USER_LDFLAGS
to customise binaries you can add sunpro32.cf/sunpro64.cf/sunpro*.cf
with -m32/-m64 or any other hardware dependent settings to force some
memory model or cross compilation.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
