using gcc 4.3.3, it too builds, in both c and cpp modes.
granted, this is not core (yet), but maybe there's a way around this
(maybe in a similar way as external/libhpdf/ explicitly switches to
c mode).
Is this a new error after latest changes?
don't know, haven't built on linux (where there's qt) in a while. i'll
check out an older version to see, any particular recommendations
(before revision this-and-that)?
Perhaps r12086 (2009-08-12 14:36) would be interesting to check.
I used to build linux/sunpro, but don't remember such error.
Moreover it's quite interesting that the suncc command is executed,
but it's just silently doing nothing.
../../../../../lib/linux/gcc/libharbour-2.0.0.so @__dyn__.tmp -
lncurses
-lslang -lX11 -lrt -ldl -lm
gcc: @__dyn__.tmp: No such file or directory
make[3]: *** [libharbour-2.0.0.so] Error 1
make[2]: *** [descend] Error 2
Here it works (latest ubuntu), but we can change it if this isn't
yes, newer gccs work. don't have exact versions, though,
Okay, I've changed back all gccs to use to older safe method.
Should be okay, if not shout.
portable enough. We can use the other method also used in mingw.mk.
Could you give it a try? (INPUT(<filename>) in disk file and
omitting '@' from cmdline).
i see you've committed it in the meantime. that works, yes, but
Or we can just plain pass the list of objects. On most *nixes this
should not be a problem.
i'd still vote for this, though. no particular reason, just gives me a
warmer fuzzier feeling. whatever. just don't break not even gcc2,
please ;)
Would have preferred to do this, but I have no information
on *nix cmdline size limits. Currently we'd need 30-32K,
and may go up to 40K on the mid run.
Found this:
http://www.in-ulm.de/~mascheck/various/argmax/
But for me it's difficult to conclude anything close to
real life.
If you *nix gurus think such is okay to do, I will do it,
it would even make rules simpler.
this however surfaced another issue:
ar crs ../../../../../lib/linux/gcc/libhbdebug.a dbgentry.o
dbgmenu.o dbghelp.o dbgtinp.o dbgtmenu.o dbgtmitm.o dbgtwin.o
debugger.o dbgtarr.o dbgthsh.o dbgtobj.o tbrwtext.o dbgwa.o
dbgbrwsr.o || ( rm -f ../../../../../lib/linux/gcc/libhbdebug.a &&
false )
gcc -shared -fPIC -L/usr/X11R6/lib -o ../../../../../lib/linux/gcc/
libharbour-2.0.0.so __dyn__.tmp -lncurses -lslang -lX11 -lrt -ldl -lm
/usr/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status
this is because the x11 libs are not in /usr/X11R6/lib but in
/usr/X11R6/lib64 (this being redhat, where "/usr/lib" is not always
the native isa, but always 32bits, whereas on debian /usr/lib is
always native, and you have /usr/lib32 for compat stuff; ditto for
/lib{,64} and the other similar dirs).
Yes, this has never been solved on the GNU Make level, the
64-bit flavor lib dir is sitting there commented since ages.
To solve this we can jump into detecting *nix (Linux?) ISA
to the extent we have enough information to decide on this.
If this information is there, it's easy to solve. But may
this isn't such easy.
The existing hbmk[2] logic here is to simply check for presence
of 64-bit dir and add it before regular dir if exist. Even lazier
solution is to always add the 64-bit dir, which I guess will be
ignored anyway by linker, if not there. For some reason though
this hasn't been done this way.
Choice is up to *nix gurus. I'd go for the simplest which
works w/o side-effects.
as a quick fix i've applied
--- config/linux/libs.mk (revision 12353)
+++ config/linux/libs.mk (working copy)
@@ -40,7 +40,7 @@
endif
ifneq ($(HB_HAS_X11),)
SYSLIBS += X11
- # SYSLIBPATHS += /usr/X11R6/lib64
+ SYSLIBPATHS += /usr/X11R6/lib64
SYSLIBPATHS += /usr/X11R6/lib
endif
ifneq ($(HB_HAS_GPM),)
this, but i really doubt this is the proper way.
We're on the same page. Well, I tend to think this is alright,
but maybe an extra existence check would be needed. Anyone?
note double "-fPIC -fPIC". i'm not seeing anything of the sorts with
sunpro. now it probably won't bite anything unix, but if it
manifests
itself on platforms where argument space is precious, it might be a
problem.
No idea yet, plus couldn't replicate it, but I'll look further.
uh. i don't see anything special in my env or anything, it's just so:
Not wanted to imply that.
$ svn diff
$ env | fgrep HB
$ env | fgrep FLA
$ make
! Building Harbour 2.0.0beta2 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_HOST_PLAT: linux HB_SHELL: sh
! HB_PLATFORM: linux (autodetected)
! HB_COMPILER: gcc (autodetected: /usr/bin/gcc /usr/bin/X11/gcc /usr/
X11R6/bin/gcc /usr/bin/)
! Component: 'openssl' found in /usr/include
! Component: 'gpm' found in /usr/include
! Component: 'slang' found in /usr/include
! Component: 'curses' found in /usr/include
! Component: 'x11' found in /usr/include
! HB_INSTALL_PREFIX automatically set to: /usr/local
! REVISION: 12352
make[2]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
gcc -I. -I../../../../../include -Wall -W -O3 -fPIC -fPIC -
c ../../../expropt1.c -oexpropt1.o
this on ubuntu 9.04 x64, with no configuration out of the ordinary, as
far as i can tell, and also on centos 4.8, with definitely no
configuration out of the ordinary (very fresh install, and i don't
know red hat enough to screw it up anyway :).
x64 is the key. The one I have is x86 only.
I tried to emulate -fPIC usage on windows after your mail, but there
there wasn't a problem, I'll recheck on Ubuntu ASAP.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
