On Mon, 10 Aug 2009, Viktor Szakáts 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 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. > > 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. > > 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. 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. > > 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. > > Thanks, I'll do this in next commit. and now you broke it ;) the thing is, there are binaries named "cc" and "CC". there are no stuff named "suncc" and "sunCC". this is a tough one to crack so that noone gets hurt, but since i was the last one to arrive, i'm ready to take the pain. (on (at least some) linuxes alternatives could solve this cleanly, but as far as i can tell there is no such thing on redhat-like stuff, and certainly not on the bsds, for example, so it's ruled out...) still, the above logic is somewhat skewed on opensolaris, where you'll have "gcc" for gcc, and plain old "cc" for sunc, if the sunstudioexpress package is installed (only talkin 2008.11 as that's what i have atm), so if you happen to try there, beware that you may not get what you think you asked for ;) do we want to include these wrappers (as far as i can tell, not much heuristics would be needed to find them, at least if only "places people install sunc by convention" are taken into account), or document the need for such wrappers? -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
