On Fri, 31 Jul 2009, Przemyslaw Czerpak wrote:
hi,
> > AFAIK SunPro has SPARC 32/64 and x86/x64 CPU targets. It can be
> > solved by simple few lines line long wrapper .cf files, so it won't
> > create any maintenance nightmare. For this reason I don't see this
> > is a problem at all in this
On Fri, 31 Jul 2009, Przemyslaw Czerpak wrote:
i certainly feel your pain, and you do have a valid point, but so do
i.
face it, you are a special breed, besides doing stuff in harbour, you
also know a metric shitload of toolchains and platforms inside out,
and want to make use of that knowle
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':
> > > pc
On Mon, 10 Aug 2009, Tamas TEVESZ wrote:
> > > 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
&
hi,
external/libhpdf/Makefile
39 ifeq ($(HB_XBUILD),)
40 HB_INC_LIBPNG = /usr/include
is there any reason for explicitly specifying /usr/include here? it'll
be picked up by the compiler anyway, but now i've found a case where
it _might_ cause some level of harm - probably not in hpdf, thoug
On Wed, 12 Aug 2009, Viktor Szakáts wrote:
hi,
> > 39 ifeq ($(HB_XBUILD),)
> > 40 HB_INC_LIBPNG = /usr/include
> >
> > is there any reason for explicitly specifying /usr/include here? it'll
> > be picked up by the compiler anyway, but now i've found a case where
> > it _might_ cause some l
On Wed, 12 Aug 2009, Viktor Szakáts wrote:
> > what i mean that after all the magic is done, it ends up with a
> > command line like that:
> >
> > cc -I. -I../../../../../include -K udk -KPIC \
> > -I../../../../../source/hbzlib -I/usr/include -c \
> > ../../../_hbhbpdf.c -o_hbhbpdf.o
On Wed, 12 Aug 2009, Przemyslaw Czerpak wrote:
> > > > 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 sun
On Sun, 16 Aug 2009, Phil Krylov wrote:
> On Sat, Aug 15, 2009 at 8:02 PM, Viktor Szakáts wrote:
> >> Just to report that using the prefix in the subj the libs are put in
> >> /opt/harbour/lib/harbour.
>
> I think it's perfect.
>
> >> I think that set correctly HB_INSTALL_PREFIX should be
hi,
so the above wasn't meant to be untested, but some glitch in the
autodetection mechanism made it go completely south at least here (i
haven't built a fresh-ish checkout for a while):
r12131 with the previous (i'd like to think at most harmless) change,
tinky:~/w/xhb/harbour$ env | fgrep
hi,
r12131, linux (x64), gcc 4.3:
Generating /tmp/hb/bin/hb-build...
Creating links...
Making libharbour-2.0.0.so...
/usr/bin/ld: ./libhbusrrdd.a/usrrdd.o: relocation R_X86_64_32S against `a local
symbol' can not be used when making a shared object; recompile with -fPIC
./libhbusrrdd.a/usrrdd.
On Sun, 16 Aug 2009, Viktor Szakáts wrote:
> It should. So does it also not work using latest SVN without local changes?
it does. sorry for the noise then.
--
[-]
mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.
ted GNU Make
> syntax), maybe this effect is caused by it being broken
> for now.
point is, why not -fPIC unconditionally?
>
> Brgds,
> Viktor
>
> On 2009.08.16., at 0:55, Tamas TEVESZ wrote:
>
> >
> > hi,
> >
> > r12131, linux (x64), gcc
On Sun, 16 Aug 2009, April White wrote:
> I've gleaned this list of OS from the source:
>
> BSD
> DARWIN
> DOS
> HPUX
> LINUX
i guess if one is to be really pedantic, for bsd, darwin and linux
it's more like "oses based on the bsd/darwin/linux kernel". not that
there would be too many v
On Wed, 26 Aug 2009, Bisz István wrote:
> The attachment contains the build results on CentOS 5.3. The build fails on
> Fedora 11 also. On Vista Ultimate works perfectly. Please review.
same failure on solaris (so probably on all unixes):
suncc -fast -xnolibmopt -xcode=pic32 -erroff=%none -o
On Wed, 26 Aug 2009, vszak...@users.sourceforge.net wrote:
> Revision: 12337
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12337&view=rev
> Author: vszakats
> Date: 2009-08-26 17:53:36 + (Wed, 26 Aug 2009)
>
> Log Message:
> ---
> 2009-0
On Wed, 26 Aug 2009, Tamas TEVESZ wrote:
> yup, this made it pass that.
>
> now (still on sunos) slang is somehow picked up (there's no slang on
> sunos, at least not anywhere harbour could pick up from without
> being explicitly told):
i should add that it seems it
On Wed, 26 Aug 2009, Tamas TEVESZ wrote:
> > now (still on sunos) slang is somehow picked up (there's no slang on
> > sunos, at least not anywhere harbour could pick up from without
> > being explicitly told):
>
> i should add that it seems it
hi,
#1
linux, sunpro:
! Building Harbour 2.0.0beta2 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_INSTALL_PREFIX: /tmp/hbcc
! HB_HOST_PLAT: linux HB_SHELL: sh
! HB_PLATFORM: linux (autodetected)
! HB_COMPILER: sunpro
! Component: 'openssl' found in /usr/includ
On Thu, 27 Aug 2009, Tamas TEVESZ wrote:
> this looks as if suncc, when facing c++ code, didn't automagically
> know to treat is as c++ (like gcc does, for the most part). using
> HB_BUILD_MODE=cpp (ie. sunCC instead of suncc), it builds.
>
> using gcc 4.3.3, it too b
On Thu, 27 Aug 2009, Viktor Szakáts wrote:
> > suncc -I. -I../../../../../include -fast -xnolibmopt -KPIC -erroff=%none
> > -I/usr/include/qt4 -I/usr/include/qt4/Qt -I/usr/include/qt4/QtCore
> > -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork
> > -I/usr/include/qt4/QtWebKit -o moc_sl
On Thu, 27 Aug 2009, Viktor Szakáts wrote:
> > > > 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).
> > >
On Thu, 27 Aug 2009, vszak...@users.sourceforge.net wrote:
> Revision: 12352
> 2009-08-27 18:20 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * config/linux/sunpro.mk
> + Setting CXX for linux/sunpro.mk to make it build .cpp files
> without forcing cpp mode explicitly. (suncc
On Thu, 27 Aug 2009, vszak...@users.sourceforge.net wrote:
> * config/sunos/libs.mk
> - Deleted commented /usr/X11R6/lib64 lib dir. It's a Linux
> distro specific thing.
almost there.
still centos 4.8, x64, having slang and ncurses (+devel stuff)
installed, but no gpm devel insta
hi,
linux (ubuntu 9.04: gcc 4.3.3, glibc 2.9), x64
linux (centos 4.8: gcc 3.4.6, glibc 2.3.4), x64
linux (debian etch: 4.3.2, glibc 2.7), x86
the same on all of them. works on solaris 10 Generic_141414-09, sun c
5.9, sparcv9, but then again solaris libc is probably more forgiving.
this exceprt
hi,
something's fishy with the rddsql install target. right now as far as
i can tell, it only manifests itself on sunos (where /bin/sh isn't
quite the brightest spark in town), and on the surface is
shell-related, but the cause looks to be lying deeper therein.
do find the relevant piece of t
On Tue, 1 Sep 2009, Przemyslaw Czerpak wrote:
hi,
> > it seems as if INSTALL_RULE was assembled more than once, once with
> > INSTALL_FILES set to libsddpg.a, but at the next iteration
> > INSTALL_FILES was empty. afaict this second iteration must somehow be
> > happening inside instsh.mk,
On Wed, 2 Sep 2009, Przemyslaw Czerpak wrote:
hi,
> Yet another:
> include $(TOP)$(ROOT)config/header.mk
> without any header files.
oh. i thought PRG_HEADERS := harupdf.ch was that.
anyway, testing...
> > this actually has been bugging me for a while - it seems that much
> > (a
hi,
tinky:~/w/xhb/harbour-build$ export HB_BUILD_DEBUG=yes
tinky:~/w/xhb/harbour-build$ make
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_BUILD_DEBUG: yes
! HB_HOST_PLAT: linux HB_SHELL: sh
! HB_PLATFORM: linux (autodetected)
! HB_C
hi,
this is a very uncharted territory for me, so sorry in advance if i'm
too off.
export HB_BUILD_DEBUG=yes
export HB_COMMERCE=yes
export HB_BUILD_OPTIM=no (also happens w/ optimized build)
export HB_CONTRIBLIBS=no
export WATCOM="/opt/ow"
export PATH="$WATCOM/binl:$PATH"
export INCLUDE="$
On Mon, 7 Sep 2009, Viktor Szakáts wrote:
hi,
> > wlib -q -p=64 -c -n ../../../../../lib/win/watcom/hbrtl.lib -+abs.obj
> > Error! Library too large. Recommend splitting the library into two or
> > trying a page_bound larger than 64.
> > make[3]: *** [hbrtl.lib] Error 8
> > make[2]: *** [d
hi,
solaris 10, sparc, g++ 4.0.2:
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_INSTALL_PREFIX: /home/ice/inst/sunos/gcc/cpp
! HB_BUILD_DEBUG: yes
! HB_BUILD_OPTIM: no
! HB_BUILD_MODE: cpp
! HB_CONTRIBLIBS: no
! HB_HOST_PLAT: sunos
On Mon, 7 Sep 2009, dru...@users.sourceforge.net wrote:
hi,
> 2009-09-07 22:29 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/source/vm/thread.c
> + added HB_MT() PRG function which exists only in MT HVM version and
> can be REQUESTed from .prg code to force link
hi,
sunos (solaris 10/sparc), sunpro 5.9 p124863-15, c++ mode, can't
pinpoint anything obvious, so here's the complete build log at
http://dawn.dev.hu/~ice/tmp/log_sunos_sunpro_cpp.gz
the failure itself is:
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: ma
On Tue, 8 Sep 2009, vszak...@users.sourceforge.net wrote:
hi,
> * utils/hbmk2/hbmk2.prg
> + Added sunpro compiler support. (not tested, bazaar style)
no time for more extensive tests (it just finished building, and i'm
about to fall asleep standing), but it does seem to be in perfect
On Wed, 9 Sep 2009, Przemyslaw Czerpak wrote:
hi,
> change it to:
>
>if( pHbSqlite3 && pHbSqlite3->db )
>{
> /* TODO: verify exact SQLITE3 version in
>* which sqlite3_extended_result_codes() was added
>*/
> #if SQLITE_VERSION_NUMBER > 3003006
> hb_ret
On Wed, 9 Sep 2009, Bisz István wrote:
hi,
> I just want to signal a building problem with 'CentOS 5.3' based on
> 'RedHat Enterprise Linux 5.3'. Just to clarify the stability of the
> distribution. The RHEL is upgraded from 5.3 to 5.4 just in the last
> weeks. Yes, the 'sqlite' is quite "
On Thu, 10 Sep 2009, vszak...@users.sourceforge.net wrote:
hi,
> Revision: 12458
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12458&view=rev
> Author: vszakats
> Date: 2009-09-10 00:53:58 + (Thu, 10 Sep 2009)
breaks all (well, all i have) watcoms.
On Thu, 10 Sep 2009, vszak...@users.sourceforge.net wrote:
hi,
> Revision: 12467
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12467&view=rev
> Author: vszakats
> Date: 2009-09-10 15:14:46 + (Thu, 10 Sep 2009)
all my tests (except the ones using wa
On Thu, 10 Sep 2009, Viktor Szakáts wrote:
> Okay, so hbpcre lib is missing. Could you look up relevant
> section in log file to see what was the reason it got
> skipped? Also hbzlib lib, maybe it's also missing.
for me its
! 'hbpcre' library skipped (not supported or disabled)
! 'hbzlib' lib
On Thu, 10 Sep 2009, Viktor Szakáts wrote:
here's some extra info which may mean something.
if i switch on to use the bundled zlib and pcre with
HB_WITH_ZLIB=yes
HB_WITH_PCRE=yes
HB_INC_PCRE=$( realpath harbour-build/external/pcre/ )
HB_INC_ZLIB=$( realpath harbour-build/external/zlib/ )
then e
On Fri, 11 Sep 2009, vszak...@users.sourceforge.net wrote:
hi,
> Revision: 12470
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12470&view=rev
> Author: vszakats
> Date: 2009-09-11 01:37:44 + (Fri, 11 Sep 2009)
with this, builds seem to be nicely ba
On Fri, 11 Sep 2009, Viktor Szakáts wrote:
no joy ;(
$hbmk2 t.prg -static
hbmk2: Processing configuration: /usr/bin/hbmk.cfg
Harbour 2.0.0beta3 (Rev. 12473)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 't.prg'...
Lines 6, Functions/Procedures
On Fri, 11 Sep 2009, Viktor Szakáts wrote:
> Okay, this was a different issue, pls recheck after 12474.
yup, this works, thanks.
> > $hbmk2 t.prg -static
> > hbmk2: Processing configuration: /usr/bin/hbmk.cfg
> > Harbour 2.0.0beta3 (Rev. 12473)
> > Copyright (c) 1999-2009, http://www.ha
On Fri, 11 Sep 2009, Bisz István wrote:
> The problem is solved with 'export HB_USER_CFLAGS=-fpic' magic as it is
> recommended in a document from Red Hat. I verified the new harbour.so with
> eu-findtextrel and the errors are gone.
> Any comment of this issue is useful, as I see. Maybe the '-
On Fri, 11 Sep 2009, Viktor Szakáts wrote:
> Recent changes in GNU Make system makes it possible to
> build with -fpic for Harbour dynamic lib and build without
> it for static libs/binaries in one build pass. [ of course
> the build will take more time to complete as most core libs
> will be
hi,
after viktor's recent watcom treat, things have gotten much better,
the build log for linux x os2 is attached (as it's big), the other,
native linux, is inlined here.
it's not entirely impossible i've gotten hb_build_extdef wrong, at
least not finding pthread.h would indicate that, but if
hi,
if i specify HB_PLATFORM=win, compiler is autodetected fine to be
mingw, and all is fine.
if, however, i explicitly specify HB_COMPILER=mingw (along with
HB_PLATFORM=win of course(?)), all hell breaks loose. it looks as if
compile commands were *mostly* set (ie. switches and stuff are alm
On Sun, 13 Sep 2009, Viktor Szakáts wrote:
hi,
> If you specify HB_COMPILER explicitly, there will be
> no autodetection done, so you also have to setup the other
> aspects of the compiler, like HB_CCPREFIX, HB_BUILD_EXTDEF.
>
> Of course it could be implemented otherwise, but it
> looks a
hi,
i had, this was fun.
it's barely over the "it just compiles" stage, there are a whole loads
of problems with terminal, possibly network, and whatnot.
anyway, if someone wants to chew this, it's a start. the downloadable
haiku r1alpha1 iso contains everything one needs to get started ;)
2
On Tue, 15 Sep 2009, Viktor Szakáts wrote:
hi,
> What do you think to rename HAIKU to BEOS inside Harbour?
as you see fit.
> It'd certainly sound more familiar for ppl, but I wonder
> if it would be accurate.
i absolutely have no idea. six hours ago i didn't even really know
haiku exists (
the following (and attached, too) makes it possible to just "make",
and get most of the stuff (compiled, at least). after this, my regular
build tests still build.
i also need some help. it seems that there's only a static library for
ncurses, and no matter how i bend things, it just won't get
hi,
linux x win, mingw/c,cpp watcom/cpp
i586-mingw32msvc-gcc -I. -I../../../../../include -Wall -W -g
-DHB_TR_LEVEL_DEBUG -ohbrun.o -c hbrun.c
i586-mingw32msvc-gcc -Wall -W -g -o
../../../../../bin/win/mingw/hbrun.exe hbrun.o
-L../../../../../lib/win/mingw -lhbextern -lhbdebug -lhbvm
On Tue, 15 Sep 2009, Viktor Szakáts wrote:
> BTW, here there is free OpenVMS terminal access provided:
> http://deathrow.vistech.net/
>
> Know zero about VMS, I couldn't do much, but it's useful.
vms crash course for unix users, most important lesson #1:
DO NOT EVER UNDER ANY CIRCUMSTANCES
hi,
Harbour 2.0.0beta3 (Rev. 12474)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'menutest.prg'...
menutest.prg(17) Error E0030 Syntax error "syntax error at '@'"
menutest.prg(18) Error E0030 Syntax error "syntax error at '@'"
menutest.prg(19) Error E0030 Syntax error "sy
On Wed, 16 Sep 2009, dru...@users.sourceforge.net wrote:
> * harbour/config/beos/libs.mk
> ! do not set explicitly GCC internal library paths.
> They are configured in GCC config and should not be overloaded
> in normal builds.
yes, right, thanks (and for the others too).
a
On Wed, 16 Sep 2009, vszak...@users.sourceforge.net wrote:
hi,
> 2009-09-16 09:47 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * utils/hbmk2/hbmk2.prg
> + Added support for beos targets to hbmk2. (untested)
almost there.
hbmk2 tries to link in libm, which doesn't exist on haiku.
t
On Wed, 16 Sep 2009, Viktor Szakáts wrote:
hi,
> > i also need some help. it seems that there's only a static library for
> > ncurses, and no matter how i bend things, it just won't get linked
> > into gtcrs (libncurses.a is ~400k, libgtcrs.a stays at ~65k, and
> > curses doesn't seem to work
hi,
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_BUILD_MODE: cpp
! HB_HOST_PLAT: beos (x86) HB_SHELL: sh
! HB_PLATFORM: beos (x86) (autodetected)
! HB_COMPILER: gcc (autodetected: /boot/develop/tools/gnupro/bin/)
! Component: 'zlib'
On Wed, 16 Sep 2009, Viktor Szakáts wrote:
hi,
> hbmk2 doesn't understand HB_BUILD_MODE envvar. You have to
it was just a shot in the dark :)
> use '-cpp' switch. In fact there are quite some GNU Make
this works, thanks. in this case, hbmk2 invokes g++, which is the
right thing to do.
> e
On Wed, 16 Sep 2009, Przemyslaw Czerpak wrote:
hi,
> I'm really sorry but I was wrong. I've just tested current SVN
> and default build time CC is preferred.
that is contrary to what i'm experiencing. i've built hb in cpp mode
(so it was using g++ as the compiler), and if i don't explicitly
On Wed, 16 Sep 2009, Viktor Szakáts wrote:
> > Current hbmk2 behavior is OK for me - thank you very much and I think
> > we should only add support to "inherit" C++ mode from Harbour build
> > settings.
>
> I'd resist here. Certainly not a good idea on non-*nix
> (additional question: shoul
On Thu, 17 Sep 2009, Przemyslaw Czerpak wrote:
hi,
> > yup, my test builds include cross from linux to os2, dos, win and also
> > native linux (btw, linux native and os2 cross are still broken :).
>
> With default setting yes.
i've been using the same settings for quite some time. builds u
On Thu, 17 Sep 2009, Lorenzo Fiorini wrote:
> In contrib/hbtip/sendmail.prg these lines:
>
> IF !( Right( cBody, 2 ) == hb_osNewLine() )
> cBody += hb_osNewLine()
> ENDIF
>
> should be:
>
> IF !( Right( cBody, 2 ) == Chr( 13 ) + Chr( 10 ) )
> cBody
On Thu, 17 Sep 2009, Viktor Szakáts wrote:
> > > i think (from a quick skim of the code) that the correct solution
> > > would be deleting these three altogether, and the smtp client seems to
> > > already add this in it's commit(), which should be enough (and along
> > > these lines, appendin
hi przemek,
netiosrv.c reads:
440 if( connsd != HB_NO_SOCKET )
441 {
442 BOOL fOK = FALSE;
443 BYTE msgbuf[ 64 ];
444
445 conn = s_consrvNew( connsd, lsd->rootPath );
446
447 if( s_srvRecvAll( conn, msgbuf, NETIO_MSGLEN ) == NETIO_MSGLEN &&
it f
hi,
the firtst hunk is apparently needed -- with that, netiotest actually
starts and runs and seems to be doing its stuff fine. note, i'm
deliberately not mentioning an exit of any sorts -- it doesn't,
instead it eats up all memory and hangs, but that's for another day,
when my eyes stopped b
On Fri, 18 Sep 2009, Jerry Finuliar wrote:
> > Such functionality will be available in final version of alternative
> > IO APIs. It will be possible to redirect any operations but now only
> > functionality used by core RDD code is supported.
>
>
> Ok I'll wait for it. One more question Ar
On Fri, 18 Sep 2009, Viktor Szakáts wrote:
hi,
> We have an option to set HB_GT_LIB to 'os2pm'.
>
> I'd like to ask OS/2 users what is the use of this,
> and do we still need it?
(entirely uneducated guess)
"pm" stands for "presentation manager", which is the os/2 gui. i
suspect this must
On Fri, 18 Sep 2009, Przemyslaw Czerpak wrote:
hi,
> > Index: source/rtl/hbsocket.c
> > ===
> > --- source/rtl/hbsocket.c (revision 12533)
> > +++ source/rtl/hbsocket.c (working copy)
> > @@ -58,6 +58,10 @@
> > # endif
> >
On Fri, 18 Sep 2009, Tamas TEVESZ wrote:
> the firtst hunk is apparently needed -- with that, netiotest actually
> starts and runs and seems to be doing its stuff fine. note, i'm
> deliberately not mentioning an exit of any sorts -- it doesn't,
> instead it eats u
On Fri, 18 Sep 2009, Przemyslaw Czerpak wrote:
> I downloaded ISO CD and installed HAIKU in VirtualBOX and it works
w.o.w.
i've been (and probably will stay :) a vmware guy (i like the
interface better...), but i must say, haiku runs about a gazillion
trillion plus one time better in vb than
On Sat, 19 Sep 2009, Guy Roussin wrote:
> $ LANG=C fakeroot sh mpkg_deb.sh
fakeroot debian/rules binary
--
[-]
mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
(doesn't hurt other finds)
Index: bin/postinst.sh
===
--- bin/postinst.sh (revision 12576)
+++ bin/postinst.sh (working copy)
@@ -46,7 +46,7 @@
fi
if [ "$HB_PLATFORM" != "hpux" ]; then
# Keep the size of the libraries t
hi,
now with libharbour*.so installed in /boot/common/lib/harbour/, things
don't find it.
--
[-]
mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
hi,
this is something new:
HB_BUILD_DEBUG=yes
WATCOM=/opt/ow
HB_CONTRIBLIBS=no
HB_BUILD_EXTDEF=no
HB_COMMERCE=yes
HB_INSTALL_PREFIX=/home/ice/w/xhb/hbci/inst/dos/watcom/cpp
HB_COMPILER=watcom
HB_BUILD_MODE=cpp
HB_BUILD_OPTIM=no
HB_PLATFORM=dos
INCLUDE=/opt/ow/h
===
! Building Harbour 2.0.0beta3
On Wed, 28 Oct 2009, Viktor Szakáts wrote:
> hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
>
> doesn't seem to respect app CP (like now f.e. GTWVT does)
> with GTXWC, accented chars don't appear correctly in title
> bar.
>
> I tried to fix it by converting to UTF8 in gtxwc.c,
On Wed, 28 Oct 2009, Przemysław Czerpak wrote:
> > > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
> > > doesn't seem to respect app CP (like now f.e. GTWVT does)
> > > with GTXWC, accented chars don't appear correctly in title
> > > bar.
> > > I tried to fix it by convertin
On Thu, 29 Oct 2009, Viktor Szakáts wrote:
> BTW, does someone know if it's possible to run dosemu under
> amd64 Ubuntu?
>
> I'm tempted to move to 64-bit, but I'd cut myself out of
> DOS even more if it breaks dosemu.
why not virtualbox? i'm quite sure even the opensource edition can
run
On Tue, 3 Nov 2009, dru...@users.sourceforge.net wrote:
> Revision: 12818
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12818&view=rev
> Author: druzus
> Date: 2009-11-03 12:37:01 + (Tue, 03 Nov 2009)
>
> Log Message:
> ---
> 2009-11-03
On Tue, 3 Nov 2009, Przemysław Czerpak wrote:
hi,
> > suncc is (still?) broken:
> > "/usr/include/stdio.h", line 480: Error: "(" expected instead of
> > "__attribute__".
>
> yes, but it is sunCC problem not Harbour one.
ah, ok.
--
[-]
mkdir /nonexistent
___
On Fri, 20 Nov 2009, Bisz István wrote:
> ../../../dlmalloc.c: In function 'void* dlmalloc(size_t)':
> ../../../dlmalloc.c:4107: warning: dereferencing pointer 'b' does break
> strict-aliasing rules
there is an updated dlmalloc available from
ftp://gee.cs.oswego.edu/pub/misc/ (2.8.4 as oppo
viktor,
i believe the following is better at identifying the actual llvm
frontend used:
tinky:~/w/xhb/hbci/harbour-build$ ../inst/linux/llvm/c/bin/harbour -build 2>&1
| fgrep Compiler
Compiler: LLVM/GNU C 4.2.1 (64-bit)
tinky:~/w/xhb/hbci/harbour-build$ ../inst/linux/llvm/cpp/bin/harbour -buil
On Sun, 22 Nov 2009, Viktor Szakáts wrote:
hi,
> I'll commit something pretty soon, pls
> take a look at it.
it gives the expected results with llvm/g{cc,++}, thanks.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB
On Sun, 22 Nov 2009, vszak...@users.sourceforge.net wrote:
> + Added support for linux/clang. (untested)
> (what package has to be installed? I installed llvm yesterday,
> but couldn't find clang on Ubuntu)
it's not there afaict. what is there is llvm-gcc-4.2, but the package
On Sun, 22 Nov 2009, Viktor Szakáts wrote:
> > could you also add this (llvm-gcc) target to the mix? for all intents
> > and purposes, it is the very same as the gcc target, except compilers
> > being llvm-gcc and llvm-g++ instead of gcc and g++, respectively.
>
> Can you try if it works b
On Sun, 22 Nov 2009, Przemysław Czerpak wrote:
hi,
> > HB_COMPILER=gcc
> > HB_BUILD_OPTIM=no
>
> Why do you disable optimization?
i don't know, i forgot already. the original intent was probably that
probably noone else builds with optimizations disabled, so at least my
tests should have
> separate llvmgcc target, which, for starters, only sets HB_CMP.
i'm fighting with the attached llvmgcc target definition, but i got
stuck, and can't ffigure out where do cflags leak into ldflags. just
try building it, you'll see.
cluebat, please?
--
[-]
mkdir /nonexistent#
# $Id: gcc.mk
On Mon, 23 Nov 2009, Viktor Szakáts wrote:
> > i'm fighting with the attached llvmgcc target definition, but i got
> > stuck, and can't ffigure out where do cflags leak into ldflags. just
> > try building it, you'll see.
> > cluebat, please?
>
> For some reason CPPFLAGS is passed to linke
On Mon, 23 Nov 2009, Przemysław Czerpak wrote:
> > that is exactly what's happening, and according to llvm bugzilla, this
> > is what should be happening, see:
> > http://www.mail-archive.com/llvmb...@cs.uiuc.edu/msg03238.html
>
> Please note that we are calling llvm-gcc to link final appli
On Mon, 23 Nov 2009, Przemysław Czerpak wrote:
> > they work together correctly, if they are configured to work together
> > correctly. my first stab, they were not. i'm much further now, and
> > almost have a complete compilation+link cycle without workarounds like
> > above (as i slowly s
On Thu, 26 Nov 2009, Przemysław Czerpak wrote:
hi,
> I've just committed it:
>
> 2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
a typo seems to have snuck in.
Index: src/vm/hvm.c
===
--- src/vm/hvm.c
On Mon, 30 Nov 2009, Davor Siklic wrote:
> s...@siki:~/clipp/harbour/contrib/hbide$ hbmk2 hbide
hbmk2 hbide.hbp
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-projec
On Tue, 1 Dec 2009, vszak...@users.sourceforge.net wrote:
> Log Message:
> ---
> 2009-12-01 12:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
> * config/global.mk
> % "De-xmastree"-d two more if/else structures.
you SO are my hero.
--
[-]
mkdir /nonexistent
__
On Sat, 5 Dec 2009, Viktor Szakáts wrote:
> continues about the mingw project. First they use .lzma
> extension instead of well-known .7z. Fine. Then they insist
they are by far not the same. .lzma to .7z is what .gz is to .zip,
> on using .tar inside the .7z file, which is a solid archive
hi,
contrib/hbtpathy/tpunix.c:
270 HB_FUNC( __TP_CTRLCTS )
271 {
272 #if !defined( CRTSCTS ) && defined( __WATCOMC__ )
273 # define CRTSCTS 0200
274 #endif
is there a reason for the "&& defined( __WATCOMC__ )" part? i've just
found another platform where CRTSCTS isn't defined, and am
On Sat, 5 Dec 2009, Viktor Szakáts wrote:
> > hence the need for a container, which they chose to be tar (probably
> > because 7z can't, or they thought it can't store attributes they
> > needed) (it probably can).
>
> It's still an insane idea. Even .tar.gz is insane on Windows.
i have n
On Sat, 5 Dec 2009, Viktor Szakáts wrote:
> > 270 HB_FUNC( __TP_CTRLCTS )
> > 271 {
> > 272 #if !defined( CRTSCTS ) && defined( __WATCOMC__ )
> > 273 # define CRTSCTS 0200
> > 274 #endif
> >
> > is there a reason for the "&& defined( __WATCOMC__ )" part? i've just
> > found anot
On Sun, 6 Dec 2009, Viktor Szakáts wrote:
> I'm leaving this to you as it obviously has no point for
> me to update it while I don't understand a single bit about it.
>
> I can restore original state but that won't help on the
> original problem.
here's the deal in condensed form: CRTSCTS
hi,
i've been toying with a platform where (due to compiler, erhm, issues)
my best bet for startup seems to be hb_strict_ansi_c, however it
doesn't seen to work. i've checked setting this on linux/gcc, and it
doesn't work either.
even compilation doesn't succeed by throwing lots of multiply d
1 - 100 of 176 matches
Mail list logo
