Hi Viktor, Just to clarify the picture or to restrict the playing space, why these issues is are missing in linux (Fedora 12) builds?
Best regards, István -----Original Message----- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor 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. > >> 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. > > 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 the whole build results strange GPF > free executables. BTW I repeated these test with the previous Qt 4.5.3 and > the results was the same with the native Windows and linux (Fedora 12) > cross-builds: the C mode generates executables with strange GPF-s. As I > understand from your mails this was specific to my development environment, > hard to understand taking into consideration the cross-build experiences. So > I tried to enter deeper in this issue with the recommended TDM Mingw > offering GCC 4.4.1. and without forcing the C++ mode building. > > See below a debug log (at the end of this mail). > > In this log there are thread activities, so I tried to check that all the > things are ok serving multithreading. I was very surprised that the default > build offers just ST mode. After switching to the MT mode, the resulting > executables in C mode in native Windows and linux cross-builds do not > present the mentioned strange GPF-s. So please consider these just > experiments and not "theory". Thank you very much for all your testing and experimentation. I hope some more (than me) trained eyes can check you results and get to some conclusions. 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 it also works without Harbour. So the culprit could be HBQT, which makes use of, or requires HVM MT features to solve some problems on the wrapper level. It's also possible that HBQT has some explicit support for MT HVM mode, and this support accidentally broke ST builds. If true, it's IMO wrong, but beyond any personal opinions we should first of all document it, then possibly remove such MT HVM requirement and make it work in both modes without GPFs. But I'm starting to repeat myself, which doesn't add terribly lot to the picture, so I'll now wait for educated input :) Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
