On Mon, 7 Dec 2009, vszak...@users.sourceforge.net wrote:
hi,
[libpng]
> * Updated to 1.2.41 (from 1.2.40)
broke linux x win/watcom cpp
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! MAKE: make 3.81 /bin/sh
! HB_INSTALL_PREFIX: /home/ice/w/xhb/hbci/inst/win
On Mon, 7 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
> Revision: 13154
> * harbour/src/rdd/dbfcdx/dbfcdx1.c
> * modified to use unique names for startup functions
yup, much better now, all artifacts seem to have disappeared, thanks!
--
[-]
mkdir /nonexistent
On Wed, 9 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
> Revision: 13174
something is not quite right. i have added c builds to my test suite
(they are all cross-builds on a linux host), and they do not build:
! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org
! M
On Wed, 9 Dec 2009, Tamas TEVESZ wrote:
> ! HB_USER_CFLAGS: -DHB_STATIC_STARTUP
i am so shutting up right about now.
i forgot this in from a previous experiment ;(
sorry for the noise.
--
[-]
mkdir /nonexistent
___
Harbour mailing l
hi,
these two are quite synonymous (so maybe extending the patch to
include the reverse case could be useful later on as well).
Index: src/rtl/hbsocket.c
===
--- src/rtl/hbsocket.c (revision 13223)
+++ src/rtl/hbsocket.c (working
enrico,
"latest svn" is not helpful now, and certainly isn't going to be
helpful when later on if/when one will try to use archived mails.
you have the EXACT revision number right in front of you.
use it.
--
[-]
mkdir /nonexistent
___
Harbour mail
hi,
i have hit a case where the libharbour.so linking phase generates a
command line of about 33k, while this system's limit is about 10k.
i reckon this is the first unix we've hit this on, accordingly i can't
really find anything to follow.
i think that on other limited systems the linker ca
On Sat, 12 Dec 2009, Viktor Szakáts wrote:
> You can have a peek into config/win/mingw.mk,
> where there is example for that.
lovely!
cheers,
>
> Brgds,
> Viktor
>
> On 2009 Dec 12, at 15:49, Tamas TEVESZ wrote:
>
> >
> > hi,
> >
>
hi,
could i please have the implicit short intness of iverpatch (
hb_snprintf( pszCompiler, COMPILER_BUF_SIZE, "%s%s %hd.%hd.%hd", pszName,
szSub, iVerMajor, iVerMinor, iVerPatch );
) lifted, and szSub extended by a few octets?
i'm massaging a compiler that encodes MM in the patch level, an
(subject should have read iVerPatch of course)
> could i please have the implicit short intness of iverpatch (
> hb_snprintf( pszCompiler, COMPILER_BUF_SIZE, "%s%s %hd.%hd.%hd", pszName,
> szSub, iVerMajor, iVerMinor, iVerPatch );
> ) lifted, and szSub extended by a few octets?
>
> i'm ma
hi,
would someone with gcc2 handy get me the output of
gcc -dM -E -xc /dev/null
please? (whatever /dev/null is on your platform; running it on an
empty file is good, too.)
please indicate what platform you are on.
i am not at the moment interested in any other gcc version, only v2.
thanks,
On Tue, 15 Dec 2009, Viktor Szakáts wrote:
hi,
> Try exchanging line 56 with line 58 in contrib/hbqt/detect.mk
> and report results.
>
> Even if this works I'd appreciate if someone could give
> ideas how to make moc tool detection reliable on the long
> run, while keeping it simple. Di
On Tue, 15 Dec 2009, Viktor Szakáts wrote:
hi,
> > the logic is that (since one can have qt3 and qt4 dev installed
> > simultaneously), one gets to decide which one does one want "by
> > default". you trying to work around users picking the wrong one (or
> > not picking the right one) is a
hi,
got this:
g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W -O3 -o
expropt1.o -c ../../../expropt1.c
In file included from ../../../../../include/hbvmpub.h:56,
from ../../../../../include/hbapi.h:61,
from ../../../../../include/hbcomp
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
> * harbour/include/hbinit.h
> + added new alternative form for initialization code activated
> by HB_INITSEG_STARTUP macro. This method uses asm() directive
> to store call to startup function in .init segment.
y
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
> * explicitly restore .text segment for compilers which do not make
commit typo, it says .init at the end too :)
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi
> Revision: 13253
now something is broken again. i'm not sure what, as at one point i
had a working harbour ("working" at this stage i define as "hbrun
starts"), now for all of gcc/c, native/c, native/c++, when trying to
run hbrun,
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
> Revision: 13255
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13255&view=rev
> Author: druzus
> Date: 2009-12-15 23:24:29 + (Tue, 15 Dec 2009)
>
> Log Message:
> ---
> 2009-
On Wed, 16 Dec 2009, Tamas TEVESZ wrote:
hi,
> that didn't really help, and it's getting even more strange.
[...]
nevermind. all of a sudden it started working. if i did this, i have
no idea, what did i do. i'm going to stick a screwdriver through this
thing and go become
'm still trying
to hunt that down, before inevitably failing and crying for help:)...
> (correction is easy after that point)
in fact the build procedure still runs -n1, and now all is fine.
>
> Brgds,
> Viktor
>
> On 2009 Dec 16, at 01:37, Tamas TEVESZ wrote:
&g
hi,
it seems that something is wrong with g++2.95 builds afterall.
i took a fresh checkout of 13263, and tried building it on an older
linux/i386 box that has gcc 2.95.
(i changed HB_CMP to gcc-2.05 and g++-2.95 in config/linux/gcc.mk
because this has no gcc and g++ links, but that's all that
On Wed, 16 Dec 2009, Przemysław Czerpak wrote:
hi,
> The problem is trivial. GCC-2.96 when C++ mode is used ignores
> __attribute__ ((constructor)) and does not add functions with
> above attribute to .ctors segment. Looks like it was fixed in
> one of GCC-3.3x releases but I do not know the
On Wed, 16 Dec 2009, Viktor Szakáts wrote:
hi,
> No educated bug report, but just now I tried to
> coppy/paste some text from OS X Mail to my app
> running GTXWC, and the app just hung with 100%
> CPU consumption.
i notice i cannot paste (nor copy) to/from xwc at all ;)
anyway, if seems
On Wed, 16 Dec 2009, Tamas TEVESZ wrote:
hi,
> i have a hunch that i am verifying now (only 3.3 g++ is done so far,
> this is a slow machine, but so far the only result i have is
> promising): change the order of initializers.
fyi that fixed g++ 2.95 as well as 3.3.6, wi
On Wed, 16 Dec 2009, Viktor Szakáts wrote:
> >> No educated bug report, but just now I tried to
> >> coppy/paste some text from OS X Mail to my app
> >> running GTXWC, and the app just hung with 100%
> >> CPU consumption.
this is a long shot, but.
is this even supposed to work? i do not k
hi,
while doing a new port, came across this:
g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W
-O3 -o expropt1.o -c ../../../expropt1.c
../../../expropt1.c: In function `struct HB_EXPR_ *
hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)':
../../../expropt1.c:1066: integ
On Thu, 17 Dec 2009, Przemysław Czerpak wrote:
hi,
> > I've just checked and same OS X GTXWC app picked what was
> > placed to clipboard before starting the app (or even
> > starting X11 for that matter).
> > I'll keep an open eye to report any clipboard problems
> > here.
>
> Please t
On Thu, 17 Dec 2009, Przemysław Czerpak wrote:
hi,
> > g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W
> > -O3 -o expropt1.o -c ../../../expropt1.c
> > ../../../expropt1.c: In function `struct HB_EXPR_ *
> > hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)':
> > ..
On Thu, 17 Dec 2009, Przemysław Czerpak wrote:
hi,
> > the symptom is that when there is already data in the primary when
> > this app is started, the first inkey(0) is immediately satisfied (and
> > then it shows the correct content for the primary selection).
> >
> > this doesn't happen
On Fri, 18 Dec 2009, Przemysław Czerpak wrote:
hi,
> Can you check if problem can be resolved if you add at the end of your
> test application:
>
>hb_gtInfo( HB_GTI_CLIPBOARDDATA, "" )
no, but i managed to strace the xterm that got picked by the Client
Killer Phenomenon.
it's last bre
On Fri, 18 Dec 2009, Przemysław Czerpak wrote:
hi,
> I cannot replicate it (probably because I cannot exactly replicate your
> environment settings) so I have to guess but probably you are right.
> Anyhow thank you very much for your tests. Finally I've found a while
> to clean the selection
hi,
../../../../../bin/linux/gcc/harbour ../../../xbpwindow.prg
-I../../../../../contrib/hbqt -i../../../../../include -n1 -q0 -w3
-es2 -kmo -i- -l
../../../xbpwindow.prg(785) Warning W0032
Variable 'LSUCCESS' is assigned but not used in function
'XBPWINDOW_DESTROY(0)'
../../../xbpwind
On Sat, 19 Dec 2009, Viktor Szakáts wrote:
hi,
> I'd like to ask everyone if there are any
> patches, commits or fixes pending? (besides
> hbqt related modules)
this should worth a yes/no/after release:
Message-ID:
or alternatively
http://old.nabble.com/g%2B%2B2.95-g%2B%2B3.3-bad-build-
On Sat, 19 Dec 2009, Viktor Szakáts wrote:
> > considering that currently all g++ > answer should be a "yes", though :) (gcc 2.95 is omnipresent on
> > less-than-mainstream-but-still-important platforms, so compatibility
> > with that should be a quite high priority.)
>
> Probably yes, es
On Mon, 21 Dec 2009, Viktor Szakáts wrote:
hi,
> start making test builds on various platforms, so
my batch looks fine (linux host to dos/watcom, os2/watcom, win/watcom,
win/mingw, linux/watcom, linux/gcc, linux/sunpro, linux/gcc, both c
and cpp; linux/sunpro/cpp is unknown (because of recen
hi,
preparing a platform that has no S_IFSOCK/S_ISSOCK, i protected the
hb alikes like this:
include/hbapifs.h:
#if defined( S_ISSOCK )
# define HB_FA_SOCKET HB_FA_SPARSE /* S_ISSOCK() */
#endif
src/common/hbffind.c:
#if defined( S_ISSOCK )
if( S_ISSOCK( raw_attr ) ) ulAttr
On Tue, 22 Dec 2009, Viktor Szakáts wrote:
> I'm glad to announce that after a very heavy 16 months
> of development, the final, stable version 2.0.0 is finally
> released.
incredible job!
a toast a cheers to all those involved!
--
[-]
mkdir /nonexistent
_
hi,
the attached unifies all "int TODO"s to "int iTODO"s, for your
grepping pleasure.
--
[-]
mkdir /nonexistentIndex: src/vm/thread.c
===
--- src/vm/thread.c (revision 13370)
+++ src/vm/thread.c (working copy)
@@ -786,7 +786,7 @@
hi,
on platforms where available, what is the significance of including
ieeefp.h, given that even without it, things seem to be doing OK?
thanks,
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-proje
On Wed, 23 Dec 2009, Przemysław Czerpak wrote:
hi,
> > on platforms where available, what is the significance of including
> > ieeefp.h, given that even without it, things seem to be doing OK?
>
> Probably nothing though sometimes is good to check the details in
> platform documentation. I
On Wed, 23 Dec 2009, Przemysław Czerpak wrote:
hi,
sorry to be so blunt, but the more i read, the less i understand ;)
> isinf() and isfinite() are C99 extensions so they are not available if
> C99 features are not enabled.
> There is problem with non GCC unix builds - they do not use HB_MATH
hi,
the attached and below inlined does the following:
- hunk #1 prepares for when IPV6_ADD_MEMBERSHIP is defined by the
system; it is very synonymous with IPV6_JOIN_GROUP.
- hunk #2 makes initseg startup work with coff executables. (ok,
despite the heritage, i really don't know whether th
On Thu, 31 Dec 2009, Massimo Belgrano wrote:
> What about evolve harbour name HarbourPro
> pro Is for a "pro"fessiona product
it is already there.
on top of that, "ject" has been added for **EVEN MORE** professionalism.
--
[-]
mkdir /nonexistent
On Sat, 2 Jan 2010, francesco perillo wrote:
> Another option would be to have the packages split: the first one,
> monolithic, is the "base" package, the "mandatory" one. All the
> optional packages have the "base" package as pre-requisite and each
> one has its own "client" pre-requistite...
On Sat, 2 Jan 2010, vszak...@users.sourceforge.net wrote:
hi,
> * config/global.mk
> + Added rudamentary package manager detection (so far for
> darwin and linux). Please extend. This will allow to make
> proper dependency checking in detect.mk.
the deb heuristics are quit
On Sat, 2 Jan 2010, vszak...@users.sourceforge.net wrote:
> * config/global.mk
> ! Fixed debian package manager detection, as suggest by
> Tamas Tevesz.
you nicely beat me to it while i was preoccupied ;)
the floowing (also attached) could also be applied for uniformit
hi,
viktor, is there any compelling reason against this one? it removes a
level of if-nests, and inlines an expression used only once. positive
and negative tests look ok here.
Index: config/global.mk
===
--- config/global.mk(
On Sat, 2 Jan 2010, Viktor Szakáts wrote:
hi,
> No, it looks fine. It can even be a little bit further optimized,
> I'll commit it ASAP, pls test it.
works nicely.
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
H
one more related cleanup piece
Index: config/dir.mk
===
--- config/dir.mk (revision 13444)
+++ config/dir.mk (working copy)
@@ -10,11 +10,6 @@
ifeq ($(HB_HOST_PLAT),dos)
# do not use rules for parallel processing in
On Sun, 3 Jan 2010, francesco perillo wrote:
> harbour-static contains the .a libraries
doesn't suse name these kinds of packages -devel, like any
rpm system with good manners does?
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment siz
On Sun, 3 Jan 2010, francesco perillo wrote:
> On Sun, Jan 3, 2010 at 11:20 AM, Tamas TEVESZ wrote:
> > On Sun, 3 Jan 2010, francesco perillo wrote:
> >
> > > harbour-static contains the .a libraries
> >
> > doesn't suse name these kinds of packa
On Sun, 3 Jan 2010, francesco perillo wrote:
francesco,
honestly this is not intended as an offence, far be from it, but there
are established standards and policies for packaging, which you are
not to reinvent, override or outsmart, but to follow.
opensuse has some nice documentation on packa
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
most things below are just scratching the problem-surface, and
definitely need more eyes.
> I have a pending commit, which merges core + lib + static
> rpms into one. Is this okay?
definitely not.
i think that the proper splitting is something very
On Sun, 3 Jan 2010, vszak...@users.sourceforge.net wrote:
> * harbour.spec
> + Merged lib and static subpackages into main one.
oh, i see you did that while i was away typing.
anyway, there's no point in reverting that; currently (by virtue of
rpm/deb being used as a convenience contain
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
> > /usr should be used only by packages since they know how to clean and
> > how to manage conflicts.
> >
> > make install MUST go elsewhere like /usr/local or /opt/
> >
> > Please let's leave to Linux REAL developers rpm and deb packaging issues.
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
> > harbour-utils - hbrun, maybe hbtest
> > libharbour$shlib_version - libharbour{mt,}.so.x.y.z
> > libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to &.x.y.z)
> > harbour - harbour, hbmk2, *.ch, other stuff that are directly used
> > when
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
> >> Then what is the point of having hbrun without dynamic
> >> libs, when hbrun is built as shared binary in certain
> >> situations, so it cannot work without Harbour dynamic
> >> lib also.
> >
> > i might be misunderstanding something, but th
On Fri, 8 Jan 2010, Viktor Szakáts wrote:
hi,
> What build settings are needed to build an x86 (i?86)
> Harbour build on an amd64 host?
HB_USER_CFLAGS=-m32 is a good start (assuming gcc or sunpro), but
component autodetection will almost certainly be unusable (it'll pick
up stuff for which
On Fri, 8 Jan 2010, Viktor Szakáts wrote:
hi,
> >> What build settings are needed to build an x86 (i?86)
> >> Harbour build on an amd64 host?
> >
> > HB_USER_CFLAGS=-m32 is a good start (assuming gcc or sunpro), but
> > component autodetection will almost certainly be unusable (it'll pick
On Sat, 9 Jan 2010, Viktor Szakáts wrote:
> >>> HB_USER_CFLAGS=-m32 is a good start (assuming gcc or sunpro), but
> >>> component autodetection will almost certainly be unusable (it'll pick
> >>> up stuff for which no 32-bit libs are present).
>
> Now that I'm testing it live, it seems I a
On Sat, 9 Jan 2010, Viktor Szakáts wrote:
> I'm not sure if it's missing package or something missing from our .mk
> files. [TOFIX?]
> As far as I can tell, a libX11.so lib _was_ installed in 32-bit lib dir.
> This can be solved using this ugly hack: [update#1]
> $ cd /usr/lib
>
hi,
i am quite hopelessly behind reading the list, but at a quick skim
these have not surfaced yet.
linux x dos/watcom c
linux x os2/watcom c++
linux x win/mingw c
linux x win/mingw c++
linux x win/watcom c
linux x win/watcom c++
these builds are broken atm.
os2/watcom c++ is:
/usr/bin/harbo
hi,
as $subject says. i have bisected the problem to have been introduced
in r12466 (r12465 is fine).
r12466 only says segmentation fault, leaving an empty hb_out.log;
r14542 is a bit more verbose with:
Application Internal Error -
/home/ice/w/xhb/hbci/harbour-bisect/harbour/inst/linux/sunp
On Thu, 20 May 2010, Przemysław Czerpak wrote:
hi,
> Linux SUNPRO port has very serious bug. It does not correctly generate
> code for all constructors. We are exploiting this problem from time to
> time. It probably depends on total binary size which may interact with
> the contents of some
hi,
the following adds dragonfly support to the bsd support chunk.
some notes:
--- config/bsd/libs.mk (revision 14580)
+++ config/bsd/libs.mk (working copy)
- SYSLIBS += slang
+ ifneq ($(wildcard /usr/pkg/lib/libslang2.so),)
+ SYSLIBS += slang2
+ else
+ SYSLIBS
On Tue, 25 May 2010, Viktor Szakáts wrote:
hi,
> I've committed, along with hbmk2 patch, so in theory
> the last issue with HB_USER_LDFLAGS should be fixed.
> (since the /pkg dir is already hardcoded when checking
> for slang2, I think it's just fine to also add it to
> lib list in hbmk2)
On Tue, 25 May 2010, Tamas TEVESZ wrote:
hi,
> let me make a small amendment:
and one more. apparently clang (pkgsrc wip/clang at least) works too.
config/bsd/clang.mk is a straight copy of config/linux/clang.mk so
i'll spare inlining it. some hbmk2-voodoo is needed in addition to
On Tue, 25 May 2010, vszak...@users.sourceforge.net wrote:
> 2010-05-25 23:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> + config/bsd/clang.mk
> + Base implementation of bsd/clang target.
> Based on patch by Tamas Tevesz with modifications:
> - dele
yOn Wed, 26 May 2010, Tamas TEVESZ wrote:
> this seems to have fixed this remaining issue here, and hbmk2 is quite
> happily churning out clang-compiled binaries.
yuh, works nicely on freebsd8R-ish with devel/llvm-devel.
netbsd decided to show virtualbox the finger, so that's
i think this takes care of sunpros >=0x5100 (studio 12).
have no earlier ones readily installed, but they should stay ok.
Index: src/common/hbver.c
===
--- src/common/hbver.c (revision 14628)
+++ src/common/hbver.c (working copy)
- clang 2 does c++ now, so only fall back to c mode if we are running
clang1
- clang2 has some nice macros for version stuff, use them
tested with both clang2 (bsd) and clang1 (linux), both appear to be
fine.
thanks to viktor for solving my troubles with the
$($(shell(($($((subst))$)zoink))$
On Sun, 30 May 2010, Viktor Szakáts wrote:
hi,
> Thanks for the patch. We already had "LLVM/Clang C"
> detection inside the __GNUC__ branch, is it still
> necessary, or can we now safely delete it?
the current one is for clang1 (no clang_major and friends, but
defines gnuc and llvm), whil
On Sun, 30 May 2010, vszak...@users.sourceforge.net wrote:
> + Clearing forced C++ mode if clang 1.x is detected.
> (Patch from Tamas Tevesz. Slight fix added by me to
> set HB_CMP when falling back to C mode. I didn't make
> tests though.)
>
> maybe it could be turned around a bit so that all the llvm/clang
> things are moved out of the gnuc block, but at the same time it fits
> the way mingw/rsx*/etc are handled now.
>
> i'd say leave it like this, and maybe do some shuffling several clang
> and/or llvm versions in the futu
hi,
przemek, i'm having a build failure with sunpro/linux. i've went quite
outside my comfort zone by installing centos 5.5 (centos 5 is
explicitly supported by studio 12u1) i386 (just in case, the "no
surprises" fallback). c mode builds but doesn't work (we've been there
already), but now cp
plus add some, those that are also in src/rtl/hbcom.c
Index: contrib/hbtpathy/tpunix.c
===
--- contrib/hbtpathy/tpunix.c (revision 14656)
+++ contrib/hbtpathy/tpunix.c (working copy)
@@ -114,9 +114,27 @@
case 9600:baud
101 - 176 of 176 matches
Mail list logo
