[Harbour] SF tracker#2871130: 5 AdsOpenTable and Free Tables with DD (patch)
The following patch was submitted to our bug tracker: http://sourceforge.net/tracker/index.php?func=detailaid=2871130group_id=681atid=300681 Anonymous wrote: In ads1.c (adsOpen function call), when a DD is used, there are instances where free table access might still be desired. This fix solves the problem by introducing a second call to AdsOpenTable after the inital call fails to find the free table in the DD. This procedure was commented on by Alex Wong in the Advantage.xHarbour newsgroup with his approval. See comment with my name Andy Ross in the source to locate the change. Please review and apply if it is the correct solution. Chen. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile Error Using BCC 6.20
Hi Mario, I don't have this compiler. You'll have to find out which bcc system lib holds this symbol. grep WSAIoctl *.lib Brgds, Viktor On 2009 Oct 1, at 01:15, Mario H. Sabado wrote: Hi Viktor, I have the following error when compiling Harbour under Windows XP using BCC 6.20. ** ilink32.exe -q -Gn -C -aa -Tpd -Gi -x c0d32.obj @__dyn__.tmp Error: Unresolved external 'WSAIoctl' referenced from D:\HARBOUR \SOURCE\RTL\OBJ\WIN\BCC\HBSOCKET_DYN.OBJ Error: Unable to perform link mingw32-make.exe[3]: *** [harbour-20-bcc.dll] Error 2 mingw32-make.exe[2]: *** [descend] Error 2 mingw32-make.exe[1]: *** [dynlib.inst] Error 2 mingw32-make.exe: *** [source.inst] Error 2 ** Thank you for any help. Regards, Mario ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Forced ANSI Windows API calls
Hi Przemek (and All), When you find some spare time, could you help in converting these ANSI Windows API calls to native ones?: --- source/common/hbver.c:264: if( GetVersionExA( osVer ) ) source/common/hbver.c:306: if( GetVersionExA ( ( OSVERSIONINFOA * ) osVerEx ) ) source/common/hbgete.c:75: DWORD size = GetEnvironmentVariableA( szName, NULL, 0 ); source/common/hbgete.c:80: GetEnvironmentVariableA ( szName, pszBuffer, size ); source/common/hbgete.c:114: bRetVal = GetEnvironmentVariableA ( szName, szBuffer, nSize ) != 0; source/common/hbgete.c:157: return SetEnvironmentVariableA ( szName, szValue ) != 0; source/rtl/filesys.c:2687: fResult = GetCurrentDirectoryA ( ulSize, pszBuffer ); source/rtl/filesys.c:2876: type = GetDriveTypeA( buffer ); source/rtl/fstemp.c:153: if( ! GetTempPathA( ( DWORD ) ( HB_PATH_MAX - 1 ), pszName ) ) source/rtl/fstemp.c:270: if( ! GetTempPathA( ( DWORD ) HB_PATH_MAX, szTempDir ) ) source/rtl/fstemp.c:278: fResult = GetTempFileNameA ( szTempDir, pszPrefix ? pszPrefix : hb, 0, pszBuffer ); source/rtl/net.c:157: GetComputerNameA( pszValue, ulLen ); source/rtl/net.c:186: GetUserNameA( pszValue, ulLen ); contrib/hbwin/win_prn2.c:169: DWORD dwSize = GetProfileStringA( windows, device, , pPrinterName, *pdwBufferSize ); + plus a few dynamically called ones, but I'm not exactly sure how to handle them properly. --- I could start doing it, but I fear that I'd do it either in not very optimal way, and/or would break something along the way :( If you'd just modify the typical cases, I could apply the logic to the rest of occurrences. This move would be important to untie Unicode Harbour versions from Windows's internal ANSI-Unicode conversion and be able to take it in our hands. It's also simply good practice to use non-ANSI versions in Unicode programs. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - 12624
Viktor: [...] did create a potential problem if users are mixing gcc3 and gcc4. One of them is not a specific need, it's simply to INCOMPATIBLE groups of gcc compilers: = 3.3 and = 3.4. Hence gcc3 and gcc4 seems like a logical choice here. In hbmk2 compiler choice is managed by -compiler= option. And for consistency I'd like to keep it this way. [...] so still gcc3/gcc4 compiler names are better here. I was thinking this matter had been completely clarified: we do not need gcc3/gcc4 separation Along these messages I have seen how misunderstandings come again and again even after they have been explained You confused much of the explanations and your review of the information provided has been on surface. Perhaps you ever did a check of diff output content Recalling again explanations may lead to new or older confutions. I have made the work and know exactly what it need and where, it has been explained many times in many ways A lot of time and efforts has been lost on an issue that is so simple to understand and as exposed, very easy to implement Yes I know you do not want any new value in Harbour build scheme, but we need only one to inform Harbour that we are building with alternative library format in OS/2 platform Does not need any specification of gcc3 or gcc4 as you think David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF tracker#2871130: 5 AdsOpenTable and Free Tables with DD (patch)
On Thu, 01 Oct 2009, Chen Kedem wrote: Hi, The following patch was submitted to our bug tracker: http://sourceforge.net/tracker/index.php?func=detailaid=2871130group_id=681atid=300681 Anonymous wrote: In ads1.c (adsOpen function call), when a DD is used, there are instances where free table access might still be desired. This fix solves the problem by introducing a second call to AdsOpenTable after the inital call fails to find the free table in the DD. This procedure was commented on by Alex Wong in the Advantage.xHarbour newsgroup with his approval. See comment with my name Andy Ross in the source to locate the change. Please review and apply if it is the correct solution. 1. it's for old code with bugs which were fixed 2. if 1-st call to AdsOpenTable() success then uninitialized fRetry is used as loop stop condition so the behavior is random and depends on C stack context - potentialy it's infinit loop. Classic example why clear indenting is necessary - due to dropped indenting very serious bug cannot be seen immediately. 3. for non ADS_DATABASE_CONNECTION it repeates exactly the same call which fail before so the next one will also fail 4. fixing above problems is trivial but still the final modification can be source of very serious problems when free tables with the same names as the ones in DD exists. If for some reasons DD tables cannot be accessed, i.e. they are open in exclusive mode by other clients then silently the free tables are open instead without any information for user what may cause that important data will be stored in temporary tables which will be removed later or some other similar bad things. In such context the argument that free tables are usable sometimes we have to revert to free tables are very danger and we will havew to fix above fix. 5. it still does not allow to control by programmer table location and DD has higher priority hiding free tables with the same name. if ADS users really need such functionality then current code allows to access free tables using different connections and connection can be passed as dbUseArea() parameter. Anyhow if it's still not enough for and users wants to use the same connection then we can add option to force free table access by some function or using new ADS* RDD which will inherit from ADS. The second version allows to use COPY TO / APPEND FROM between free tables and DD using the same table names. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12630] trunk/harbour
Revision: 12630 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12630view=rev Author: macdavid Date: 2009-10-01 09:41:25 + (Thu, 01 Oct 2009) Log Message: --- 2009-10-01 4:25 UTC-0500 David Arturo Macias Corona (dmacias/at/mail.udg.mx) * harbour/config/os2/gcc.mk * harbour/utils/hbmk2/hbmk2.prg + Added support of OMF library format To select alternative OMF library format, use: set HB_OS2_OMF=yes * INSTALL + Added note for OMF library format Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/os2/gcc.mk trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - 12624
Viktor Szakáts wrote: Yes I know you do not want any new value in Harbour build scheme, but we need only one to inform Harbour that we are building with alternative library format in OS/2 platform Does not need any specification of gcc3 or gcc4 as you think No new value? Perhaps you missed the few thousand commits which went into make systems and hbmk2. (much of it went to OS/2 port, which essentially 3 ppl uses from the whole userbase, perhaps you should say 'thanks' instead of telling insults.) I think he means new environment value, no insult intended. Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12631] trunk/harbour
Revision: 12631 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12631view=rev Author: vszakats Date: 2009-10-01 09:58:44 + (Thu, 01 Oct 2009) Log Message: --- 2009-10-01 11:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * config/global.mk * utils/hbmk2/hbmk2.prg + Added autodetection for win/msvcia64 compiler. * INSTALL + Tweaks to links. * ChangeLog ! Fixed wrong entry header in my prev commit. * INSTALL * utils/hbmk2/hbmk2.prg * config/os2/gcc.mk ! Reverted rogue patch. I'd like to kindly ask David, to commit when doubts are cleared, otherwise I will have to revoke R/W rights to avoid extra cleanup work. This solution is wrong, for specific concerns see dev list. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/global.mk trunk/harbour/config/os2/gcc.mk trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - 12624
Viktor: No new value? Perhaps you missed the few thousand commits which went into make systems and hbmk2. (much of it went to OS/2 port, which essentially 3 ppl uses from the whole userbase, perhaps you should say 'thanks' instead of telling insults.) Case closed from my side. You misread again Just to clarify it, along time on some of your responses you tend to suggest that I am against your work and that is not true. How easily jumped in when seeing a different POV Only avoid these suggestions, somebody may believe it is true and I do not have that style. For me every Harbour developer/contributor/user are valuable David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - 12624
Case closed from my side. You misread again Just to clarify it, along time on some of your responses you tend to suggest that I am against your work and that is not true. How easily jumped in when seeing a different POV Only avoid these suggestions, somebody may believe it is true and I do not have that style. For me every Harbour developer/contributor/ user are valuable I guess you'll have to write more precisely. You wrote no new value in Harbour build scheme. If you meant no new control setting, or no new environment value (as Alex suggested), you're absolutely right. Since I'm working to REDUCE number of control knobs, I don't want to add new ones for no good reason. I'm sorry if you can't grasp the benefits of this direction. See below a little explanation: Every such knob needs to be documented, maintained, kept working. Besides each of these knobs will have to be understood by users, and we as developers will have to support them in this. Each of these knobs will have different branches inside the make system also to _test_. Each of these extra knobs adds to the complexity of the design, which means each of these simple and easy solutions will turn out to cause much more trouble on the long run, than you're saving on the design side. That is why creating a simple design is in fact much complicated than a messy one. [ Plus one: This specific extra know will have to be carefully synced by user to the gcc environment he uses. This is not obvious from the knob's name HB_OS2_OMF, which suggest this is a general option to choose object format, but this is just one little issue with such design. ] So, I don't like them. We still have such knob for MSVC which sets some internal details depending on MSVC version. I don't like it either, and I certainly wouldn't like to duplicate such bad solution. Please comment on the concerns and maybe we can find a good solution, like gcc4, which you can't tell why you don't like, or autodetection of non-OMF vs. OMF environment. Although this again goes best with gcc4 solution to keep internal logic clean. Notice there are solutions to avoid .mk logic duplication even in this case (just change HB_OS2_OMF=yes checks to HB_COMPILER=gcc4 checks). Granted, it needs a little more work to complete, since gcc4 needs to be introduced to a few places. [ As for the wlink hack (two extra knobs), it's so marginal that IMO we should just drop it. And every word spent on discussing it just time wasted. If you want to experiment with it locally, just create a new compiler .mk file ] Plus we stil have the cmdline problem, which isn't solved yet properly, so that gcc4 becomes ready for SVN. Maybe it's not the easy way, but in Harbour we value the _proper_ way, instead of the easy one. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Compile Error Using BCC 6.20
Hi Viktor, -- Message: 4 Date: Thu, 1 Oct 2009 08:41:43 +0200 From: Viktor Szak?ts harbour...@syenar.hu Subject: Re: [Harbour] Compile Error Using BCC 6.20 To: Harbour Project Main Developer List. harbour@harbour-project.org Message-ID: a840ee34-0ff8-4efc-aa02-901757d07...@syenar.hu Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi Mario, I don't have this compiler. You'll have to find out which bcc system lib holds this symbol. grep WSAIoctl *.lib Brgds, Viktor I have the following results: Binary file import32.lib matches Binary file intraweb_100_140.lib matches Binary file ws2_32.lib matches How can I include these libs to build Harbour? Thanks, Mario ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile Error Using BCC 6.20
Hi Mario, I don't have this compiler. You'll have to find out which bcc system lib holds this symbol. grep WSAIoctl *.lib Brgds, Viktor I have the following results: Binary file import32.lib matches Binary file intraweb_100_140.lib matches Binary file ws2_32.lib matches How can I include these libs to build Harbour? Thanks. ws2_32 is already on the liblist, so the problem may lie elsewhere Thanks, Mario ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12632] trunk/harbour
Revision: 12632 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12632view=rev Author: druzus Date: 2009-10-01 11:22:17 + (Thu, 01 Oct 2009) Log Message: --- 2009-10-01 13:22 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbrdddbf.h * harbour/source/rdd/dbf1.c ! resolve pending relations before clearing WA filter Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbrdddbf.h trunk/harbour/source/rdd/dbf1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Google wave invitation
I search a google wave invitation for massimo.belgrano atgmail.comThanks -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12633] trunk/harbour
Revision: 12633 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12633view=rev Author: druzus Date: 2009-10-01 12:12:14 + (Thu, 01 Oct 2009) Log Message: --- 2009-10-01 14:12 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/rdd/dbfcdx/dbfcdx1.c * harbour/source/rdd/dbf1.c * harbour/contrib/rddads/ads1.c ! resolve pending relations before clearing or setting WA filter directly or indirectly by SUPER method call Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/rddads/ads1.c trunk/harbour/source/rdd/dbf1.c trunk/harbour/source/rdd/dbfcdx/dbfcdx1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - 12624
Viktor: You reverted my first commit in Harbour SVN age :-) I hope this was an temporary action because content of code changes are self-explained I was based in doc\howtosvn.txt and this does not work in my case 6) svn commit --editor-cmd notepad.exe --username sfuser ( svn report missing log after using EPM OS/2 editor ) so I used Ryszard alternative svn commit -F file_with_saved_ChangeLog_changes --username sfuser Now back to your response, included entirely below to avoid quoting parts As you know I am in Harbour since February 1999 and seen the Harbour History near allmost So I know that one of your better personality characteristics is the cooperative work and help to reach goals even if them are not yours The hard part sometimes is that you reject until you understand it entirely. Not allways is possible So this is the spirit of your phrase: Please comment on the concerns and maybe we can find a good solution, I as allways appreciate it and want to reach goals as you have seen but this part tell me you are still confused :-) : like gcc4 As this subject of OMF felt into a long chain of David/Viktor/Maurilio unuseful messages, I moved from words to productive actions, as commit to SVN I am not an expert in OS/2 and/or os2gcc, but I am not a fool Every message I posted is based in carefully checked/tested info I started to test OMF/gcc335/gcc4xx since Oct 2008, and reported to Harbour group in August 16 2009 Harbour under OS/2 - eCS gcc, first as long messages containing a lot of info, then summaries, then diff output and last as SVN commit But I do not want to get tired to anyone with this long list of messages and explanations :-) Based in all these works, I do not have doubts about we need to do and I posted in summary. It imply os2gcc internals related to these works I understand clearly that you do not know os2gcc internals, and of course you do not need to know every detail I understand clearly that Maurilio do not know ALL os2gcc internals, but can catch quickly what they mean. For sure is our OS/2 expert :-) So when at first time a presented my work I was prepared to take care of each of the questions/doubts that may arise by your part and/or Maurilio, so them have answer in each message directly or indirectly included in info presented I supposed any doubts were solved :-) but as ghosts some of them return many times and they avoid to add benefits to Harbour capabilities Since first message I added a lot of relationed info, enough to clarify any doubts. One of them was reference and part of svn.netlabs.org/libc/wiki/kOptions (entire page is included below) which start explaining: GCC on OS/2 supports several extra options. Most start with -Z. With the exception of -Zomf (others?) they are affecting the linking. so I explained many times with different words: we need to tell Harbour about an specific os2gcc feature and repeated: we do not need gcc3/gcc4 separation My additional function is to save you or any other to work in solutions which lead to unnecessary work, based in your (theirs) remaining doubts As I said: subject is os2gcc library format types, not gcc3 vs gcc4 Perhaps changing style from long messages to short explanations (like FAQ) we can go faster: - Why OMF ? Because is native to OS/2. os2-OWatcom default to OMF too - And why we were using a.out ? Because it was only alternative when OS/2 support was added to Harbour - Why a.out is default in os2gcc: Because was only way available when gcc was ported to OS/2. OMF support was added later with proper implementation and unavoidable switch - We need to drop a.out ? No, we can use either a.out or OMF - What need Harbour to use OMF ? Just to inform him in some way hey, Harbour, build you in OMF type in OS/2 - Needs for gcc ? Inform him to use OMF type (-Zomf) and optionally set some os2gcc values - Needs for Harbour ? Inform him to inform gcc to use OMF type and set some values for Harbour - Which values for gcc ? -Zomf and optionally EMXOMFLD_TYPE, EMXOMFLD_LINKER - Which values for Harbour ? Specification to use OMF (somebody proposed HB_OS2_OMF) and corresponding values as .obj, .lib, emxomfar, ... - What are EMXOMFLD_TYPE, EMXOMFLD_LINKER ? Optional values which inform os2gcc what to use to link. Defaults are VAC365 and ilink.exe - And what are emxomfar.exe, emxomfld.exe ? os2gcc use for: + a.out type: gcc, ar and ld + OMF: gcc, emxomfar and emxomfld. Emxomfld use as final linker values specified by EMXOMFLD_TYPE, EMXOMFLD_LINKER, or defaults if are not set - We are forced to use wlink ? No, is optional. User can apply other prefered final linker - Which final linker is suggested ? Harbour with OMF support has been tested with LINK386.exe and WL.exe. First have many limitations explained in messages and WL.exe gave best results. WL.exe is an modified OpenWatcom WLINK.exe to add support of debuggers in HLL format - Which are benefits
Re: [Harbour] Re: Harbour under OS/2 - 12624
Sorry, but I've been asking some specific questions and now you begin with a long tirade starting from 1999. Let's cut it short: Please correct me, if I'm wrong: - There is 3.3.4 and lower, supporting COFF (or whatever else, let's call it non-OMF) - There is 3.3.5, which supports both OMF and non-OMF. - There is 4.0.0 and upper, which support both, but non-OMF is broken, so it doesn't work, so it only supports OMF. - Should we REALLY concentrate on 3.3.5 ? Is it some sort of widely used version, we should design Harbour around? If so, change my proposition to gccomf.mk from gcc4.mk, and this problem is also solved. - All these options are free and gratis. - How to autodetect 3.3.4 or lower vs. 4.0.0 or upper by checking a presence of a file in PATH? - GCC 4.x port is in beta status AFAIK, so linker problems which you try to workaround using WLINK are not proper/final solutions we should implement in Harbour. Instead, you should report these problems to port maintainers for fix. (if it's really a showstopper). Some notes: - You seem to be stuck at giving too many options (alternatives) for a too small user community (customizable linker because of WLINK, gcc 3.3.5, when gcc 4.x and gcc 3.3.4 are also free options with similar features). Please weight these, because it's not you who will support them on the long run, but volunteers like me in their free time. To me it looks we need to add proper support for GCC 4.x with supplied linker and we had done a 100% coverage of the problem, maybe except your case. [ I remember how aggressively you've been fighting for make_gcc_os2.cmd, and bld_os2.cmd back then. After someone added it, you _never ever_ updated those files, telling you're only a tester. After that I had to update them several dozens of times. ] - easy addition of any feature is not a virtue in Harbour. It's not even and argument. IOW, it doesn't serve Harbour or its users the best if an implementation of a feature is easy for the developer. It only serves the committer because he could save some time for himself. This is great and all that, but not a value for the community. - You still didn't fix gcc4 (or gccomf) to handle long cmdlines. Telling that it's too complicated to one of my suggestions. If you're only interested in easy solutions and nothing which is complicated (but is right), then it will be very difficult to come to a Harbour-quality resolution for this matter. Brgds, Viktor On 2009 Oct 1, at 16:07, David Arturo Macias Corona wrote: Viktor: You reverted my first commit in Harbour SVN age :-) I hope this was an temporary action because content of code changes are self-explained I was based in doc\howtosvn.txt and this does not work in my case 6) svn commit --editor-cmd notepad.exe --username sfuser ( svn report missing log after using EPM OS/2 editor ) so I used Ryszard alternative svn commit -F file_with_saved_ChangeLog_changes --username sfuser Now back to your response, included entirely below to avoid quoting parts As you know I am in Harbour since February 1999 and seen the Harbour History near allmost So I know that one of your better personality characteristics is the cooperative work and help to reach goals even if them are not yours The hard part sometimes is that you reject until you understand it entirely. Not allways is possible So this is the spirit of your phrase: Please comment on the concerns and maybe we can find a good solution, I as allways appreciate it and want to reach goals as you have seen but this part tell me you are still confused :-) : like gcc4 As this subject of OMF felt into a long chain of David/Viktor/ Maurilio unuseful messages, I moved from words to productive actions, as commit to SVN I am not an expert in OS/2 and/or os2gcc, but I am not a fool Every message I posted is based in carefully checked/tested info I started to test OMF/gcc335/gcc4xx since Oct 2008, and reported to Harbour group in August 16 2009 Harbour under OS/2 - eCS gcc, first as long messages containing a lot of info, then summaries, then diff output and last as SVN commit But I do not want to get tired to anyone with this long list of messages and explanations :-) Based in all these works, I do not have doubts about we need to do and I posted in summary. It imply os2gcc internals related to these works I understand clearly that you do not know os2gcc internals, and of course you do not need to know every detail I understand clearly that Maurilio do not know ALL os2gcc internals, but can catch quickly what they mean. For sure is our OS/2 expert :-) So when at first time a presented my work I was prepared to take care of each of the questions/doubts that may arise by your part and/ or Maurilio, so them have answer in each message directly or indirectly included in info presented I supposed any doubts were solved
Re: [Harbour] Compile Error Using BCC 6.20
Hi Viktor, -- Message: 6 Date: Thu, 1 Oct 2009 13:14:46 +0200 From: Viktor Szak?ts harbour...@syenar.hu Subject: Re: [Harbour] Re: Compile Error Using BCC 6.20 To: Viktor Szak?ts harbour...@syenar.hu Cc: Harbour Project Main Developer List. harbour@harbour-project.org Message-ID: 24c252bf-3552-4073-a5a7-0177b93ea...@syenar.hu Content-Type: text/plain; charset=us-ascii; format=flowed Hi Mario, I don't have this compiler. You'll have to find out which bcc system lib holds this symbol. grep WSAIoctl *.lib Brgds, Viktor I have the following results: Binary file import32.lib matches Binary file intraweb_100_140.lib matches Binary file ws2_32.lib matches How can I include these libs to build Harbour? Thanks. ws2_32 is already on the liblist, so the problem may lie elsewhere Pressed send by mistake, well, check your BCC setup, I'd guess it's wrong. I can compile Harbour with BCC 5.82 successfully. What I have noticed is that WSAIoctl from BCC 5.82 only exist with ws2_32.lib, while from BCC 6.20, it is present both with import32.lib and ws2_32.lib. Would the ordering of these two libs help in resolving the issue? Thanks and best regards, Mario ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile Error Using BCC 6.20
I don't have this compiler. You'll have to find out which bcc system lib holds this symbol. grep WSAIoctl *.lib Brgds, Viktor I have the following results: Binary file import32.lib matches Binary file intraweb_100_140.lib matches Binary file ws2_32.lib matches How can I include these libs to build Harbour? Thanks. ws2_32 is already on the liblist, so the problem may lie elsewhere Pressed send by mistake, well, check your BCC setup, I'd guess it's wrong. I can compile Harbour with BCC 5.82 successfully. What I have noticed is that WSAIoctl from BCC 5.82 only exist with ws2_32.lib, while from BCC 6.20, it is present both with import32.lib and ws2_32.lib. Would the ordering of these two libs help in resolving the issue? I don't think so, since import32.lib isn't used at all in this case. Please verify your BCC 6.20 installation, .cfg files. If these are wrong, you can still build all other versions of BCC (which happen to be configured right). Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile Error Using BCC 6.20
Hi Viktor, Message: 3 Date: Thu, 1 Oct 2009 17:48:12 +0200 From: Viktor Szak?ts harbour...@syenar.hu Subject: Re: [Harbour] Compile Error Using BCC 6.20 To: Harbour Project Main Developer List. harbour@harbour-project.org Message-ID: f2d70c1f-bb6a-4e60-8531-6d98f909b...@syenar.hu Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes I don't have this compiler. You'll have to find out which bcc system lib holds this symbol. grep WSAIoctl *.lib Brgds, Viktor I have the following results: Binary file import32.lib matches Binary file intraweb_100_140.lib matches Binary file ws2_32.lib matches How can I include these libs to build Harbour? Thanks. ws2_32 is already on the liblist, so the problem may lie elsewhere Pressed send by mistake, well, check your BCC setup, I'd guess it's wrong. I can compile Harbour with BCC 5.82 successfully. What I have noticed is that WSAIoctl from BCC 5.82 only exist with ws2_32.lib, while from BCC 6.20, it is present both with import32.lib and ws2_32.lib. Would the ordering of these two libs help in resolving the issue? I don't think so, since import32.lib isn't used at all in this case. Please verify your BCC 6.20 installation, .cfg files. If these are wrong, you can still build all other versions of BCC (which happen to be configured right). I tried to rename import32.lib from BCC 6.20 to test if it's being used and I got the following error: bcc32.exe -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -e..\..\..\..\..\bin\win\bcc\hbpp.exe hbpp.obj -L../../../../../lib/win/bcc ../../../../../lib/win/bcc/hbnortl.lib ../../../../../lib/win/bcc/hbcommon.lib kernel32.lib user32.lib ws2_32.lib advapi32.lib gdi32.lib Fatal: Unable to open file 'IMPORT32.LIB' mingw32-make.exe[3]: *** [hbpp.exe] Error 1 rm hbpp.obj mingw32-make.exe[2]: *** [descend] Error 2 mingw32-make.exe[1]: *** [pp.inst] Error 2 mingw32-make.exe: *** [source.inst] Error 2 Anyway, I can stick BCC 5.82 at the moment which is working fine. Thanks again for your time. Best regards, Mario ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How to create and use DLL like HRB
Hi! In my program, I want to allow users to add their modules. This works very well with the modules in the HRB. However, in modules HRB can not add blocks in C (for example, inserts the code referring APIs ). I found information that can be just as HRB, use DLLs. In message: http://www.nabble.com/Pcode-and-hb_LibDo%28%29...-what-has-changed--td11161011.html http://www.nabble.com/Pcode-and-hb_LibDo%28%29...-what-has-changed--td11161011.html You write that use HB_LIBLOAD() function, and found the sample programs. But this sample not work (may be I wrong compiling it ?). Therefore, I looked to the sources HB_LIBLOAD() function. This function only loads the library (API LoadLibrary() ) and attempts to perform functions such INIT. So, I think I have to put yourself in the library operations that add to an array of symbols the new my functions, and do it during the loading library using the APIs DllEntryPoint() function. So please give examples of sources program and librarie and how they build (options for BCC32 and ILINK32). -- View this message in context: http://www.nabble.com/How-to-create-and-use-DLL-like-HRB-tp25698377p25698377.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12634] trunk/harbour
Revision: 12634 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12634view=rev Author: vszakats Date: 2009-10-01 16:04:11 + (Thu, 01 Oct 2009) Log Message: --- 2009-10-01 17:58 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * INSTALL * utils/hbmk2/hbmk2.prg * config/os2/gcc.mk + config/os2/gccomf.mk + Added OS/2 GCC OMF support. This tries to fix resource support in hbmk2 compared to David's solution. hbmk2 support is completely newly done, .mk support was imported as is, with little change in actication logic. ! Fixed to use $(ECHOQUOTE) in some $(ECHO) command parameters. ; NOTE: Until we don't add autodetection for OMF supporting GCC versions, it will have to be selected manually using HB_COMPILER=gccomf. Notice that for GCC 4.x this is obligatory since COFF support is broken in these versions. Additional EMX* envvar options are left as an excercise for the users, I intentionally didn't document these in INSTALL, as INSTALL servers as Harbour documentation, not 3rd party tools like GCC. * config/global.mk ! Minor in comment. * contrib/hbqt/Makefile * contrib/hbqt/hbqts/Makefile * contrib/gtqtc/gtqtcs/Makefile * contrib/gtqtc/Makefile ! Disabled QT dependent parts for msvcia64 targets. ; Fails with error: --- z:\devl\qt\4.5.2\include\qtcore\../../src/corelib/tools/qvector.h(541) : warning C4346: 'QVectorT::iterator' : dependent name is not a type prefix with 'typename' to indicate a type z:\devl\qt\4.5.2\include\qtcore\../../src/corelib/tools/qvector.h(541) : error C2143: syntax error : missing ';' before 'QVectorT::insert' z:\devl\qt\4.5.2\include\qtcore\../../src/corelib/tools/qvector.h(541) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int z:\devl\qt\4.5.2\include\qtcore\../../src/corelib/tools/qvector.h(541) : fatal error C1903: unable to recover from previous error(s); stopping compilation --- * package/winuni/HARBOUR_README_MINGWARM * Minor raw update to document newly found --force-local tar switch. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/global.mk trunk/harbour/config/os2/gcc.mk trunk/harbour/contrib/gtqtc/Makefile trunk/harbour/contrib/gtqtc/gtqtcs/Makefile trunk/harbour/contrib/hbqt/Makefile trunk/harbour/contrib/hbqt/hbqts/Makefile trunk/harbour/package/winuni/HARBOUR_README_MINGWARM trunk/harbour/utils/hbmk2/hbmk2.prg Added Paths: --- trunk/harbour/config/os2/gccomf.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile Error Using BCC 6.20
Please verify your BCC 6.20 installation, .cfg files. If these are wrong, you can still build all other versions of BCC (which happen to be configured right). I tried to rename import32.lib from BCC 6.20 to test if it's being used and I got the following error: bcc32.exe -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -e..\..\.. \..\..\bin\win\bcc\hbpp.exe hbpp.obj -L../../../../../lib/win/ bcc ../../../../../lib/win/bcc/hbnortl.lib ../../../../../lib/win/ bcc/hbcommon.lib kernel32.lib user32.lib ws2_32.lib advapi32.lib gdi32.lib Fatal: Unable to open file 'IMPORT32.LIB' mingw32-make.exe[3]: *** [hbpp.exe] Error 1 rm hbpp.obj mingw32-make.exe[2]: *** [descend] Error 2 mingw32-make.exe[1]: *** [pp.inst] Error 2 mingw32-make.exe: *** [source.inst] Error 2 Anyway, I can stick BCC 5.82 at the moment which is working fine. Thanks again for your time. So import32.lib is automatically pulled by BCC linker. We can't really do too much about it. Anyhow you should still try to fix your BCC .cfg files. Maybe they point to other BCC version dir. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2 cmdline hack removal
Hi Maurilio, David, All, Does anyone of you want to remove config/global/watcom.mk hacks added to workaround recently fixed GNU Make bugs? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour Itanium build success
Hi All, Harbour Windows MSVC 2008 Itanium target was just tested OK. It needs MSVC 2008 Team Suite (I just get hold of a legal copy). (maybe 2005 works also, I don't know) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12635] trunk/harbour
Revision: 12635 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12635view=rev Author: druzus Date: 2009-10-02 00:19:28 + (Fri, 02 Oct 2009) Log Message: --- 2009-10-02 02:19 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbrdddbf.h * harbour/include/hbrddnsx.h * harbour/include/hbrddcdx.h * harbour/include/hbrddfpt.h * harbour/include/hbrddntx.h * harbour/source/rdd/dbf1.c * harbour/source/rdd/dbffpt/dbffpt1.c * harbour/source/rdd/dbfntx/dbfntx1.c * harbour/source/rdd/dbfnsx/dbfnsx1.c * harbour/source/rdd/dbfcdx/dbfcdx1.c * harbour/contrib/hbbmcdx/hbbmcdx.h * code cleanup Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbbmcdx/hbbmcdx.h trunk/harbour/include/hbrddcdx.h trunk/harbour/include/hbrdddbf.h trunk/harbour/include/hbrddfpt.h trunk/harbour/include/hbrddnsx.h trunk/harbour/include/hbrddntx.h trunk/harbour/source/rdd/dbf1.c trunk/harbour/source/rdd/dbfcdx/dbfcdx1.c trunk/harbour/source/rdd/dbffpt/dbffpt1.c trunk/harbour/source/rdd/dbfnsx/dbfnsx1.c trunk/harbour/source/rdd/dbfntx/dbfntx1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2.0beta3 deployment success
So far logs are clean and phones are quiet :) I'd like to thank all ( in particular Przemyslaw and Viktor ) for the great job done in the last months. With the new standard make, clean, install build system is really easy to import harbour as a standard Eclipse C Makefile project. After the -fpic discussion, I've packed my full ERP into few shared libs so that the former 1-3MB executables are now 10KB ( yes 10KB on both linux and win ) and are made of 1 function call. The main advantage is that now a small fix or an entire new release can be done simply uploading a new shared lib ( and in Linux it can be done even when users are working ). Many thanks again to all. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
