>> Me - still in the "hunch" mode - am still finding it odd that
>> we need to use MT HVM to make QT not GPF. I perfectly believe
>> your tests are correct and for you MT solved the problems, but
>> we still don't see the deeper reason.
>>
>> For sure QT itself cannot require MT _HVM_, because i
>> IMO, it should not require it, but may give extra features
>> if available, and for sure _be compatible with it_. If current
>> implementation _requires it_, which means it cannot work or
>> cannot reliably work without it, we should document this fact.
>>
>
> HBQT may/may not _require it_
Hi
Viktor Szakáts wrote:
>
> Me - still in the "hunch" mode - am still finding it odd that
> we need to use MT HVM to make QT not GPF. I perfectly believe
> your tests are correct and for you MT solved the problems, but
> we still don't see the deeper reason.
>
> For sure QT itself cannot re
Hi Istvan
Bisz István wrote:
>
> Here I can share just my experiences with the harbour Qt implementation
> testing. I spent a lot of time to clarify the build problems with 4.6 and
> after the successful building the resulted executable testing. My first
> conclusion was that C++ mode force to
Hello
Viktor Szakáts wrote:
>
> "Exploits it" and "cannot imagine" doesn't mean it _requires_ it.
>
> What I'm interested in, is whether HBQT _requires it_?
>
> IMO, it should not require it, but may give extra features
> if available, and for sure _be compatible with it_. If current
> impl
rbour] SF.net SVN: harbour-project:[13103] trunk/harbour
Hi Istvan,
> Hi Viktor,
>
> Just to clarify the picture or to restrict the playing space, why these
> issues is are missing in linux (Fedora 12) builds?
Interesting question, I hope someone will give an answer.
For sure
Hi Istvan,
> Hi Viktor,
>
> Just to clarify the picture or to restrict the playing space, why these
> issues is are missing in linux (Fedora 12) builds?
Interesting question, I hope someone will give an answer.
For sure MT isn't used by default on Fedora either, and also
base Harbour isn't bui
Szakáts
Sent: 2009. december 7. 13:46
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
Hi Istvan,
>> This is very easy to implement, only needs one extra 'mt=yes' line
>> in contrib/hbqt/hbqt[s].hbc files.
>
> If you need to build harbour with TDM-MINGW with dual rewind feature
> installed and Qt previous to 4.6 release, you should set HB_COMPILER to
> mingw, skipping in this way the build system auto detection:
>
> set HB_WITH_QT=C:/Qt/4.5.3/include
> set HB_COMPILER=mingw
>
> for 4.6 just:
>
> se
Hi Istvan,
>> This is very easy to implement, only needs one extra 'mt=yes' line
>> in contrib/hbqt/hbqt[s].hbc files.
>
>> However, before we do this, I'd like know if this is indeed the
>> _real_ solution to the problem. Turning on MT mode decreases performance
>> by ~30% (AFAIR) in mingw, s
I am resending, as the previous is lost...
From: Bisz István [mailto:istvan.b...@t-online.hu]
Sent: 2009. december 7. 11:02
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
Hi Massimo,
> C:/HARBOUR/lib/win/mi
: Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
What can i have miss?
hbmk2 hbide.hbp
C:/HARBOUR/lib/win/mingw/libhbqt.a(hbqt_slots.o):hbqt_slots.cpp:(.tex
undefined reference to `_imp___ZN9QListData7detach3Ev'
C:/HARBOUR/lib/win/mingw/libhbqt.a(hbqt_sl
Hi Viktor,
> This is very easy to implement, only needs one extra 'mt=yes' line
> in contrib/hbqt/hbqt[s].hbc files.
> However, before we do this, I'd like know if this is indeed the
> _real_ solution to the problem. Turning on MT mode decreases performance
> by ~30% (AFAIR) in mingw, so it's
Wich is last good version of proposed script for q6 4.6?
WIch version of minigui must be use for qt 4.6?
Have we some advanced for NEWS
2009/12/5 Viktor Szakáts
> Hi Istvan,
>
> > The same experience I encountered with Qt 4.6 mingw environment (not
> > TDM-MINGW).
> > No more idea, as I have the
Hi Pritpal,
>> However, before we do this, I'd like know if this is indeed the
>> _real_ solution to the problem. Turning on MT mode decreases performance
>> by ~30% (AFAIR) in mingw, so it's not a costless option.
>>
>
> Does not matter how slow/fast it is, but it is needed.
> I cannot imagi
Hello Viktor
Viktor Szakáts wrote:
>
> This is very easy to implement, only needs one extra 'mt=yes' line
> in contrib/hbqt/hbqt[s].hbc files.
>
> However, before we do this, I'd like know if this is indeed the
> _real_ solution to the problem. Turning on MT mode decreases performance
> by
t; Sent: 2009. december 5. 18:28
> To: Harbour Project Main Developer List.
> Subject: Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
>
>> @cd c:\downloads\harbour\contrib\hbide
>> @hbmk2 hbide.hbp
>> @cd c:\downloads\harbour\contrib\hbxbp\tests
>> @hbmk2
Szakáts
Sent: 2009. december 5. 18:28
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
> @cd c:\downloads\harbour\contrib\hbide
> @hbmk2 hbide.hbp
> @cd c:\downloads\harbour\contrib\hbxbp\tests
> @hbmk2 demoxbp.prg
> @
>>> practically, if i had to pick between using these features of ntfs and
>>> the cheese greeter, i'd probably pick the cheese greeter.
>>
>> Hm, what is a cheese greeter? :o
>
> that's what "cheese grater" becomes when i'm simultaneously trying to
> type "cheese grater" and saying "gdmgreeter
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
>> 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
>> anyway, so .tar doesn't give any
> @cd c:\downloads\harbour\contrib\hbide
> @hbmk2 hbide.hbp
> @cd c:\downloads\harbour\contrib\hbxbp\tests
> @hbmk2 demoxbp.prg
> @cd c:\downloads\harbour\contrib\hbqt\tests
> @hbmk2 demoqt.prg
Another suggestion:
Use -rebuild option in above hbmk2 calls. It may happen
you get a confused state i
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 Istvan,
> The same experience I encountered with Qt 4.6 mingw environment (not
> TDM-MINGW).
> No more idea, as I have the same problem with two different development
> environments, but on the same platform.
> Please jump in, to clarify that it is specific to my environment or not.
>
> ==
Here is the same.
After the last commit.
1. Delete the content of c:\harbour\mingw
2. run the script below with @rem @set HB_BUILD_MODE=cpp
-hbide Load project + push cancel button -> GPF
-demoqt exit -> GPF
3. Delete the content of c:\harbour\mingw
4. rerun the script below wit
>> Sorry for the rant.
>
> I have the same conclusion. That’s why I decided to use the Qt 4.6 mingw
> development environment. They are moving fast and my impression was that we
> are behind them at some steps, but maybe I am wrong.
QT having his own special MinGW release doesn't seem like an
ex
> OK. I will retry with these.
> But try project load + cancel (Right click on the top of project tree)
OK, tried that, all I can see is weird coloring in the context
menu (white on light-blue for highlighted item). This should be
fixed, but there is no GPF here.
Brgds,
Viktor
___
Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
> @set HB_BUILD_OPTIM=yes
This is the default.
> @set HB_BUILD_UNICODE=yes
I didn't use this one, although it shouldn't make a difference.
> @cd c:\downloads\harbour\contrib\hbide
>
> Sorry for the rant.
I have the same conclusion. Thats why I decided to use the Qt 4.6 mingw
development environment. They are moving fast and my impression was that we
are behind them at some steps, but maybe I am wrong.
Best regards,
István
___
Ha
> @set HB_BUILD_OPTIM=yes
This is the default.
> @set HB_BUILD_UNICODE=yes
I didn't use this one, although it shouldn't make a difference.
> @cd c:\downloads\harbour\contrib\hbide
> @hbmk2 hbide.hbp -cpp
> @cd c:\downloads\harbour\contrib\hbxbp\tests
> @hbmk2 demoxbp.prg -cpp
> @cd c:\downloads
> See below:
>
> http://sourceforge.net/project/shownotes.php?release_id=691876:
I'm trying to install this, and my "astonishment" just
continues about the mingw project. First they use .lzma
extension instead of well-known .7z. Fine. Then they insist
on using .tar inside the .7z file, which i
> Here it exists cleanly. (Win7/64)
I still have this. Also in hbide Load project and push cancel...
Before radical restructuration in my development environment, maybe somebody
else try to jump in the tests...
See below:
==
@echo PREREQUISITES:
@
I'd like to recommend to stick with 4.5.2 until these
issues are cleared up.
>>>
>>> Or 4.5.3 ?
>
>> While I've seen the blog entry from QT release manager
>> announcing this version, I can find no sign of it on the
>> download page. (I checked 30 minutes ago)
>
>> If you have some
List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
Hi Viktor,
>>> I'd like to recommend to stick with 4.5.2 until these
>>> issues are cleared up.
>>
>> Or 4.5.3 ?
> While I've seen the blog entry from QT release manager
&
Hi Viktor,
>>> I'd like to recommend to stick with 4.5.2 until these
>>> issues are cleared up.
>>
>> Or 4.5.3 ?
> While I've seen the blog entry from QT release manager
> announcing this version, I can find no sign of it on the
> download page. (I checked 30 minutes ago)
> If you have some
Hi Istvan,
>> I'd like to recommend to stick with 4.5.2 until these
>> issues are cleared up.
>
> Or 4.5.3 ?
While I've seen the blog entry from QT release manager
announcing this version, I can find no sign of it on the
download page. (I checked 30 minutes ago)
If you have some pointers, pl
>I'd like to recommend to stick with 4.5.2 until these
>issues are cleared up.
Or 4.5.3 ?
>> @set HB_USER_LDFLAGS=-static-libgcc
>> @set HB_USER_DFLAGS=-static-libgcc
>Can you tell, what these options are doing?
The @set HB_USER_LDFLAGS=-static-libgcc, stops the following exe to ask for
'libgc
> Maybe I missed to mention that the Qt tests are passed just in the case of
> forcing the C++ mode in the whole harbour build. If we force the C++ mode
> just in hbide, demoxbp and demoqt build, the resulting executables crashes
> in different points.
That's very bad news. QT 4.6.0 seems to be a
What can i have miss?
hbmk2 hbide.hbp
C:/HARBOUR/lib/win/mingw/libhbqt.a(hbqt_slots.o):hbqt_slots.cpp:(.tex
undefined reference to `_imp___ZN9QListData7detach3Ev'
C:/HARBOUR/lib/win/mingw/libhbqt.a(hbqt_slots.o):hbqt_slots.cpp:(.tex
undefined reference to `_imp___ZN9QListData7detach3Ev'
C:/HARBOUR
Ø Very thanks for your effort!
You're welcome.
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. december 5. 11:11
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-pr
Very thanks for your effor!
we need switch harbour to Build Mode to cpp and Minigui to DWARF2 ?
Disadvantages?
2009/12/5 Bisz István
> Hi Viktor,
>
> Maybe I missed to mention that the Qt tests are passed just in the case of
> forcing the C++ mode in the whole harbour build. If we force the
Hi Viktor,
>BTW, here today I just switched to DWARF-2 build of mingw,
>did a new clean build and didn't have this problem.
This issue has an actuality on other lists too:
http://www.mail-archive.com/fedora-mi...@lists.fedoraproject.org/msg02094.ht
ml
Yes, you are right, but see below...
>I do
Hi,
BTW, here today I just switched to DWARF-2 build of mingw,
did a new clean build and didn't have this problem.
I don't see build parameters in the report so I can just
guess that it may be you're forcing C++ mode for mingw.
In this case we should decide what to do, hack hbmk2,
hack postin
But, try what? Forcing plain mingw on a DWARF build?
Why is this good? Please report errors, I don't have
capacity to make investigation for every such report.
Please keep a separate DWARF and non-DWARF mingw
build and set PATH accordingly and let autodetection
do its work.
Probably I'll remo
I'd suggest HBMK_OPTIONS=-cpp for temporary solution.
Otherwise I have no idea how to solve that, but to be
honest I begin to give up maintaing the zillions of
combinations and working around strange issues of
strange tool releases. Probably we should focus on
some combinations which can be ma
Try with a HB_COMPILER=mingw
2009/12/3 Viktor Szakáts
> > your trick require SET HB_COMPILER not created with SET HB_COMPILER=mingw
> dwarf2 seem not work
>
> Sorry I don't understand. Here it doesn't require HB_COMPILER
> this was the whole point of modification.
>
> Brdgs,
> Viktor
>
> ___
> your trick require SET HB_COMPILER not created with SET HB_COMPILER=mingw
> dwarf2 seem not work
Sorry I don't understand. Here it doesn't require HB_COMPILER
this was the whole point of modification.
Brdgs,
Viktor
___
Harbour mailing list (attachm
your trick require SET HB_COMPILER not created with SET HB_COMPILER=mingw
dwarf2 seem not work
2009/12/3
> Revision: 13103
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13103&view=rev
> Author: vszakats
> Date: 2009-12-03 15:04:28 + (Thu, 03 Dec 2009)
>
> Log Mess
Hi,
The error: undefined reference to `__gxx_personality_v0', listed below is
solved temporally with the force of the cpp mode in postins.bat:
FROM:
echo ! Making shared version of Harbour binaries...
"%HB_HOST_BIN_DIR%\hbmk2" -quiet -q0 -lng=en-EN -shared
"-o%HB_BIN_INSTALL%\hb
-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. december 3. 17:12
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[13103] trunk/harbour
Hi István
can you guide me to recompile with GCC 4.4.1-DWARF-2
What other problem will
Hi István
can you guide me to recompile with GCC 4.4.1-DWARF-2
What other problem will be occur using DWARF-2 in harbour
> Great! Thank you Viktor, hbide, demoqt and demxbp are running with Qt 4.6
> MinGW (GCC 4.4.1-DWARF-2).
>
> Pritpal, if you have some spare time, can you please take a look
> + Added autodetection of DWARF-2 build of mingw.
> This is mingw build is required for QT 4.6.0.
Great! Thank you Viktor, hbide, demoqt and demxbp are running with Qt 4.6 MinGW
(GCC 4.4.1-DWARF-2).
Pritpal, if you have some spare time, can you please take a look of the
parent-child
with DWARF-2 installed in MinGWtd2
c:\devl\MinGWTD2\bin>gcc-dw2 -v
Using built-in specs.
Target: mingw32
Configured with: ../../gcc-4.4.1/configure --prefix=/mingw --build=mingw32 --ena
ble-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls --disable-win32-regis
try --enable-libgomp --disable-w
53 matches
Mail list logo
