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
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
> 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
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.)
>
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
- 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))$
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)
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
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
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, 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)
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 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,
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
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
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
>
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 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 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 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 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:
> > /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, 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:
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, 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, 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:
> 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
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 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
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, 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
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, 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 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
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 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
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
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
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 @@
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,
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 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
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 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-
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 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
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 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 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,
> > 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
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 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
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:
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, 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
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
'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
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
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 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:
> * 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,
> * 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
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, 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
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
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,
(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,
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
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,
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
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,
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
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
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 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 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
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
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
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 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
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:
> 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
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 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 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, 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 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, 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
> 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 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
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, 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:
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
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 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
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 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 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 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 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,
1 - 100 of 176 matches
Mail list logo
