Re: [Harbour] Re: Switch to detect undeclared vars being used
Viktor, one thing I'd like to have is the ability of the compiler to spot iVars like it does variables, I mean unused, not declared and so on, while it now simply ignores all of them and you get an error when executing such code. Best regards. Maurilio. Viktor Szakáts wrote: >>> lot of success. One thing that will make our lives easier in 100,000 >>> lines >>> of Clipper code is some sort of switch in Harbour / hbmk2 that will warn >>> you >>> if you are using a variable that wasn't declared by LOCAL, PRIV, MEMVAR, >>> etc >>> etc... in a function. >>> >> If tou want to detect such occurances: -w3 -es3 > > You probably meant: -es2 > (there is no -es3 option in Harbour (nor Clipper)) > >> If you want to detect and ignore: -w0 -es2 > > Rather simply: -w3, -w2, or -w1 > > extra -es2 means: threat warnings as errors. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13948] trunk/harbour
Massimo Belgrano wrote: > > Related function & See also > Implemented: after r13953. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13948-trunk-harbour-tp4607167p4610819.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13948] trunk/harbour
Massimo Belgrano wrote: > > Can you give me a solution for having path indipendent > if i move the structure of project can i move > Using =&"curdir()" ) in project directory? > 1. I assume you have the sources in the same folder where .hbi resides. If yes, 2. Copy the whole folder contents and paste in the target folder. 3. Open hbIDE.ini and change the path of old project to new one. 4. Run hbIDE, and you are done. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13948-trunk-harbour-tp4607167p4610827.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
David, it seems it does not find os2.a and rtl c library. I was going to create a ld.exe which simply spits out what it received from gcc so we can see what it needs :) Maurilio. David Arturo Macias Corona wrote: > Viktor: > >>> Harbour need shorter intermediate file size > >>I also need a bigger house ;) It's not an option >>unfortunately, at least I don't know of any. But >>the source is there so anyone can try to enhance >>it. > > Perhaps you will get your bigger house before we can get a shorter > intermediate file :-) > >>IMO rather someone should fix this OS/2 GCC >>toolchain bug. > > Yes I hope someone can modify this toolchain, but is not a bug, is a > consequence of design > >>?? > >>I'd think it's rather my change here: >> 2010-02-21 15:03 UTC+0100 Viktor Szakats > >>You say thank you in a rather unique way. > > ??? > >>Ops, this was 13946. > >>Anyways. > > I am doing one step in each time, so I stated > - "13945" > - "recent libraries changes" > to avoid confutions. It was not enough > >>2010-02-21 15:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * config/os2/gcc.mk >>* Changed to use 'ld' tools directly when creating >> Harbour dynamic libraries. >>; Please test, it's possible that some option have to be >> deleted, changed, or some system/compiler libs added >> manually to make it work. > > And now here we are in next step > > Using os2gcc442: > > * $Id: ChangeLog 13951 2010-02-21 21:02:05Z vszakats $ > 2010-02-21 22:01 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > --- > make[3]: Entering directory > `E:/harbour102/harbour/src/dynlib/obj/os2/gccomf' > emxomfld -shared -L../../../../../lib/os2/gccomf -Zomf -o > ../../../../../bin/os2/gccomf/harbour.dll @__dyn__.tmp __dyn__.def -lsocket > emxomfld: invalid option (-shared) > make[3]: *** [harbour.dll] Error 1 > make[3]: Leaving directory > `E:/harbour102/harbour/src/dynlib/obj/os2/gccomf' > make[2]: *** [descend] Error 2 > make[2]: Leaving directory `E:/harbour102/harbour/src/dynlib' > make[1]: *** [dynlib] Error 2 > --- > > and trying manually: > > [E:\harbour102\harbour\src\dynlib\obj\os2\gccomf]emxomfld -shared > -L../../../../../lib/os2/gccomf -Zomf -o > ../../../../../bin/os2/gccomf/harbour.dll @__dyn__. > tmp __dyn__.def -lsocket > emxomfld: invalid option (-shared) > > Removing -shared: > > [E:\harbour102\harbour\src\dynlib\obj\os2\gccomf]emxomfld > -L../../../../../lib/os2/gccomf -Zomf -o > ../../../../../bin/os2/gccomf/harbour.dll @__dyn__.tmp __dy > n__.def -lsocket > emxomfld: invalid option (-Zomf) > > Removing -Zomf: > > [E:\harbour102\harbour\src\dynlib\obj\os2\gccomf]emxomfld > -L../../../../../lib/os2/gccomf -o > ../../../../../bin/os2/gccomf/harbour.dll @__dyn__.tmp __dyn__.def > -lsocket > weakld: cannot open library file > '..\..\..\..\..\lib\os2\gccomf\socket_s.a'. > emxomfld: weak prelinker failed. (rc=8) > > Removing -lsocket: > > 1108 lines of errors > Some segments are: > > weakld: error: Unresolved symbol (UNDEF) 'DosScanEnv'. > weakld: info: The symbol is referenced by: > E:\harbour102\harbour\src\common\obj\os2\gccomf\hbgete.o > weakld: error: Unresolved symbol (UNDEF) 'recv'. > weakld: info: The symbol is referenced by: > E:\harbour102\harbour\src\rtl\obj\os2\gccomf\hbsocket.o > weakld: error: Unresolved symbol (UNDEF) '_memcmp'. > weakld: info: The symbol is referenced by: > E:\harbour102\harbour\src\rtl\obj\os2\gccomf\hbi18n1.o > E:\harbour102\harbour\src\macro\obj\os2\gccomf\macrolex.o > [...] > Error! E2028: _strcmp is an undefined reference > Error! E2028: ___moddi3 is an undefined reference > Error! E2028: ___divdi3 is an undefined reference > Error! E2028: _pow is an undefined reference > Error! E2028: _fmod is an undefined reference > Error! E2028: _ldexp is an undefined reference > [...] > Error! E2028: ___main is an undefined reference > file > E:\harbour102\harbour\src\common\obj\os2\gccomf\expropt1.o(expropt1.o): > undefined symbol _strcmp > file > E:\harbour102\harbour\src\common\obj\os2\gccomf\expropt2.o(expropt2.o): > undefined symbol ___moddi3 > file > E:\harbour102\harbour\src\common\obj\os2\gccomf\expropt2.o(expropt2.o): > undefined symbol ___divdi3 > file > E:\harbour102\harbour\src\common\obj\os2\gccomf\expropt2.o(expropt2.o): > undefined symbol _pow > file > E:\harbour102\harbour\src\common\obj\os2\gccomf\expropt2.o(expropt2.o): > undefined symbol _fmod > file E:\harbour102\harbour\src\common\obj\os2\gccomf\hbarch.o(hbarch.o): > undefined symbol _ldexp > file E:\harbour102\harbour\src\common\obj\os2\gccomf\hbarch.o(hbarch.o): > undefined symbol _frexp > file E:\harbour102\harbour\src\common\obj\os2\gccomf\hbarch.o(hbarch.o): > undefined symbol ___fixunsdfdi > file E:\harbour102\harbour\src\common\obj\os2\gccomf\hbdate.o(hbdate.o): > undefined symbol ___divdi3 > file E:\harbour102\harbour\src\common\obj\os2\gccomf\hbdate.o(hbdate.o): > undefined symbol ___moddi3 > > [..
Re: [Harbour] Re: Switch to detect undeclared vars being used
Hi Maurilio, On 2010 Feb 22, at 09:02, Maurilio Longo wrote: > Viktor, > > one thing I'd like to have is the ability of the compiler to spot iVars like > it does variables, I mean unused, not declared and so on, while it now simply > ignores all of them and you get an error when executing such code. By 'iVars', you means object vars? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13945] trunk/harbour
Przemyslaw, > * harbour/src/vm/classes.c > + added new PRG function: > __clsMsgType( , | ) -> >is one of HB_OO_MSG_* values defined in hboo.ch or -1 if > message is not supported. > Thanks, I'll test it shortly. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
David, here it is my ld.exe while building ld.exe itself after substituing it with itself :)) (E:\harbour\ld)hbmk2 -st -shared ld.prg hbmk2: Processing environment options: -mt -compiler=gcc hbmk2: Processing configuration: E:\HARBOUR\BIN\hbmk.cfg Harbour 2.1.0dev (Rev. 13913) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'ld.prg'... Lines 8, Functions/Procedures 1 Generating C source output to 'E:\TMP\ld.c'... Done. 8< -o ld.exe E:/SVILUPPO/GCC/V3.3.5/USR/lib/crt0.o -Le:\harbour\lib -LE:/Sviluppo/g cc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/lib /gcc-lib -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/SVI LUPPO/GCC/V3.3.5/USR/lib/tcpipv4 -LE:/SVILUPPO/GCC/V3.3.5/USR/lib -LE:/harbour/l d -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/g cc/v3.3.5/usr/i386-pc-os2-emx/lib -LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/l ib -LE:/Sviluppo/gcc/v3.3.5/usr/lib E:\TMP\ld.o E:\TMP\hbmk_prvkqn.o -lhbmainstd -lhbcplr -lhbdebug -lharbour -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_d ll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 - lgcc_so_d -lc_alias -lc_dll -los2 >8 my ld.exe is a simple function main( ... ) ? ... return 0 So, we can see that it points to a lot of libs, now let's see what happens when it is called in building harbour.dll Maurilio. Maurilio Longo wrote: > David, > > it seems it does not find os2.a and rtl c library. > > I was going to create a ld.exe which simply spits out what it received from > gcc so we can see what it needs :) > > Maurilio. > > David Arturo Macias Corona wrote: >> Viktor: >> Harbour need shorter intermediate file size >>> I also need a bigger house ;) It's not an option >>> unfortunately, at least I don't know of any. But >>> the source is there so anyone can try to enhance >>> it. >> Perhaps you will get your bigger house before we can get a shorter >> intermediate file :-) >> >>> IMO rather someone should fix this OS/2 GCC >>> toolchain bug. >> Yes I hope someone can modify this toolchain, but is not a bug, is a >> consequence of design >> >>> ?? >>> I'd think it's rather my change here: >>> 2010-02-21 15:03 UTC+0100 Viktor Szakats >>> You say thank you in a rather unique way. >> ??? >> >>> Ops, this was 13946. >>> Anyways. >> I am doing one step in each time, so I stated >> - "13945" >> - "recent libraries changes" >> to avoid confutions. It was not enough >> >>> 2010-02-21 15:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >>> * config/os2/gcc.mk >>>* Changed to use 'ld' tools directly when creating >>> Harbour dynamic libraries. >>>; Please test, it's possible that some option have to be >>> deleted, changed, or some system/compiler libs added >>> manually to make it work. >> And now here we are in next step >> >> Using os2gcc442: >> >> * $Id: ChangeLog 13951 2010-02-21 21:02:05Z vszakats $ >> 2010-02-21 22:01 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> --- >> make[3]: Entering directory >> `E:/harbour102/harbour/src/dynlib/obj/os2/gccomf' >> emxomfld -shared -L../../../../../lib/os2/gccomf -Zomf -o >> ../../../../../bin/os2/gccomf/harbour.dll @__dyn__.tmp __dyn__.def -lsocket >> emxomfld: invalid option (-shared) >> make[3]: *** [harbour.dll] Error 1 >> make[3]: Leaving directory >> `E:/harbour102/harbour/src/dynlib/obj/os2/gccomf' >> make[2]: *** [descend] Error 2 >> make[2]: Leaving directory `E:/harbour102/harbour/src/dynlib' >> make[1]: *** [dynlib] Error 2 >> --- >> >> and trying manually: >> >> [E:\harbour102\harbour\src\dynlib\obj\os2\gccomf]emxomfld -shared >> -L../../../../../lib/os2/gccomf -Zomf -o >> ../../../../../bin/os2/gccomf/harbour.dll @__dyn__. >> tmp __dyn__.def -lsocket >> emxomfld: invalid option (-shared) >> >> Removing -shared: >> >> [E:\harbour102\harbour\src\dynlib\obj\os2\gccomf]emxomfld >> -L../../../../../lib/os2/gccomf -Zomf -o >> ../../../../../bin/os2/gccomf/harbour.dll @__dyn__.tmp __dy >> n__.def -lsocket >> emxomfld: invalid option (-Zomf) >> >> Removing -Zomf: >> >> [E:\harbour102\harbour\src\dynlib\obj\os2\gccomf]emxomfld >> -L../../../../../lib/os2/gccomf -o >> ../../../../../bin/os2/gccomf/harbour.dll @__dyn__.tmp __dyn__.def >> -lsocket >> weakld: cannot open library file >> '..\..\..\..\..\lib\os2\gccomf\socket_s.a'. >> emxomfld: weak prelinker failed. (rc=8) >> >> Removing -lsocket: >> >> 1108 lines of errors >> Some segments are: >> >> weakld: error: Unresolved symbol (UNDEF) 'DosScanEnv'. >> weakld: info: The symbol is referenced by: >> E:\harbour102\harbour\src\common\obj\os2\gccomf\hbgete.o >> weakld: error: Unresolved symbol (UNDEF) 'recv'. >> weakld: info: The symbol is referenced by: >> E:\harbour102\harbour\src\rtl\obj\os2\gccomf\hbsocket.o >> weakld: error: Unresolved symbol (UNDEF) '_memcmp'. >> weakld: info: The sy
[Harbour] SF.net SVN: harbour-project:[13955] trunk/harbour
Revision: 13955 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13955&view=rev Author: vouchcac Date: 2010-02-22 09:45:25 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 01:41 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/ideharbourhelp.prg + Implemented: presentation of documents per "Category" field. ; QUESTION: is it worth to populate the tree with sub-category. In my opinion, a function can belong to many categories. If yes, what method to adopt? Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideharbourhelp.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
And here, in all of its beauty, the call to build harbour.dll :) Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org ! MAKE: make 3.81 D:\OS2\CMD.EXE ! HB_BIN_INSTALL: e:\harbour\bin ! HB_LIB_INSTALL: e:\harbour\lib ! HB_INC_INSTALL: e:\harbour\include ! HB_DOC_INSTALL: e:\harbour\doc ! HB_BUILD_SHARED: yes ! HB_BUILD_STRIP: all ! HB_HOST_PLAT: os2 (x86) HB_SHELL: os2 ! HB_PLATFORM: os2 (x86) (autodetected) ! HB_COMPILER: gcc ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on os2 platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not supported on os2 platform ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on os2 platform ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR make[2]: `../../../../../lib/os2/gcc/hbcommon.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbnortl.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbpp.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbcplr.a' is up to date. gcc -L../../../../../lib/os2/gcc -o ..\..\..\..\..\bin\os2\gcc\harbour.exe harbour.o -lhbcplr -lhbpp -lhbnortl -lhbcommon -s 8< -o ..\..\..\..\..\bin\os2\gcc\harbour.exe -s E:/SVILUPPO/GCC/V3.3.5/USR/lib/crt0.o -L../../../../../lib/os2/gcc -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/SVILUPPO/GCC/V3.3.5/USR/lib -LE:/REPOSITORY/HARBOUR/src/main/obj/os2/gcc -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib -LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib -LE:/Sviluppo/gcc/v3.3.5/usr/lib harbour.o -lhbcplr -lhbpp -lhbnortl -lhbcommon -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 >8make[2]: `../../../../../lib/os2/gcc/hbvm.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbmainstd.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbmaindllh.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbvmmt.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbrtl.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/gtcgi.a' is up to date. ! 'gtcrs' library skipped (component not found) ! 'gtdos' library skipped (platform not supported) ! 'gtgui' library skipped (platform not supported) make[3]: `../../../../../../lib/os2/gcc/gtos2.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/gtpca.a' is up to date. ! 'gtsln' library skipped (component not found) make[3]: `../../../../../../lib/os2/gcc/gtstd.a' is up to date. ! 'gttrm' library skipped (platform or compiler not supported) ! 'gtwin' library skipped (platform not supported) ! 'gtwvt' library skipped (platform not supported) ! 'gtxwc' library skipped (component not found) make[2]: `../../../../../lib/os2/gcc/hbmacro.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbcpage.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hblang.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbrdd.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbnulrdd.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/rddntx.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/rddnsx.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/rddcdx.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/rddfpt.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbsix.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbhsx.a' is up to date. make[3]: `../../../../../../lib/os2/gcc/hbusrrdd.a' is up to date. make[3]: `../../../../../../../lib/os2/gcc/hbuddall.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbextern.a' is up to date. make[2]: `../../../../../lib/os2/gcc/hbdebug.a' is up to date. gcc -shared -L../../../../../lib/os2/gcc -o ../../../../../bin/os2/gcc/harbour.dll @__dyn__.tmp __dyn__.def -lsocket -s 8< -Zdll -o ../../../../../bin/os2/gcc/harbour.dll -s E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o -L../../../../../lib/os2/gcc -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/SVILUPPO/GCC/V3.3.5/USR/lib -LE:/REPOSITORY/HARBOUR/src/dynlib/obj/os2/gcc -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib -LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib -LE:/Sviluppo/gcc
[Harbour] SF.net SVN: harbour-project:[13956] trunk/harbour
Revision: 13956 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13956&view=rev Author: vouchcac Date: 2010-02-22 09:50:42 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 01:48 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) + contrib/hbide/resources/harbour.png ! Missed from prev commit. ! Enabled building the Harbour Documentation structure at the time of hbIDE start. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/contrib/hbide/resources/harbour.png This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13955] trunk/harbour
Version: Harbour 2.1.0dev (Rev. 13954) Compiler: GNU C 4.4.1 (32-bit) Platform: Linux 2.6.31-16-generic i686 I get this runtime error on Hbide pressing the "Home" icon on Document Viewer Dock Error BASE/1132 Bound error: array access Called from IDEHARBOURHELP:EXECEVENT(409) Called from (b)IDEHARBOURHELP_INSTALLSIGNALS(333) Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) Called from APPEVENT(0) Called from HBIDE:CREATE(417) Called from MAIN(110) Thank you ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13955] trunk/harbour
Same error on Rev. 13955 ... Best regards ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Nice. Now all the absolute paths to gcc lib locations need to be sorted out. I can add support for $(HB_COMP_PATH_PUB) variable for os2/gcc, but this is not enough, as the relative paths also hold the gcc version number. Plus the logic should be checked for each gcc version, as it may change along the way. Brgds, Viktor On 2010 Feb 22, at 10:47, Maurilio Longo wrote: > And here, in all of its beauty, the call to build harbour.dll > > :) > > Maurilio. > > > -- > __ > | | | |__| Maurilio Longo > |_|_|_|| farmaconsult s.r.l. > > > ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org > ! MAKE: make 3.81 D:\OS2\CMD.EXE > ! HB_BIN_INSTALL: e:\harbour\bin > ! HB_LIB_INSTALL: e:\harbour\lib > ! HB_INC_INSTALL: e:\harbour\include > ! HB_DOC_INSTALL: e:\harbour\doc > ! HB_BUILD_SHARED: yes > ! HB_BUILD_STRIP: all > ! HB_HOST_PLAT: os2 (x86) HB_SHELL: os2 > ! HB_PLATFORM: os2 (x86) (autodetected) > ! HB_COMPILER: gcc > ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) > ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) > ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. > ! Component: 'gpm' not supported on os2 platform > ! Component: 'slang' not found. Configure with HB_WITH_SLANG. > ! Component: 'curses' not supported on os2 platform > ! Component: 'x11' not found. Configure with HB_WITH_X11. > ! Component: 'wattcp/watt-32' not supported on os2 platform > ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR > make[2]: `../../../../../lib/os2/gcc/hbcommon.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbnortl.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbpp.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbcplr.a' is up to date. > gcc -L../../../../../lib/os2/gcc -o ..\..\..\..\..\bin\os2\gcc\harbour.exe > harbour.o -lhbcplr -lhbpp -lhbnortl -lhbcommon -s > > 8< > -o ..\..\..\..\..\bin\os2\gcc\harbour.exe -s > E:/SVILUPPO/GCC/V3.3.5/USR/lib/crt0.o -L../../../../../lib/os2/gcc > -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 > -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib > -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 > -LE:/SVILUPPO/GCC/V3.3.5/USR/lib -LE:/REPOSITORY/HARBOUR/src/main/obj/os2/gcc > -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 > -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib > -LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib > -LE:/Sviluppo/gcc/v3.3.5/usr/lib harbour.o -lhbcplr -lhbpp -lhbnortl > -lhbcommon -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 > -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 > -lgcc_so_d -lc_alias -lc_dll -los2 > >8make[2]: > `../../../../../lib/os2/gcc/hbvm.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbmainstd.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbmaindllh.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbvmmt.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbrtl.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/gtcgi.a' is up to date. > ! 'gtcrs' library skipped (component not found) > ! 'gtdos' library skipped (platform not supported) > ! 'gtgui' library skipped (platform not supported) > make[3]: `../../../../../../lib/os2/gcc/gtos2.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/gtpca.a' is up to date. > ! 'gtsln' library skipped (component not found) > make[3]: `../../../../../../lib/os2/gcc/gtstd.a' is up to date. > ! 'gttrm' library skipped (platform or compiler not supported) > ! 'gtwin' library skipped (platform not supported) > ! 'gtwvt' library skipped (platform not supported) > ! 'gtxwc' library skipped (component not found) > make[2]: `../../../../../lib/os2/gcc/hbmacro.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbcpage.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hblang.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbrdd.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbnulrdd.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/rddntx.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/rddnsx.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/rddcdx.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/rddfpt.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbsix.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbhsx.a' is up to date. > make[3]: `../../../../../../lib/os2/gcc/hbusrrdd.a' is up to date. > make[3]: `../../../../../../../lib/os2/gcc/hbuddall.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbextern.a' is up to date. > make[2]: `../../../../../lib/os2/gcc/hbdebug.a' is up to date. > gcc -shared -L../../../../../lib/os2/gcc -o > ../../../../../bin/os2/gcc/harbour.dll @__dyn__.tmp __dyn__.def -lsocket -s > > 8<-
[Harbour] SF.net SVN: harbour-project:[13957] trunk/harbour
Revision: 13957 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13957&view=rev Author: vouchcac Date: 2010-02-22 10:05:25 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 02:03 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/ideharbourhelp.prg ! A rare-condition bug fix. Thanks Marco. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideharbourhelp.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor, I'm checking, a part is from an environment var named library_path which is set by GCC (E:\harbour\ld)set library_path LIBRARY_PATH=E:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5;E:/SVI LUPPO/GCC/V3.3.5/USR/lib/tcpipv4;E:/SVILUPPO/GCC/V3.3.5/USR/lib;D:\JAVA11\LIB; But it seems to be using some other path which I'm trying to figure out where it comes from. Maurilio. Viktor Szakáts wrote: > Nice. > > Now all the absolute paths to gcc lib locations need > to be sorted out. I can add support for $(HB_COMP_PATH_PUB) > variable for os2/gcc, but this is not enough, as the > relative paths also hold the gcc version number. Plus > the logic should be checked for each gcc version, as it > may change along the way. > > Brgds, > Viktor > > On 2010 Feb 22, at 10:47, Maurilio Longo wrote: > >> And here, in all of its beauty, the call to build harbour.dll >> >> :) >> >> Maurilio. >> >> >> -- >> __ >> | | | |__| Maurilio Longo >> |_|_|_|| farmaconsult s.r.l. >> >> >> ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org >> ! MAKE: make 3.81 D:\OS2\CMD.EXE >> ! HB_BIN_INSTALL: e:\harbour\bin >> ! HB_LIB_INSTALL: e:\harbour\lib >> ! HB_INC_INSTALL: e:\harbour\include >> ! HB_DOC_INSTALL: e:\harbour\doc >> ! HB_BUILD_SHARED: yes >> ! HB_BUILD_STRIP: all >> ! HB_HOST_PLAT: os2 (x86) HB_SHELL: os2 >> ! HB_PLATFORM: os2 (x86) (autodetected) >> ! HB_COMPILER: gcc >> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) >> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) >> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. >> ! Component: 'gpm' not supported on os2 platform >> ! Component: 'slang' not found. Configure with HB_WITH_SLANG. >> ! Component: 'curses' not supported on os2 platform >> ! Component: 'x11' not found. Configure with HB_WITH_X11. >> ! Component: 'wattcp/watt-32' not supported on os2 platform >> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR >> make[2]: `../../../../../lib/os2/gcc/hbcommon.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbnortl.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbpp.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbcplr.a' is up to date. >> gcc -L../../../../../lib/os2/gcc -o >> ..\..\..\..\..\bin\os2\gcc\harbour.exe harbour.o -lhbcplr -lhbpp -lhbnortl >> -lhbcommon -s >> >> 8< >> -o ..\..\..\..\..\bin\os2\gcc\harbour.exe -s >> E:/SVILUPPO/GCC/V3.3.5/USR/lib/crt0.o -L../../../../../lib/os2/gcc >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib >> -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> -LE:/SVILUPPO/GCC/V3.3.5/USR/lib >> -LE:/REPOSITORY/HARBOUR/src/main/obj/os2/gcc >> -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib >> -LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib harbour.o -lhbcplr -lhbpp -lhbnortl >> -lhbcommon -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 >> -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 >> -lgcc_so_d -lc_alias -lc_dll -los2 >> >8make[2]: >> `../../../../../lib/os2/gcc/hbvm.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbmainstd.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbmaindllh.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbvmmt.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbrtl.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/gtcgi.a' is up to date. >> ! 'gtcrs' library skipped (component not found) >> ! 'gtdos' library skipped (platform not supported) >> ! 'gtgui' library skipped (platform not supported) >> make[3]: `../../../../../../lib/os2/gcc/gtos2.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/gtpca.a' is up to date. >> ! 'gtsln' library skipped (component not found) >> make[3]: `../../../../../../lib/os2/gcc/gtstd.a' is up to date. >> ! 'gttrm' library skipped (platform or compiler not supported) >> ! 'gtwin' library skipped (platform not supported) >> ! 'gtwvt' library skipped (platform not supported) >> ! 'gtxwc' library skipped (component not found) >> make[2]: `../../../../../lib/os2/gcc/hbmacro.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbcpage.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hblang.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbrdd.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbnulrdd.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/rddntx.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/rddnsx.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/rddcdx.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/rddfpt.a' is up to date. >> make[3]: `../../../../../../lib
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor, but, a lot of references could be simplified, for example: ../../../../../src/common/obj/os2/gcc/expropt2.o all common objects are inside src/common/obj/os2/gcc an so they could be referenced as src/common/obj/os2/*.o If gcc does not expand them and leaves to ld this task than we should be ok! Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
On Mon, 22 Feb 2010, Xavi wrote: Hi Xavi, > Okay. Well..., If it's not possible know the type of adapter > (Ethernet, Token Ring, ...) on other OS not Windows. :( It's is possible. Just like many other things which still do not exists in MS-Windows and we will have to wait next 10 years until MS discover them and add some support for it in WinSOCK.X.Y.Z which will work correctly in version X.Y.Z + N. There is only one question: Why we should add such things? The fact that sth is possible on some platforms does not mean that it has to be implemented. > #include "hbsocket.ch" > proc main( noAlias ) > local iface > ? os(), version() > ? "interfaces:" > for each iface in hb_inetIfInfo( !empty( noAlias ), 0 ) >? "Family :", iface[HB_SOCKET_IFINFO_FAMILY] >? "Name .. :", iface[HB_SOCKET_IFINFO_NAME] >? "Flags . :", iface[HB_SOCKET_IFINFO_FLAGS] >? "Address ... :", iface[HB_SOCKET_IFINFO_ADDR] >? "Mask .. :", iface[HB_SOCKET_IFINFO_NETMASK] >? "Bradcast .. :", iface[HB_SOCKET_IFINFO_BROADCAST] >? "P2P :", iface[HB_SOCKET_IFINFO_P2PADDR] >? "MAC ... :", iface[HB_SOCKET_IFINFO_HWADDR] >? "Gateway ... :", iface[HB_SOCKET_IFINFO_GATEWAY] >? '---' > next > ? > Wait > return Why you added HB_SOCKET_IFINFO_GATEWAY? What programs do you plan to write which will need such information? How do you know that which gateway belongs to each IP address? It's possible that aliases uses different gateways (at least in normal systems). I do not see any code which tries to bind gateway addresses with IP addresses so HB_SOCKET_IFINFO_GATEWAY contains correct information only when the same gateway is used by all aliases. MS-Windows does not have interface names as other hosts. AFAIR windows ports of some *nix tools like ifconfing used IP address as interface name so I decided to use the same. You added code which replace this IP addres with "localhost" string for LOOPBACK interfaces. Why? Do you know that it's possible to have more then one LOOPBACK interface with different addresses? You created exception with socket initialization for single function only. This code should be removed. We may decide to add automatic socket initialization to hbsocket.c code in the future but in such case it will have to be global feature not hacks in each single function. Now we have automatic initialization for HB_INET*() PRG functions and here the problem should be fixed. It's enough to add: HB_INET_INITIALIZE(); to HB_INETIFINFO() before hb_socketGetIFaces(). I'll commit the fix in a while. Thank you very much for information about the problem. hb_arrayGetC() returns address to dynamically allocated memory block which should be freed by hb_itemFreeC(). Now this code causes memory leak. Is iphlpapi.dll loaded by application at startup and keep alive for whole application running time? If not then storing pointer to GetAdaptersInfo() in static variable seems to be a little bit risk because such address may change. BTW in which Windows version GetAdaptersInfo() was added? This code does not detect aliases. It has to be redesigned to eliminate them. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Hi Maurilio, > but, a lot of references could be simplified, for example: > > ../../../../../src/common/obj/os2/gcc/expropt2.o > > all common objects are inside src/common/obj/os2/gcc an so they could be > referenced as src/common/obj/os2/*.o > > If gcc does not expand them and leaves to ld this task than we should be ok! Referencing objects using wildcards is very error prone, and cannot be considered good practice. Build process just drops control over what's included and what's not. F.e. it only works reliably for clean builds. (Also, *.o picks everything, while we only need *_dyn. on some other platforms, so it's also not portable and generic solution) So I don't want to do such simplification, even if it's allowed by some tools. I still think the solution here is fixing OS/2 toolchain. Spending time to develop hacks to work around such 3rd party bugs is not very optimal. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13957] trunk/harbour
Hbide from rev. 13957 playing with Document Viewer Dock i set as Harbour installation root "/home/ubuntu/src/harbour" and i live the "doc folder prefix" empty pressing the green upper row i get this runtime error Unrecoverable error 6005: Exception SIGSEGV at address 0x5d Called from QT_QTREEWIDGET_SETCURRENTITEM(0) Called from QTREEWIDGET:SETCURRENTITEM(0) in ../../../TQTreeWidget.prg Called from IDEHARBOURHELP:EXECEVENT(428) in ideharbourhelp.prg Called from (b)IDEHARBOURHELP_INSTALLSIGNALS(336) in ideharbourhelp.prg Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(417) in hbide.prg Called from MAIN(110) in hbide.prg Thank you ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor, Viktor Szakáts wrote: > Referencing objects using wildcards is very error prone, > and cannot be considered good practice. Build process just > drops control over what's included and what's not. F.e. > it only works reliably for clean builds. (Also, *.o picks > everything, while we only need *_dyn. on some other > platforms, so it's also not portable and generic solution) > So I don't want to do such simplification, even if it's > allowed by some tools. > > I still think the solution here is fixing OS/2 toolchain. > Spending time to develop hacks to work around such 3rd > party bugs is not very optimal. > Sure, I agree with you, I'm just fearing it could take _a long_ time before the tool chain can be fixed, so I was looking at this as a work-around for the OS/2 platform only. Anyway, given we have the command line for ld we should be able to make it work even with full objects specification. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
Hi Przemek, > If not then storing pointer to GetAdaptersInfo() in static variable > seems to be a little bit risk because such address may change. > BTW in which Windows version GetAdaptersInfo() was added? The whole .dll is not available on my Win95 system, but it's there already on Win98. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
On Sat, Feb 20, 2010 at 6:07 PM, wrote: > Please use this code on different non MS-Windows platforms: > > proc main( noAlias ) > local iface > ? os(), version() > ? "interfaces:" > for each iface in hb_inetIfInfo( !empty( noAlias ), 0 ) > ? hb_valToExp( iface ) > next > ? > return > > and check if it returns correct information about available > interfaces. Many thanks, it works as expected under Ubuntu 10.04 i386 alpha status and Centos 5.4 i386. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Anyway, (E:\REPOSITORY\HARBOUR\src\dynlib\obj\os2\gcc)ld -Zdll @__dyn__.tmp this fails with the runtime symbols not found, so, ld supports @filename to list the needed .o files. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
> BTW in which Windows version GetAdaptersInfo() was added? It is missing from Win95 (and BCB 3.0) It exists in WinNT4.0 inside iphlpapi.dll (and in BCB 5.0 iphlpapi.h but is not documented in Win32 API that arrive with BCB 5.0) Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13952] trunk/harbour
Pritpal, your work is excellent! But it would be the case for this doc/writer feature being mounted on an application separately? I think the tool is very good, but would be much better if we could work with a maximized window and a toolbar specifically for this application ... I've been thinking and I think it would be much better, more productive (and less confusing) to separate it into two separate applications... least because they have different objectives. What do you think? Again congratulations, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Ok, this command ld -Zdll -s -o harbour.dll E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o -L../../../../../lib/os2/gcc -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib -LE:/Sviluppo/gcc/v3.3.5/usr/lib @__dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d builds harbour.dll without errors, now, it remains to be seen if the .dll works .) Maurilio. Maurilio Longo wrote: > Anyway, > > (E:\REPOSITORY\HARBOUR\src\dynlib\obj\os2\gcc)ld -Zdll @__dyn__.tmp > > this fails with the runtime symbols not found, so, ld supports @filename to > list the needed .o files. > > Maurilio. > > > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13952] trunk/harbour
Pritbal please consider. I agree with Renato I hope in something RAD functions/tools in hbide Congratulation. Thank you ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13952] trunk/harbour
Imo is right the idea having one exe Hbide is Good for read and modify all harbour source and read and modify also Documentation If you read source you can start documenting, and updating source When you modify documentation you require also search find in file in c\harbour and subdir and also you need basic editing capability I Think with future/possible a svn integration (like visual studio) we can easy upload harbour modification or modification to documentation Maj be that you think that is not same windows to be clear, docking windows require also same idea to be productive, ...in first time i think that must be only two, when you open one automatically close another... How manage Multiple important activity opened ? Think that the problem is Have different size 2010/2/22 Vailton Renato > Pritpal, your work is excellent! But it would be the case for this > doc/writer feature being mounted on an application separately? I think > the tool is very good, but would be much better if we could work with > a maximized window and a toolbar specifically for this application ... > I've been thinking and I think it would be much better, more > productive (and less confusing) to separate it into two separate > applications... least because they have different objectives. What do > you think? > > Again congratulations, > Vailton Renato > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Maurilio: >it seems it does not find os2.a and rtl c library. When we call ld.exe/emxomfld.exe directly perhaps is missing all environment values used by gcc settings >I was going to create a ld.exe which simply spits out what it received >from gcc so we can see what it needs :) >here it is my ld.exe while building ld.exe itself after substituing it >with itself :)) >(E:\harbour\ld)hbmk2 -st -shared ld.prg >hbmk2: Processing environment options: -mt -compiler=gcc -st and -mt ? [...] >my ld.exe is a simple >function main( ... ) > ? ... >return 0 >So, we can see that it points to a lot of libs, now let's see what >happens when it is called in building harbour.dll OK >And here, in all of its beauty, the call to build harbour.dll > >:) >gcc -shared -L../../../../../lib/os2/gcc -o >../../../../../bin/os2/gcc/harbour.dll @__dyn__.tmp __dyn__.def >-lsocket -s >8< >-Zdll -o ../../../../../bin/os2/gcc/harbour.dll -s >E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o -L../../../../../lib/os2/gcc >-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib >-LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >-LE:/SVILUPPO/GCC/V3.3.5/USR/lib >-LE:/REPOSITORY/HARBOUR/src/dynlib/obj/os2/gcc >-LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >-LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib >-LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib >-LE:/Sviluppo/gcc/v3.3.5/usr/lib >../../../../../src/common/obj/os2/gcc/expropt1.o [...] >../../../../../src/vm/obj/os2/gcc/runner.o >../../../../../src/vm/obj/os2/gcc/vm.o __dyn__.def -lsocket -lc_alias >-lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias >-lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias >-lc_dll -los2 >>8 You obtain same info as I reported before using -v switch in gcc. See next part of original message You can see detailed info in messages from: OS/2: harbourm.dll 4/10/09 07:28 AM >>>== At last gcc is expanding __dyn__.tmp generating a long expression I am intrigued with long expression reported as obtained with -v in gcc Recalling the parsed structure: --- emxomfld.exe -Zdll -o ../../../../../bin/os2/gcc/harbour.dll E:/usr/lib/dll0.obj -L../../../../../lib/os2/gcc -LE:/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/usr/lib/gcc-lib -LE:/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/usr/lib -LE:/harbour909f/harbour/source/dynlib/obj/os2/gcc -LE:/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/usr/i386-pc-os2-emx/lib -LE:/USR/i386-pc-os2-emx/lib -LE:/usr/lib -LE:/usr/lib ..\..\..\..\..\source\common\obj\os2\gcc\expropt1.obj [rest of .obj files list] ..\..\..\..\..\source\vm\obj\os2\gcc\vm.obj __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lend -- excluding "ld.exe" or "emxomfld.exe" rest are send to ld or emxomfld Is a long chain == What I see as differences with your and my results - You are using: gcc -shared ... -lsocket -s and I am using gcc -shared -Zomf... -lsocket -Zomf is explained by OMF type, but -s ? - In my case gcc add this list -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lend while in your case is: -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 Long chain of: [rest of .obj files list] is what surpass 32K limit, as found before and Knut explained >Ok, >this command >ld -Zdll -s -o harbour.dll E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o >-L../../../../../lib/os2/gcc >-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib >-LE:/Sviluppo/gcc/v3.3.5/usr/lib >@__dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc_so_d >-lc_alias >-lc_dll -los2 -lgcc_so_d >builds harbour.dll without errors, You are adding the rest of environment values used by gcc settings, as gcc does when it call ld.exe/emxomfld.exe It can work, but taking care of all values used in each compiler environment For example, for os2gcc442: - PATH_EMXPGCC=E:\usr CCENV=EMX BUILD_ENV=EMX BUILD_PLATFORM=OS2 DPATH=E:\usr\local442\lib;E:\usr\lib;E:\MPTN; ... PATH=E:\usr\local442\libexec\gcc\i386-pc-os2-emx\4.4.2;E:\usr\local442\bin;E:\usr\bin; ... C_INCLUDE_PATH=E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2/include;E:/usr/local442/include;E:/usr/include; CPLUS_INCLUDE_PATH=E:/usr/local442/include/c++/4.4.2;E:/usr/local442/include/c++/4.4.2/i386-pc-os2-emx;E:/usr/local442/include/c++/4.4.2/backward;E:/usr/local442/include;E:/usr/include; LIBRARY_PATH=E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2;E:/usr/local442/lib;E:/usr/lib; INFOPATH=E:/usr/local442/info;E:/usr/info; PROTODIR=E:/usr/include/c++/gen BEGINLIBPATH=E:\usr\local442\lib;E:\usr\lib; ---
[Harbour] Re: SF.net SVN: harbour-project:[13937] trunk/harbour
Lorenzo: Many thanks, it works as expected under Ubuntu 10.04 i386 alpha status and Centos 5.4 i386. Can you post output ? Just to compare with OS/2 output David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor, in this path -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 E:/SVILUPPO/GCC/V3.3.5/ is where I decided to put GCC on my system, while the last 3.3.5 in the path depends on GCC version and so it changes from release to release. So we have to parse LIBRARY_PATH to add -L options to ld command line, but it is not enough since we need an object, dll0.o, which is inside E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o which could be inferred from LIBRARY_PATH, but I don't know whether the new versions of GCC have it in the same position. This is something that has to be hard-coded inside gcc when used as dl.exe front end which should be extracted from it in some way. Best regards. Maurilio. Viktor Szakáts wrote: > Nice. > > Now all the absolute paths to gcc lib locations need > to be sorted out. I can add support for $(HB_COMP_PATH_PUB) > variable for os2/gcc, but this is not enough, as the > relative paths also hold the gcc version number. Plus > the logic should be checked for each gcc version, as it > may change along the way. > > Brgds, > Viktor > > On 2010 Feb 22, at 10:47, Maurilio Longo wrote: > >> And here, in all of its beauty, the call to build harbour.dll >> >> :) >> >> Maurilio. >> >> >> -- >> __ >> | | | |__| Maurilio Longo >> |_|_|_|| farmaconsult s.r.l. >> >> >> ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org >> ! MAKE: make 3.81 D:\OS2\CMD.EXE >> ! HB_BIN_INSTALL: e:\harbour\bin >> ! HB_LIB_INSTALL: e:\harbour\lib >> ! HB_INC_INSTALL: e:\harbour\include >> ! HB_DOC_INSTALL: e:\harbour\doc >> ! HB_BUILD_SHARED: yes >> ! HB_BUILD_STRIP: all >> ! HB_HOST_PLAT: os2 (x86) HB_SHELL: os2 >> ! HB_PLATFORM: os2 (x86) (autodetected) >> ! HB_COMPILER: gcc >> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) >> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) >> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. >> ! Component: 'gpm' not supported on os2 platform >> ! Component: 'slang' not found. Configure with HB_WITH_SLANG. >> ! Component: 'curses' not supported on os2 platform >> ! Component: 'x11' not found. Configure with HB_WITH_X11. >> ! Component: 'wattcp/watt-32' not supported on os2 platform >> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR >> make[2]: `../../../../../lib/os2/gcc/hbcommon.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbnortl.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbpp.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbcplr.a' is up to date. >> gcc -L../../../../../lib/os2/gcc -o >> ..\..\..\..\..\bin\os2\gcc\harbour.exe harbour.o -lhbcplr -lhbpp -lhbnortl >> -lhbcommon -s >> >> 8< >> -o ..\..\..\..\..\bin\os2\gcc\harbour.exe -s >> E:/SVILUPPO/GCC/V3.3.5/USR/lib/crt0.o -L../../../../../lib/os2/gcc >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib >> -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> -LE:/SVILUPPO/GCC/V3.3.5/USR/lib >> -LE:/REPOSITORY/HARBOUR/src/main/obj/os2/gcc >> -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib >> -LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib harbour.o -lhbcplr -lhbpp -lhbnortl >> -lhbcommon -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 >> -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 >> -lgcc_so_d -lc_alias -lc_dll -los2 >> >8make[2]: >> `../../../../../lib/os2/gcc/hbvm.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbmainstd.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbmaindllh.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbvmmt.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbrtl.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/gtcgi.a' is up to date. >> ! 'gtcrs' library skipped (component not found) >> ! 'gtdos' library skipped (platform not supported) >> ! 'gtgui' library skipped (platform not supported) >> make[3]: `../../../../../../lib/os2/gcc/gtos2.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/gtpca.a' is up to date. >> ! 'gtsln' library skipped (component not found) >> make[3]: `../../../../../../lib/os2/gcc/gtstd.a' is up to date. >> ! 'gttrm' library skipped (platform or compiler not supported) >> ! 'gtwin' library skipped (platform not supported) >> ! 'gtwvt' library skipped (platform not supported) >> ! 'gtxwc' library skipped (component not found) >> make[2]: `../../../../../lib/os2/gcc/hbmacro.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbcpage.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hblang.a' is up to date. >> make[2]: `../../../../../lib/os2/gcc/hbrdd.a' is up to date. >> make[3]: `../../../../../../lib/os2/gcc/hbnulrdd.a'
Re: [Harbour] Re: OS/2: Harbour 13945
Hi Maurilio, > in this path > > -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 > > E:/SVILUPPO/GCC/V3.3.5/ is where I decided to put GCC on my system, while the > last 3.3.5 in the path depends on GCC version and so it changes from release > to release. Is '/gcc/3.3.5/' a mandatory element of the base dir, or local user preference? I mean, may I simple install it to 'E:/os2stuff/gcc/' instead of 'E:/Sviluppo/gcc/v3.3.5/'? > So we have to parse LIBRARY_PATH to add -L options to ld command line, but it > is not enough since we need an object, dll0.o, which is inside > > E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o > > which could be inferred from LIBRARY_PATH, but I don't know whether the new > versions of GCC have it in the same position. That's a question. Plus whether it's in the same place for gccomf vs plain gcc. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: hbqt, advances
I continued making tests with Harbour hbqt and Qt451GA for OS/2 As I was getting many errors, I opened a "ticket" in svn.netlabs.org/qt4 With the fast and excelent help of: - Dmitry A. Kuminov (development) - Silvan Scherrer (management) Harbour for OS/2 is very close to have support of hbqt contrib Just remain eleven .cpp files with problems I need help on three areas: 1) Maurilio: to check changes in hbdefs.h /* 28/03/2000 - maurilio.lo...@libero.it The same holds true when using GCC under OS/2 */ /* xx/02/2010 - whoe...@there.is Include all OS/2 API definitions to make sure other involved parties (such as Qt for OS/2) will get everything they want */ #define OS2EMX_PLAIN_CHAR #define INCL_BASE #define INCL_PM #include #undef INT #undef UINT #define HB_DONT_DEFINE_BASIC_TYPES 2) Pritpal: 1. Add #ifndef QT_NO_PRINTER / #endif around the parts in the source code that use printing classes (QAbstractPrintDialog, QPageSetupDialog etc.) This btw will let it build on all platforms that don't provide printing support for some reason, not only OS/2. 3) Pritpal: #ifndef QT_NO_ACCESSIBILITY / #endif around the places that complain about missing accessibility methods. Below are text with relevant facts of tests, info, responses, ... Qt for OS/2 (4.6.1) will be available soon, with printer support using CUPS README.OS2 file contain this section, useful for management of unavailable classes > CURRENT LIMITATIONS [...] 4. In order to let Qt correctly detect the regional settings and choose the right language for translating the user interface, the LANG environment variable must be set. The format is set LANG=ll_CC where is the language code and is the country code (refer to wikipedia.org to find correct letters for your langage and country if you do not know them). Note that the optional encoding part of the LANG specification is ignored by Qt for OS/2 since 4.5.1 Beta 5 because it now detects the encoding automatically based on the system OS/2 settings. Later, the correct language will be detected from the system settings so that specifying LANG will be not necessary at all. [...] 8. The followign classes are not available due to their rare usage or low importance on the OS/2 platform: QSharedMemory, QSystemSemaphore, QInputContext, QAccessible. The following macros are defined to indicate this: QT_NO_SYSTEMSEMAPHORE, QT_NO_SHAREDMEMORY, QT_NO_IM, QT_NO_ACCESSIBILITY. Applications normally use them to guard the relevant parts of code so they should still build. << David Macias I installed Qt451GA using .wpi files from Netlabs Using "Qt4 Command Prompt", setting os2gcc442 environment and Harbour environment as usual In first try to build Harbour-hbqt it fail with this error: E:\ecs\system\qt4\include/QtCore/qt_os2.h:59:33: error: API_FPU_CW_Wrappers.h: No such file or directory Searching for API_FPU_CW_Wrappers.h it does not exist anywhere in e:\ecs\system\qt4\include\ directories Looking for API_FPU_CW_Wrappers.h it exist in: E:\ecs\system\qt4\mkspecs\os2-g++ E:\ecs\system\qt4\mkspecs\default with same date and content: 17/12/09 3:22a 145,271 0 a--- API_FPU_CW_Wrappers.h Copying API_FPU_CW_Wrappers.h to e:\ecs\system\qt4\include\ and trying again build of Harbour-hbqt many errors are raised from API_FPU_CW_Wrappers.h and then GPF with "Killed by SIGSEGV" So something are wrong in API_FPU_CW_Wrappers.h reference, content and use under OS/2 [...] Dmitry response: > As far as I can see, the project doesn't use qmake. For this reason, the include path E:\ecs\system\qt4\mkspecs\default (or E:\ecs\system\qt4\mkspecs\os2-g++ which is the same in this case) is not passed to the compiler. Adding it to the list of include directories for the compier should fix the problem for you. Please try and report back. For the second case, it's the wrong include order -- a typical problem for the OS/2 environment caused by the way the os2.h file (which is a central access point to the OS/2 APIs) is organized. In your case, it seems that os2.h is manually included from either hbqt_hbqmainwindow.cpp or hbqt_hbqmainwindow.h (or from another file they include) before Qt4 headers are included. Such an order is not supported and should not take place -- Qt includes must go first. Also, it's not clear why os2.h is included manually in a Qt source file in the first place: in theory, this should be never needed. If you give me more details on this, I will be able to suggest you the best solution. P.S. SIGSEGV is probably due to too many errors (e.g. maybe a bug of the GCC4 port) and is not related to Qt4. << We use GNU make Using: set C_INCLUDE_PATH=E:\ecs\system\qt4\mkspecs\default;%C_INCLUDE_PATH% set CPLUS_INCLUDE_PATH=E:\ecs\system\qt4\mkspecs\default;%CPLUS_INCLUDE_
[Harbour] OS/2: hbqt, advances
I continued making tests with Harbour hbqt and Qt451GA for OS/2 As I was getting many errors, I opened a "ticket" in svn.netlabs.org/qt4 With the fast and excelent help of: - Dmitry A. Kuminov (development) - Silvan Scherrer (management) Harbour for OS/2 is very close to have support of hbqt contrib Just remain eleven .cpp files with problems I need help on three areas: 1) Maurilio: to check changes in hbdefs.h /* 28/03/2000 - maurilio.lo...@libero.it The same holds true when using GCC under OS/2 */ /* xx/02/2010 - whoe...@there.is Include all OS/2 API definitions to make sure other involved parties (such as Qt for OS/2) will get everything they want */ #define OS2EMX_PLAIN_CHAR #define INCL_BASE #define INCL_PM #include #undef INT #undef UINT #define HB_DONT_DEFINE_BASIC_TYPES 2) Pritpal: 1. Add #ifndef QT_NO_PRINTER / #endif around the parts in the source code that use printing classes (QAbstractPrintDialog, QPageSetupDialog etc.) This btw will let it build on all platforms that don't provide printing support for some reason, not only OS/2. 3) Pritpal: #ifndef QT_NO_ACCESSIBILITY / #endif around the places that complain about missing accessibility methods. Below are text with relevant facts of tests, info, responses, ... Qt for OS/2 (4.6.1) will be available soon, with printer support using CUPS README.OS2 file contain this section, useful for management of unavailable classes CURRENT LIMITATIONS [...] 4. In order to let Qt correctly detect the regional settings and choose the right language for translating the user interface, the LANG environment variable must be set. The format is set LANG=ll_CC where is the language code and is the country code (refer to wikipedia.org to find correct letters for your langage and country if you do not know them). Note that the optional encoding part of the LANG specification is ignored by Qt for OS/2 since 4.5.1 Beta 5 because it now detects the encoding automatically based on the system OS/2 settings. Later, the correct language will be detected from the system settings so that specifying LANG will be not necessary at all. [...] 8. The followign classes are not available due to their rare usage or low importance on the OS/2 platform: QSharedMemory, QSystemSemaphore, QInputContext, QAccessible. The following macros are defined to indicate this: QT_NO_SYSTEMSEMAPHORE, QT_NO_SHAREDMEMORY, QT_NO_IM, QT_NO_ACCESSIBILITY. Applications normally use them to guard the relevant parts of code so they should still build. << David Macias I installed Qt451GA using .wpi files from Netlabs Using "Qt4 Command Prompt", setting os2gcc442 environment and Harbour environment as usual In first try to build Harbour-hbqt it fail with this error: E:\ecs\system\qt4\include/QtCore/qt_os2.h:59:33: error: API_FPU_CW_Wrappers.h: No such file or directory Searching for API_FPU_CW_Wrappers.h it does not exist anywhere in e:\ecs\system\qt4\include\ directories Looking for API_FPU_CW_Wrappers.h it exist in: E:\ecs\system\qt4\mkspecs\os2-g++ E:\ecs\system\qt4\mkspecs\default with same date and content: 17/12/09 3:22a 145,271 0 a--- API_FPU_CW_Wrappers.h Copying API_FPU_CW_Wrappers.h to e:\ecs\system\qt4\include\ and trying again build of Harbour-hbqt many errors are raised from API_FPU_CW_Wrappers.h and then GPF with "Killed by SIGSEGV" So something are wrong in API_FPU_CW_Wrappers.h reference, content and use under OS/2 [...] Dmitry response: As far as I can see, the project doesn't use qmake. For this reason, the include path E:\ecs\system\qt4\mkspecs\default (or E:\ecs\system\qt4\mkspecs\os2-g++ which is the same in this case) is not passed to the compiler. Adding it to the list of include directories for the compier should fix the problem for you. Please try and report back. For the second case, it's the wrong include order -- a typical problem for the OS/2 environment caused by the way the os2.h file (which is a central access point to the OS/2 APIs) is organized. In your case, it seems that os2.h is manually included from either hbqt_hbqmainwindow.cpp or hbqt_hbqmainwindow.h (or from another file they include) before Qt4 headers are included. Such an order is not supported and should not take place -- Qt includes must go first. Also, it's not clear why os2.h is included manually in a Qt source file in the first place: in theory, this should be never needed. If you give me more details on this, I will be able to suggest you the best solution. P.S. SIGSEGV is probably due to too many errors (e.g. maybe a bug of the GCC4 port) and is not related to Qt4. << We use GNU make Using: set C_INCLUDE_PATH=E:\ecs\system\qt4\mkspecs\default;%C_INCLUDE_PATH% set CPLUS_INCLUDE_PATH=E:\ecs\system\qt4\mkspecs\default;%CPLUS_INCLUDE_PATH% then API_FPU_CW_Wrappers.h missing has gone,
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor, Viktor Szakáts wrote: > Hi Maurilio, > >> in this path >> >> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >> >> E:/SVILUPPO/GCC/V3.3.5/ is where I decided to put GCC on my system, while the >> last 3.3.5 in the path depends on GCC version and so it changes from release >> to release. > > Is '/gcc/3.3.5/' a mandatory element of the base dir, or > local user preference? I mean, may I simple install it > to 'E:/os2stuff/gcc/' instead of 'E:/Sviluppo/gcc/v3.3.5/'? > Sure. >> So we have to parse LIBRARY_PATH to add -L options to ld command line, but it >> is not enough since we need an object, dll0.o, which is inside >> >> E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o >> >> which could be inferred from LIBRARY_PATH, but I don't know whether the new >> versions of GCC have it in the same position. > > That's a question. Plus whether it's in the same place for > gccomf vs plain gcc. > I'd say yes, the OMF version has an .obj extension. dir \*dll0.* /s The volume label in drive E is Dati. The Volume Serial Number is 812E:D5C2. Directory of E:\Sviluppo\gcc\v3.3.5\usr\lib 11/06/07 22:52 1.955 0 a--- dll0.o 11/06/07 22:52 2.797 0 a--- dll0.obj 2 file(s) 4.752 bytes used Regards. Maurilio. > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: hbqt, advances
Sorry for double post Seamonkey report failure to send, does not put message on "Sent" folder, but message is delivered (?) David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: hbqt, advances
Hi, > I need help on three areas: > > 1) Maurilio: to check changes in hbdefs.h > /* 28/03/2000 - maurilio.lo...@libero.it > The same holds true when using GCC under OS/2 > */ > /* xx/02/2010 - whoe...@there.is > Include all OS/2 API definitions to make sure other involved parties > (such as Qt for OS/2) will get everything they want > */ > #define OS2EMX_PLAIN_CHAR > #define INCL_BASE > #define INCL_PM > #include > #undef INT > #undef UINT > #define HB_DONT_DEFINE_BASIC_TYPES To give everything that's needed for HBQT, these must be put inside hbqt.h header, not hbdefs.h. [ Including everything in central header, just to satisfy some contribs, or some specific core parts is simple, but wrong solution, and quite complicated to clean later. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: hbqt, advances
BTW, seeing hbdefs.h. Current method for OS/2 is wrong, and should be fixed. should only be included when legacy types are enabled. This means that has to be manually #included in every source file where it's currently missing from, along with proper INCL_ macros needed in each specific source file. I'll fix this, but it may need more passes of fixes to get it completely clean. Brgds, Viktor On 2010 Feb 22, at 13:50, Viktor Szakáts wrote: > Hi, > >> I need help on three areas: >> >> 1) Maurilio: to check changes in hbdefs.h >> /* 28/03/2000 - maurilio.lo...@libero.it >> The same holds true when using GCC under OS/2 >> */ >> /* xx/02/2010 - whoe...@there.is >> Include all OS/2 API definitions to make sure other involved parties >> (such as Qt for OS/2) will get everything they want >> */ >> #define OS2EMX_PLAIN_CHAR >> #define INCL_BASE >> #define INCL_PM >> #include >> #undef INT >> #undef UINT >> #define HB_DONT_DEFINE_BASIC_TYPES > > To give everything that's needed for HBQT, > these must be put inside hbqt.h header, not > hbdefs.h. > > [ Including everything in central header, > just to satisfy some contribs, or some > specific core parts is simple, but wrong > solution, and quite complicated to clean > later. ] > > Brgds, > Viktor > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: hbqt, advances
David, David Arturo Macias Corona wrote: > > 1) Maurilio: to check changes in hbdefs.h >/* 28/03/2000 - maurilio.lo...@libero.it > The same holds true when using GCC under OS/2 >*/ >/* xx/02/2010 - whoe...@there.is > Include all OS/2 API definitions to make sure other involved parties > (such as Qt for OS/2) will get everything they want >*/ >#define OS2EMX_PLAIN_CHAR >#define INCL_BASE >#define INCL_PM >#include >#undef INT >#undef UINT >#define HB_DONT_DEFINE_BASIC_TYPES > This takes in all #defines related to PM (OS/2 GUI), it should pose no harm, just a slower building (maybe even not noticeable). But it would be better, given that qt is a contrib, have an include file at the top of the qt tree which does just this or at least try to see if it is enough to get it going. Maurilio. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
>>> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 >>> >>> E:/SVILUPPO/GCC/V3.3.5/ is where I decided to put GCC on my system, while >>> the >>> last 3.3.5 in the path depends on GCC version and so it changes from release >>> to release. >> >> Is '/gcc/3.3.5/' a mandatory element of the base dir, or >> local user preference? I mean, may I simple install it >> to 'E:/os2stuff/gcc/' instead of 'E:/Sviluppo/gcc/v3.3.5/'? >> > Sure. This means we can't use base path to get version information needed to form paths for ld.exe. To me it's unclear how to make this automatic or elegant. I think the bug should be reported to GCC maintainers, to get it fixed ASAP. >>> So we have to parse LIBRARY_PATH to add -L options to ld command line, but >>> it >>> is not enough since we need an object, dll0.o, which is inside >>> >>> E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o >>> >>> which could be inferred from LIBRARY_PATH, but I don't know whether the new >>> versions of GCC have it in the same position. >> >> That's a question. Plus whether it's in the same place for >> gccomf vs plain gcc. >> > I'd say yes, the OMF version has an .obj extension. > > dir \*dll0.* /s > > The volume label in drive E is Dati. > The Volume Serial Number is 812E:D5C2. > > Directory of E:\Sviluppo\gcc\v3.3.5\usr\lib > > 11/06/07 22:52 1.955 0 a--- dll0.o > 11/06/07 22:52 2.797 0 a--- dll0.obj >2 file(s) 4.752 bytes used Okay. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: hbqt, advances
Viktor, you need it also when you call some Dos() APIs to have the function prototype. Maurilio. Viktor Szakáts wrote: > BTW, seeing hbdefs.h. Current method for OS/2 is wrong, > and should be fixed. > > should only be included when legacy types are > enabled. This means that has to be manually > #included in every source file where it's currently > missing from, along with proper INCL_ macros needed > in each specific source file. > > I'll fix this, but it may need more passes of fixes > to get it completely clean. > > Brgds, > Viktor > > On 2010 Feb 22, at 13:50, Viktor Szakáts wrote: > >> Hi, >> >>> I need help on three areas: >>> >>> 1) Maurilio: to check changes in hbdefs.h >>> /* 28/03/2000 - maurilio.lo...@libero.it >>> The same holds true when using GCC under OS/2 >>> */ >>> /* xx/02/2010 - whoe...@there.is >>> Include all OS/2 API definitions to make sure other involved parties >>> (such as Qt for OS/2) will get everything they want >>> */ >>> #define OS2EMX_PLAIN_CHAR >>> #define INCL_BASE >>> #define INCL_PM >>> #include >>> #undef INT >>> #undef UINT >>> #define HB_DONT_DEFINE_BASIC_TYPES >> To give everything that's needed for HBQT, >> these must be put inside hbqt.h header, not >> hbdefs.h. >> >> [ Including everything in central header, >> just to satisfy some contribs, or some >> specific core parts is simple, but wrong >> solution, and quite complicated to clean >> later. ] >> >> Brgds, >> Viktor >> > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Switch to detect undeclared vars being used
Viktor, yes. Maurilio. Viktor Szakáts wrote: > Hi Maurilio, > > On 2010 Feb 22, at 09:02, Maurilio Longo wrote: > >> Viktor, >> >> one thing I'd like to have is the ability of the compiler to spot iVars like >> it does variables, I mean unused, not declared and so on, while it now simply >> ignores all of them and you get an error when executing such code. > > By 'iVars', you means object vars? > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: -DTCPV40HDRS
In tests with Harbour hbqt and Qt451GA for OS/2 raised the question of -DTCPV40HDRS Perhaps is time to exclude -DTCPV40HDRS ? I am using it in official builds See info below David Macias Dmitry response: And BTW, is there any specific reason for -DTCPV40HDRS? This will cause gcc to use the outdated TCP stack (which is 16-bit AFAIR) instead of the more modern 32-bit stack used by Qt. I heard that these stacks are not compatible and won't work together (though I don't know all the details). << In Harbour project Maurilio Longo is our OS/2 expert and he explained us years ago that we must build Harbour with -DTCPV40HDRS in order to be used in old OS/2 and new eCS If this case may have problem with Qt I can inform it in Harbour project. Just tell me :-) [...] Dmitry response: > Okay, I had a small discussion on this topic with other OS/2 people and this is what I found. The only benefit of the 16-bit stack (that is used by Innotek GCC/kLIBC when you use -DTCPV40HDRS) comparing to the 32-bit stack (used otherwise) that the former is available on Warp3 while the latter is not (32 bit is also not available on Warp4 by default but it is easily solvable by installing a free Fixpak on it). So unless you really want to support Warp3 you can completely drop this define. Next, both stacks can be probably used in parallel within the same process (never checked that) but they will for sure not be able to exchange sockets. And another important thing that Qt is bound to the 32-bit stack, so even if your application using two different stacks will eventually work, it will not load on a system with no 32-bit stack installed anyway (due to the Qt dependency). So keep that in mind. << It mean that Warp 3 support is excluded in your Qt4 development ? Dmitry response: > Yes. Neither Qt3 nor Qt4 officially supports Warp3. And there are no current plans to provide such support. << ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: hbqt, advances
> Viktor, > > you need it also when you call some Dos() APIs to have the function > prototype. I know, but in every such case, it should be included on per-source file basis. Similar to how we do it now for all other OSes. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor Szakáts wrote: > This means we can't use base path to get version > information needed to form paths for ld.exe. > No, we should split LIBRARY_PATH and put every piece of it into a -L statement for ld.exe and, if in one of those paths there is dll0.o (or .obj for omf) pass it to ld to have it include it in the building. > To me it's unclear how to make this automatic or > elegant. > > I think the bug should be reported to GCC maintainers, > to get it fixed ASAP. > I'll try to write to the current porter and see if he can fix it. David, did you already reported this issue to Paul Smedley? Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Switch to detect undeclared vars being used
You're right, this would be an absolutely useful feature. For me it's actually a show stopper to ever create any OOP code in Harbour. It's just too easy to mistype something and only get to know about it by live testing complete code flow. Compiler-level solution doesn't seem to be easy though. Brgds, Viktor On 2010 Feb 22, at 14:01, Maurilio Longo wrote: > Viktor, > > yes. > > Maurilio. > > Viktor Szakáts wrote: >> Hi Maurilio, >> >> On 2010 Feb 22, at 09:02, Maurilio Longo wrote: >> >>> Viktor, >>> >>> one thing I'd like to have is the ability of the compiler to spot iVars like >>> it does variables, I mean unused, not declared and so on, while it now >>> simply >>> ignores all of them and you get an error when executing such code. >> >> By 'iVars', you means object vars? >> >> Brgds, >> Viktor >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > > -- > __ > | | | |__| Maurilio Longo > |_|_|_|| farmaconsult s.r.l. > > > ___ > 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
Re: [Harbour] OS/2: -DTCPV40HDRS
David, do you still use warp 3? If not, we can remove it :D Jokes apart, we can decide that warp3 is not supported when using Qt or all together. I don't really know who is using harbour on OS/2 so I put it in to stay on the safe side. Maurilio. David Arturo Macias Corona wrote: > In tests with Harbour hbqt and Qt451GA for OS/2 raised the question of > -DTCPV40HDRS > > Perhaps is time to exclude -DTCPV40HDRS ? > I am using it in official builds > > See info below > > David Macias > > > Dmitry response: >> > And BTW, is there any specific reason for -DTCPV40HDRS? This will cause > gcc to use the outdated TCP stack (which is 16-bit AFAIR) instead of the > more modern 32-bit stack used by Qt. I heard that these stacks are not > compatible and won't work together (though I don't know all the details). > << > > > In Harbour project Maurilio Longo is our OS/2 expert and he explained us > years ago that we must build Harbour with -DTCPV40HDRS in order to be > used in old OS/2 and new eCS > If this case may have problem with Qt I can inform it in Harbour > project. Just tell me :-) > [...] > > > Dmitry response: >> > Okay, I had a small discussion on this topic with other OS/2 people and > this is what I found. The only benefit of the 16-bit stack (that is used > by Innotek GCC/kLIBC when you use -DTCPV40HDRS) comparing to the 32-bit > stack (used otherwise) that the former is available on Warp3 while the > latter is not (32 bit is also not available on Warp4 by default but it > is easily solvable by installing a free Fixpak on it). So unless you > really want to support Warp3 you can completely drop this define. > > Next, both stacks can be probably used in parallel within the same > process (never checked that) but they will for sure not be able to > exchange sockets. > > And another important thing that Qt is bound to the 32-bit stack, so > even if your application using two different stacks will eventually > work, it will not load on a system with no 32-bit stack installed anyway > (due to the Qt dependency). So keep that in mind. > << > > > It mean that Warp 3 support is excluded in your Qt4 development ? > > Dmitry response: >> > Yes. Neither Qt3 nor Qt4 officially supports Warp3. And there are no > current plans to provide such support. > << > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: hbqt, advances
Viktor, Maurilio: [Viktor] >To give everything that's needed for HBQT, >these must be put inside hbqt.h header, not >hbdefs.h. >[ Including everything in central header, >just to satisfy some contribs, or some >specific core parts is simple, but wrong >solution, and quite complicated to clean >later. ] [Viktor] >BTW, seeing hbdefs.h. Current method for OS/2 is wrong, >and should be fixed. > should only be included when legacy types are >enabled. This means that has to be manually >#included in every source file where it's currently >missing from, along with proper INCL_ macros needed >in each specific source file. >I'll fix this, but it may need more passes of fixes >to get it completely clean. [Maurilio] >This takes in all #defines related to PM (OS/2 GUI), it should pose no >harm, just a slower building (maybe even not noticeable). >But it would be better, given that qt is a contrib, have an include >file at the top of the qt tree which does just this or at least try to >see if it is enough to get it going. [Maurilio] >you need it also when you call some Dos() APIs to have the function > prototype. [Viktor] >I know, but in every such case, it should be >included on per-source file basis. Similar to >how we do it now for all other OSes. Harbour for OS/2 has been using: #define INCL_TYPES #define INCL_DOSEXCEPTIONS/* DOS exception values */ #define INCL_ERRORS /* DOS error values */ #define INCL_LONGLONG /* include native compiler LONGLONG definition */ #include #undef INT #undef UINT #define HB_DONT_DEFINE_BASIC_TYPES and proposed change is: #define OS2EMX_PLAIN_CHAR #define INCL_BASE #define INCL_PM #include #undef INT #undef UINT #define HB_DONT_DEFINE_BASIC_TYPES I do not know if old or new way are right, so I requested to Maurilio to check it Viktor, I suggest do not apply any changes until agreement Maurilio, do you have the whole picture ? Do not forget this info: (*) The thing with os2.h is that you have to specify what parts of the API you want before including it (using the #define INCL_xxx directives). If you do it once, all subsequent attempts to include os2.h again (probably with a different set of INCL_xxx defines) will be ignored by the compiler because os2.h contains a protection code that allows to include its contents only once per every compilation unit (.cpp file). Therefore, if your set of INCL_xxx doesn't drag in APIs needed by some other parties involved in the compilation process there is nothing these parties can do. BTW, if you don't want to toss the Qt includes around in all sources, there is one alternative solution. Just add the following to hbdefs.h right before the line where os2.h is included: #define OS2EMX_PLAIN_CHAR #define INCL_BASE #define INCL_PM This will make sure that os2.h will drag in all the APIs it has so every party will be eventually happy. David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Hi, >> This means we can't use base path to get version >> information needed to form paths for ld.exe. >> > No, we should split LIBRARY_PATH and put every piece of it into a -L statement > for ld.exe and, if in one of those paths there is dll0.o (or .obj for omf) > pass it to ld to have it include it in the building. Who/what is setting LIBRARY_PATH? Should it be set by user, or is it set by some of the GCC tools in GCC toolchain? >> To me it's unclear how to make this automatic or >> elegant. >> >> I think the bug should be reported to GCC maintainers, >> to get it fixed ASAP. >> > I'll try to write to the current porter and see if he can fix it. > > David, did you already reported this issue to Paul Smedley? Thank you. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Macro within codeblock ??
Hi Harbour developers,
I use macro within codeblock for years with Xbase++as follow:
cFAction := FIELD->FNCNAME
bAction := {|| &cFAction() }
If isfunction( cFAction )
oXbp:ItemSelected := bAction
Endif
However, Harbour does not support macro within codeblock ...
Hope someone can give me any solution on this topic ...
Shum
--
View this message in context:
http://n2.nabble.com/Macro-within-codeblock-tp4611984p4611984.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: hbqt, advances
> and proposed change is:
>
>#define OS2EMX_PLAIN_CHAR
>#define INCL_BASE
>#define INCL_PM
>#include
>#undef INT
>#undef UINT
>#define HB_DONT_DEFINE_BASIC_TYPES
>
>
> I do not know if old or new way are right, so I requested to Maurilio to
> check it
> Viktor, I suggest do not apply any changes until agreement
> Maurilio, do you have the whole picture ?
Sorry, I've already started to clean it, and will
commit it soon.
This is not a QT specific matter, but generic
Harbour problem. QT specific part needs to be
fixed inside HBQT header hbqt.h:
---
#define OS2EMX_PLAIN_CHAR
#define INCL_BASE
#define INCL_PM
{#include Harbour headers}
#if defined( HB_OS_OS2 )
# include
#endif
---
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor Szakáts wrote: > Who/what is setting LIBRARY_PATH? Should it be set by user, > or is it set by some of the GCC tools in GCC toolchain? > The user/installer when it installs the compiler and its tool-chain, so it has to be present, otherwise you cannot compile even a simple helloworld.c. >>> I think the bug should be reported to GCC maintainers, >>> to get it fixed ASAP. >>> >> I'll try to write to the current porter and see if he can fix it. >> >> David, did you already reported this issue to Paul Smedley? Anyway, Viktor, if we can find a way to do that parsing, it would instantly fix _every_ version out there without forcing all of us (OS/2 users left :)) to upgrade to an instable GCC version. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Maurilio: >I'll try to write to the current porter and see if he can fix it. >David, did you already reported this issue to Paul Smedley? 1) I sent report to many well-known people on OS/2 (Knut, Paul Smedley, Andreas, Sander, Ulrich) so all of them know this problem 2) I reported Knut response to Harbour group See message OS/2: Harbour 13841 12/02/10 08:57 AM Knut send same response to all, so they know response 3) I posted a ticket in svn.netlabs.org/libc 4) I opened an account in mantis.smedley.info, but response to confirm account delayed to much and I found it in spam folder 5) I have not posted ticket in mantis yet If you contact Paul you can recall him for my original message, and if you post ticket in mantis, you can use same content I used in netlabs Content are below What I see is: change to os2gcc will be available in future releases, so maybe only for os2gcc442 and greater and not for os2gcc335. It will force you to change your os2gcc compiler Cons: You need to make adjustments to your environments/systems Pros: You will be carried to present :-) Availability of next os2gcc release depend of Paul and his plans David Macias Ticket content In Harbour for OS/2 development ( www.harbour-project.org ) we face from long time a problem using os2gcc compilers when we try to build some .dll files Tracing I found an now famous 32 Kb limit: Somewhere gcc is using 32 Kb limit for our case gcc --> emxomfld.exe ( ld.exe ) ( or is OS/2 limit ? :-) ) Below are first quick and clear Knut St. Osmundsen response Thanks, David Macias Yes, this is an OS/2 limitation. The usual workaround is to pass the arguments in a response file (emxomfld @filename.rsp). Without checking all the relevant code, I'm pretty sure that the compiler/linker driver (gcc) will not create a response file when invoking sub programs like as, ld or emxomfld. The easiest way to hack it into doing this would be to change pexecute() in libiberty/pexecute.c to create a response file for arguments exceeding, say, 24 KB. http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/gcc/libiberty/pexecute.c#L803 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13958] trunk/harbour
Revision: 13958 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13958&view=rev Author: vszakats Date: 2010-02-22 13:45:07 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 14:43 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/extrap.c * src/vm/dynlibhb.c * src/common/hbgete.c * src/common/hbffind.c * src/common/hbver.c * src/rtl/filesys.c * src/rtl/diskspac.c * src/rtl/gtos2/gtos2.c * src/rtl/cputime.c * src/rtl/disksphb.c * include/hbthread.h * contrib/hbmzip/hbmzip.c ! Fixed to setup all OS/2 INCL_* constants and to #include os2.h by themselves, and not to rely on Harbour headers to do this job for them. ; TODO: Do the same for dos.h. * doc/hdr_tpl.txt - Deleted local changelog. ! Fixes to .prg function docs + Update copyright year to 2010. + Added fact that $SEEALSO$ should be comma separated. + Added .c function example (far from perfect) * examples/hbdoc2/tmplates.prg * doc/hdr_tpl.txt + Added $VERSION$ tag. (pls update HBIDE. We haven't finalized the format yet, to it's little bit premature to create new and new parsers/generators for it yet) * include/hbdefs.h ! Fixed to not unconditionally include OS/2 headers with an arbitrary selection of INCL_ macros. Now OS/2 headers will only be included if legacy types are requested (off by default), and no INCL_ macros are defined. This latter change may affect 3rd party code written for OS/2, so I'm marking it INCOMPATIBLE. * contrib/hbqt/generator/hbqtgen.prg * contrib/hbqt/hbqt.h * Changed to #include hbapi.h from hbqt.h. It needs it, so this is the clean way. Changed generator to leave out hbapi.h from each source file and refer to hbqt.h only. (untested) + Added logic to #include OS/2 headers with some INCL_ macros defined, to make QT on OS/2 happy. (copied them from the dev. list) ; TODO: Regenerate HBQT sources. * utils/hbtest/hbtest.prg ! Cleaned old problem reported by Chen. It seems like a feature which was never finished, and it's not even hugely needed, so I deleted it. * config/global.mk + Will now provide HB_COMP_PATH_PUB value for os2-gcc, os2-gccomf compilers. This value can be used to manually form ld.exe command line. (NOTE: This may be deleted in the future, when sorting out line-length limit problems for these compilers. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/global.mk trunk/harbour/contrib/hbmzip/hbmzip.c trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/doc/hdr_tpl.txt trunk/harbour/examples/hbdoc2/tmplates.prg trunk/harbour/include/hbdefs.h trunk/harbour/include/hbthread.h trunk/harbour/src/common/hbffind.c trunk/harbour/src/common/hbgete.c trunk/harbour/src/common/hbver.c trunk/harbour/src/rtl/cputime.c trunk/harbour/src/rtl/diskspac.c trunk/harbour/src/rtl/disksphb.c trunk/harbour/src/rtl/filesys.c trunk/harbour/src/rtl/gtos2/gtos2.c trunk/harbour/src/vm/dynlibhb.c trunk/harbour/src/vm/extrap.c trunk/harbour/utils/hbtest/hbtest.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
> The user/installer when it installs the compiler and its tool-chain, so it has > to be present, otherwise you cannot compile even a simple helloworld.c. Sorry if I missed it, but can you paste here a living example for what value it's actually set to? I'd also like to include it in INSTALL, since it's apparently missing. >>> David, did you already reported this issue to Paul Smedley? > > Anyway, Viktor, if we can find a way to do that parsing, it would instantly > fix _every_ version out there without forcing all of us (OS/2 users left :)) > to upgrade to an instable GCC version. If possible to do, fine for me. I've just posted a little change which helps the case already: $(HB_COMP_PATH_PUB) which returns the directory where gcc.exe is residing in. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] dos/watcom: warnings in hbsocket.c
Hi, ..\..\..\hbsocket.c(3020): Warning! W102: Type mismatch (warning) ..\..\..\hbsocket.c(3020): Note! N2003: source conversion type is 'char *' ..\..\..\hbsocket.c(3020): Note! N2004: target conversion type is 'unsigned long ' ..\..\..\hbsocket.c(3026): Warning! W131: No prototype found for function 'ioctl' ..\..\..\hbsocket.c(3028): Warning! W102: Type mismatch (warning) ..\..\..\hbsocket.c(3028): Note! N2003: source conversion type is 'unsigned long ' ..\..\..\hbsocket.c(3028): Note! N2004: target conversion type is 'char *' Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: -DTCPV40HDRS
Maurilio: >do you still use warp 3? If not, we can remove it :D I just have the red boxes, but do not use it. I was supposing you are using it :-) I have boxes of OS/2 2.0, 2.1, Warp 3, Warp 4, eCS 1.0, 1.2, 1.2MR >Jokes apart, we can decide that warp3 is not supported when using Qt or > all together. Preferable all together >I don't really know who is using harbour on OS/2 so I put it in to stay > on the safe side. I do not know too Harbour 2.0.0 for OS/2 downloads have an strange behaviour not expected for OS/2. It have downloads in sustained state daily and now have more than 600. Seem notice is spreading between isolated groups, but no one has requested help or comment Many experts in OS/2-Clipper code :-) So we exclude -DTCPV40HDRS, dropping Warp 3 support in Harbour ? ( Think carefully: many corporations, banks, ATM, ... will be affected :-) ) David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor, Viktor Szakáts wrote: >> The user/installer when it installs the compiler and its tool-chain, so it >> has >> to be present, otherwise you cannot compile even a simple helloworld.c. > > Sorry if I missed it, but can you paste here a living > example for what value it's actually set to? > here is mine when not using old tcp headers, (E:\harbour\ftpd)set LIBRARY_PATH LIBRARY_PATH=E:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5;E:/SVI LUPPO/GCC/V3.3.5/USR/lib;D:\JAVA11\LIB; > I'd also like to include it in INSTALL, since it's > apparently missing. > It is a GCC environment setting, so it has to be OK before trying to install harbour. > > I've just posted a little change which helps > the case already: $(HB_COMP_PATH_PUB) which > returns the directory where gcc.exe is residing > in. > Ok, but is there a way, inside .mk files to split an env-var using some char as delimiter? if yes, than we can create the command line for ld which has this sequence of paths as a variable part, while the rest should be pretty fixed. Thanks. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
David, David Arturo Macias Corona wrote: > I do not know too > Harbour 2.0.0 for OS/2 downloads have an strange behaviour not expected > for OS/2. It have downloads in sustained state daily and now have more > than 600. >From different IPs? I don't believe there are so many OS/2 programmers still using a clipper dialect out there. It is not possible! > So we exclude -DTCPV40HDRS, dropping Warp 3 support in Harbour ? > ( Think carefully: many corporations, banks, ATM, ... will be affected > :-) ) > Let's hope not to need one of those ATMs after we remove the switch! :D Anyway, I'd say to remove it, given Warp 3 is as old as Windows 95 or even older, and let's see what happens. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13959] trunk/harbour
Revision: 13959 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13959&view=rev Author: vszakats Date: 2010-02-22 14:07:26 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 15:06 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbdefs.h ! Fixed to not #include unconditionally. This should be done by specific source code, if needed. INCOMPATIBLE, if source code relied on this behavior. From now on it, should include dos.h manually. * src/vm/thread.c * src/common/hbver.c * src/rtl/gtdos/gtdos.c * src/rtl/isprint.c * src/rtl/diskspac.c * src/rtl/disksphb.c * src/rtl/net.c * contrib/hbct/print.c ! Fixed to #include manually. * src/rtl/fstemp.c ! Fixed recent warning for dos targets. * contrib/hbct/video.c ! Fixed old unused variable warning for dos/watcom targets. * INSTALL + Documented that OS/2 Warp 4 is supported (instead of generic OS/2). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/contrib/hbct/print.c trunk/harbour/contrib/hbct/video.c trunk/harbour/include/hbdefs.h trunk/harbour/src/common/hbver.c trunk/harbour/src/rtl/diskspac.c trunk/harbour/src/rtl/disksphb.c trunk/harbour/src/rtl/fstemp.c trunk/harbour/src/rtl/gtdos/gtdos.c trunk/harbour/src/rtl/isprint.c trunk/harbour/src/rtl/net.c trunk/harbour/src/vm/thread.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
> I do not know too > Harbour 2.0.0 for OS/2 downloads have an strange behaviour not expected for > OS/2. It have downloads in sustained state daily and now have more than 600. > Seem notice is spreading between isolated groups, but no one has requested > help or comment > Many experts in OS/2-Clipper code :-) > > So we exclude -DTCPV40HDRS, dropping Warp 3 support in Harbour ? > ( Think carefully: many corporations, banks, ATM, ... will be affected :-) ) Is there any way to detect OS/2 target version and automatically toggle this option accordingly? Also, in such way HBQT could be disabled for < Warp 4 targets. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
>> Sorry if I missed it, but can you paste here a living >> example for what value it's actually set to? >> > > here is mine when not using old tcp headers, > > (E:\harbour\ftpd)set LIBRARY_PATH > LIBRARY_PATH=E:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5;E:/SVI > LUPPO/GCC/V3.3.5/USR/lib;D:\JAVA11\LIB; Thank you. >> I'd also like to include it in INSTALL, since it's >> apparently missing. >> > It is a GCC environment setting, so it has to be OK before trying to install > harbour. Okay, I see now that currently some .cmds are called to init the env, maybe this ennvar is setup in there. > >> >> I've just posted a little change which helps >> the case already: $(HB_COMP_PATH_PUB) which >> returns the directory where gcc.exe is residing >> in. >> > > Ok, but is there a way, inside .mk files to split an env-var using some char > as delimiter? if yes, than we can create the command line for ld which has > this sequence of paths as a variable part, while the rest should be pretty > fixed. Yes, it's possble. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
Viktor, I'd say a ver command should return a version >= 4.00 (E:\harbour\ftpd)ver The Operating System/2 Version is 4.50 The issue, though, is not when building on a warp 3 system, but trying to use a program built without this option on a warp 3 system. More or less like running the code to find out interface addresses on a win95 pc, because such a program requires libraries not available on and for warp 3. Maurilio. Viktor Szakáts wrote: >> I do not know too >> Harbour 2.0.0 for OS/2 downloads have an strange behaviour not expected for >> OS/2. It have downloads in sustained state daily and now have more than 600. >> Seem notice is spreading between isolated groups, but no one has requested >> help or comment >> Many experts in OS/2-Clipper code :-) >> >> So we exclude -DTCPV40HDRS, dropping Warp 3 support in Harbour ? >> ( Think carefully: many corporations, banks, ATM, ... will be affected :-) ) > > Is there any way to detect OS/2 target version and > automatically toggle this option accordingly? > > Also, in such way HBQT could be disabled for < Warp 4 > targets. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Viktor Szakáts wrote: > Okay, I see now that currently some .cmds are called > to init the env, maybe this ennvar is setup in there. > No, the harbour build process should not set nor change LIBRARY_PATH, this has to be set and be correct _before_ installing harbour. >> Ok, but is there a way, inside .mk files to split an env-var using some char >> as delimiter? if yes, than we can create the command line for ld which has >> this sequence of paths as a variable part, while the rest should be pretty >> fixed. > > Yes, it's possble. Ok, are there examples available? Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13960] trunk/harbour
Revision: 13960 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13960&view=rev Author: vszakats Date: 2010-02-22 14:21:15 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 15:20 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/os2/gcc.mk + Attempt to fix direct ld usage to create Harbour .dlls. Please make tests for all versions of gcc/gccomf targets. * INSTALL - Deleted TCPV4 header instructions for OS/2. (they still works, it just got less emphasis with this) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/os2/gcc.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
> Viktor, > > I'd say a ver command should return a version >= 4.00 > > (E:\harbour\ftpd)ver > > The Operating System/2 Version is 4.50 That tells us the host OS version. We need a way to tell the version of OS/2 we're building _for_ though. Similar to _WIN32_WINNT macro. Such macro may have some default defined by headers, and it's also possible to override it by user. This is the generic way to force a build which targets and older version of the OS environment (or even newer, if the default is an older version). > The issue, though, is not when building on a warp 3 system, but trying to use > a program built without this option on a warp 3 system. More or less like > running the code to find out interface addresses on a win95 pc, because such a > program requires libraries not available on and for warp 3. (pls see above) Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
Hi Xavi, _Przemek, thank you very much for answering me directly_ It's is possible. Just like many other things which still do not exists in MS-Windows and we will have to wait next 10 years until MS discover them and add some support for it in WinSOCK.X.Y.Z which will work correctly in version X.Y.Z + N. There is only one question: Why we should add such things? The fact that sth is possible on some platforms does not mean that it has to be implemented. [...] Why you added HB_SOCKET_IFINFO_GATEWAY? What programs do you plan to write which will need such information? How do you know that which gateway belongs to each IP address? It's possible that aliases uses different gateways (at least in normal systems). I do not see any code which tries to bind gateway addresses with IP addresses so HB_SOCKET_IFINFO_GATEWAY contains correct information only when the same gateway is used by all aliases. I did it to make something new, not important in itself. MS-Windows does not have interface names as other hosts. AFAIR windows ports of some *nix tools like ifconfing used IP address as interface name so I decided to use the same. You added code which replace this IP addres with "localhost" string for LOOPBACK interfaces. Why? AFAIK in Windows the adapter name is one GUID exept localhost. Do you know that it's possible to have more then one LOOPBACK interface with different addresses? Yes and with the appropriate GUID adapter name. [...] hb_arrayGetC() returns address to dynamically allocated memory block which should be freed by hb_itemFreeC(). Now this code causes memory leak. Is iphlpapi.dll loaded by application at startup and keep alive for whole application running time? THANK YOU!!! for test and respond. Yes, I've a pretty hb_out.log report compiling with HB_FM_STATISTICS. Remember what means a draft code. :) You can see the interest of people about it because your sample PRG code and my sample no presents nothing in Windows. If not then storing pointer to GetAdaptersInfo() in static variable seems to be a little bit risk because such address may change. I think that this may also happen with the system dlls. Remember my post about this .- http://lists.harbour-project.org/pipermail/harbour/2010-February/032151.html BTW in which Windows version GetAdaptersInfo() was added? This code does not detect aliases. It has to be redesigned to eliminate them. Well, what do you suggest? Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Maurilio: >while the last 3.3.5 in the path depends on GCC version and so it >changes from release to release. >So we have to parse LIBRARY_PATH to add -L options to ld command line, >but it is not enough since we need an object, dll0.o, which is inside >E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o >which could be inferred from LIBRARY_PATH, but I don't know whether the >new versions of GCC have it in the same position. >This is something that has to be hard-coded inside gcc when used as >dl.exe front end which should be extracted from it in some way. Newer os2gcc are installed usually in \usr\(compiler), but os2gcc335 is *mandatory* to be installed too, as newer rely in some gcc335 tools In my machine gcc335 is in \usr\ gcc442 in \usr\local442 and dll0.o exist only in \usr\lib So path, references for both compilers are included, newer first >I'd say yes, the OMF version has an .obj extension. No. Due facts Viktor knows well, .o was impossed to both, a.out and OMF .obj for OMF was excluded >Who/what is setting LIBRARY_PATH? Should it be set by user, >or is it set by some of the GCC tools in GCC toolchain? This setting can be changed dinamically to fit requirements of many systems, not only os2gcc >Sorry if I missed it, but can you paste here a living >example for what value it's actually set to? >I'd also like to include it in INSTALL, since it's >apparently missing. >Ok, but is there a way, inside .mk files to split an env-var using some >char as delimiter? if yes, than we can create the command line for ld >which has this sequence of paths as a variable part, while the rest >should be pretty fixed. I do tests with many os2gcc compilers, so forcing values for ld.exe/emxomfld.exe should be practical For example, for os2gcc442, which show gcc442,gcc335 references: - PATH_EMXPGCC=E:\usr CCENV=EMX BUILD_ENV=EMX BUILD_PLATFORM=OS2 DPATH=E:\usr\local442\lib;E:\usr\lib;E:\MPTN; ... PATH=E:\usr\local442\libexec\gcc\i386-pc-os2-emx\4.4.2;E:\usr\local442\bin;E:\usr\bin; ... C_INCLUDE_PATH=E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2/include;E:/usr/local442/include;E:/usr/include; CPLUS_INCLUDE_PATH=E:/usr/local442/include/c++/4.4.2;E:/usr/local442/include/c++/4.4.2/i386-pc-os2-emx;E:/usr/local442/include/c++/4.4.2/backward;E:/usr/local442/include;E:/usr/include; LIBRARY_PATH=E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2;E:/usr/local442/lib;E:/usr/lib; INFOPATH=E:/usr/local442/info;E:/usr/info; PROTODIR=E:/usr/include/c++/gen BEGINLIBPATH=E:\usr\local442\lib;E:\usr\lib; - >No, the harbour build process should not set nor change LIBRARY_PATH, >this has to be set and be correct _before_ installing harbour. Fully agree. See above David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
> >No, the harbour build process should not set nor change LIBRARY_PATH, >this > >has to be set and be correct _before_ installing harbour. > > Fully agree. See above This has been agreed upon 10 years ago, so no need to re-agree on anything. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
>> Okay, I see now that currently some .cmds are called >> to init the env, maybe this ennvar is setup in there. >> > > No, the harbour build process should not set nor change LIBRARY_PATH, this has > to be set and be correct _before_ installing harbour. I wasn't clear. I was talking about this in INSTALL: --- for OS/2 hosts -- --- GCC 3.3.4 and GCC 3.3.5 C:\usr\bin\gccenv.cmd os2-make --- --- GCC 4.x C:\usr\local433\gcc440.cmd set HB_COMPILER=gccomf os2-make --- --- Harbour build never modifies system variables. It never did. >>> Ok, but is there a way, inside .mk files to split an env-var using some char >>> as delimiter? if yes, than we can create the command line for ld which has >>> this sequence of paths as a variable part, while the rest should be pretty >>> fixed. >> >> Yes, it's possble. > > Ok, are there examples available? There are quite a few in global.mk and other .mk files, anyway I've already committed it, untested, so pls check it. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
On Mon, 22 Feb 2010, Szak�ts Viktor wrote: Hi, > >>> -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 > >>> E:/SVILUPPO/GCC/V3.3.5/ is where I decided to put GCC on my system, while > >>> the > >>> last 3.3.5 in the path depends on GCC version and so it changes from > >>> release > >>> to release. > >> Is '/gcc/3.3.5/' a mandatory element of the base dir, or > >> local user preference? I mean, may I simple install it > >> to 'E:/os2stuff/gcc/' instead of 'E:/Sviluppo/gcc/v3.3.5/'? > > Sure. > This means we can't use base path to get version > information needed to form paths for ld.exe. > To me it's unclear how to make this automatic or > elegant. Calling LD directly usually creates more or less serious problems because some important switches set by GCC automatically may not be added by us. BTW the problem is caused by too long list of files passed from GCC to LD because GCC does not use intermediate files. But maybe it's possible to use small trick. DJGPP and as I can see OS2 GNU ports expands @ used in parameters. So maybe we can simply create 2 files. One with GCC/LD options only and with reference to second file __flst__.tmp will have list of object files. Such reference can be stored in first file as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then we can pass first object file directly as GCC parameter and not include in __flst__.tmp. If Maurilio or David can verify it works then we can use such method and it should resolve the problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: -DTCPV40HDRS
>> than 600. >From different IPs? I do not know. They are sourceforge numbers >I don't believe there are so many OS/2 programmers still using a >clipper dialect out there. It is not possible! :-), it is possible Remember that Clipper and OS/2 are of same age >Let's hope not to need one of those ATMs after we remove the switch! :D >Anyway, I'd say to remove it, given Warp 3 is as old as Windows 95 or >even older, and let's see what happens. Just cross your fingers >The issue, though, is not when building on a warp 3 system, but trying >to use a program built without this option on a warp 3 system. More or >less like running the code to find out interface addresses on a win95 >pc, because such a program requires libraries not available on and for >warp 3. Is correct. Is not Harbour build related, but runtime >Such macro may have some default defined by headers, and it's also >possible to override it by user. This is the generic way >to force a build which targets and older version of the OS environment >(or even newer, if the default is an older version). Is correct too > * INSTALL >- Deleted TCPV4 header instructions for OS/2. (they still > works, it just got less emphasis with this) And due above facts, this has not be deleted Instructions are for everyone and newer user can be pointed clearly on this fact reading INSTALL David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Hi, > -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5 > E:/SVILUPPO/GCC/V3.3.5/ is where I decided to put GCC on my system, while > the > last 3.3.5 in the path depends on GCC version and so it changes from > release > to release. Is '/gcc/3.3.5/' a mandatory element of the base dir, or local user preference? I mean, may I simple install it to 'E:/os2stuff/gcc/' instead of 'E:/Sviluppo/gcc/v3.3.5/'? >>> Sure. >> This means we can't use base path to get version >> information needed to form paths for ld.exe. >> To me it's unclear how to make this automatic or >> elegant. > > Calling LD directly usually creates more or less serious problems > because some important switches set by GCC automatically may not > be added by us. Yes. > BTW the problem is caused by too long list of files passed > from GCC to LD because GCC does not use intermediate files. > But maybe it's possible to use small trick. DJGPP and as > I can see OS2 GNU ports expands @ used in parameters. Yes. > So maybe we can simply create 2 files. One with GCC/LD options > only and with reference to second file __flst__.tmp will have > list of object files. Such reference can be stored in first file > as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then > we can pass first object file directly as GCC parameter and not > include in __flst__.tmp. That's a good idea. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Maurilio: >Newer os2gcc are installed usually in \usr\(compiler), but os2gcc335 is >*mandatory* to be installed too, as newer rely in some gcc335 tools >In my machine gcc335 is in \usr\ >gcc442 in \usr\local442 and dll0.o exist only in \usr\lib >So path, references for both compilers are included, newer first Do you have dll0.obj ? I have both .o and .obj OBJ_EXT is forced to .o, but we need to check what is using gcc in OMF (dll0.o or dll0.obj) dir dll*.o* /s Directory of E:\usr\lib 11/06/07 10:52p 1,955 0 a--- dll0.o 11/06/07 10:52p 2,797 0 a--- dll0.obj 11/06/07 10:52p 1,955 0 a--- dll0hi.o 11/06/07 10:52p 2,797 0 a--- dll0hi.obj 11/06/07 10:52p 1,279 0 a--- dll0hinofork.o 11/06/07 10:52p 2,105 0 a--- dll0hinofork.obj 11/06/07 10:52p 1,279 0 a--- dll0hinoforknoux.o 11/06/07 10:52p 2,105 0 a--- dll0hinoforknoux.obj 11/06/07 10:52p 1,279 0 a--- dll0hinoux.o 11/06/07 10:52p 2,105 0 a--- dll0hinoux.obj 11/06/07 10:52p 1,279 0 a--- dll0nofork.o 11/06/07 10:52p 2,105 0 a--- dll0nofork.obj 11/06/07 10:52p 1,279 0 a--- dll0noforknoux.o 11/06/07 10:52p 2,105 0 a--- dll0noforknoux.obj 11/06/07 10:52p 1,279 0 a--- dll0noux.o 11/06/07 10:52p 2,105 0 a--- dll0noux.obj David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
>> So maybe we can simply create 2 files. One with GCC/LD options >> only and with reference to second file __flst__.tmp will have >> list of object files. Such reference can be stored in first file >> as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then >> we can pass first object file directly as GCC parameter and not >> include in __flst__.tmp. > > That's a good idea. The file list is already separate, so to try this solution out, only '-Wl,' needs to be added right in front of '@__dyn__.tmp': --- [gcc.mk] $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl,@__dyn__.tmp __dyn__.def $(DLIBS) $(DYSTRIP) --- This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently on SVN. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Przemek: [Przemek] >Calling LD directly usually creates more or less serious problems >because some important switches set by GCC automatically may not >be added by us. >BTW the problem is caused by too long list of files passed >from GCC to LD because GCC does not use intermediate files. >But maybe it's possible to use small trick. DJGPP and as >I can see OS2 GNU ports expands @ used in parameters. >So maybe we can simply create 2 files. One with GCC/LD options >only and with reference to second file __flst__.tmp will have >list of object files. Such reference can be stored in first file >as: '-Wl, at __flst__.tmp'. If gcc expects at least one .o file then >we can pass first object file directly as GCC parameter and not >include in __flst__.tmp. >If Maurilio or David can verify it works then we can use such >method and it should resolve the problem. [Viktor] >The file list is already separate, so to try this solution out, >only '-Wl,' needs to be added right in front of '@__dyn__.tmp': >--- [gcc.mk] > $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl, at >__dyn__.tmp __dyn__.def $(DLIBS) $(DYSTRIP) >--- >This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently >on SVN. Unfortunatelly we do not have matter to test right now As I posted recently, changes in libraries caused all .dll can be build fine, no one fails I will look for older versions to find which fail and to test this approach. 13841 is an option. How must be specified in SVN ? In all these messages ping-pong I was tempted to insert the question: "Do we really need to force direct ld.exe/emxomfld.exe right now ?" My answer is no David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
On Mon, 22 Feb 2010, Szak�ts Viktor wrote: Hi, > >> So maybe we can simply create 2 files. One with GCC/LD options > >> only and with reference to second file __flst__.tmp will have > >> list of object files. Such reference can be stored in first file > >> as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then > >> we can pass first object file directly as GCC parameter and not > >> include in __flst__.tmp. > > That's a good idea. > The file list is already separate, so to try this solution out, > only '-Wl,' needs to be added right in front of '@__dyn__.tmp': > --- [gcc.mk] >$(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl,@__dyn__.tmp > __dyn__.def $(DLIBS) $(DYSTRIP) > --- > This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently > on SVN. Looks OK for me. If OS2 GCC port does not need at least one .o/.obj file (in my Linux box it doesn't) then it should work and resolve the problem without direct call to LD. Maurilio or David, Can you check it? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Przemek: >Looks OK for me. >If OS2 GCC port does not need at least one .o/.obj file (in my Linux >box it doesn't) then it should work and resolve the problem without >direct call to LD. >Maurilio or David, Can you check it? Work in progress with "-r 13841" David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
On Mon, 22 Feb 2010, David Arturo Macias Corona wrote: Hi David, > >The file list is already separate, so to try this solution out, > >only '-Wl,' needs to be added right in front of '@__dyn__.tmp': > >--- [gcc.mk] > > $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl, at > >__dyn__.tmp __dyn__.def $(DLIBS) $(DYSTRIP) > >--- > >This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently > >on SVN. > Unfortunatelly we do not have matter to test right now > As I posted recently, changes in libraries caused all .dll can be > build fine, no one fails It's less important if current version fails or not. More important is information if above trick can be used. If this trick works without any errors then it should eliminate passing object files in command line between GCC and LD what is the source of problem because GCC will not expand -Wl,@__dyn__.tmp but pass @__dyn__.tmp directly to LD. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Przemek: >It's less important if current version fails or not. >More important is information if above trick can be used. >If this trick works without any errors then it should eliminate >passing object files in command line between GCC and LD what is >the source of problem because GCC will not expand -Wl, at __dyn__.tmp >but pass @__dyn__.tmp directly to LD. Check me if "-Wl," is inserted correctly First try using -v switch in gcc: __dyn__.tmp is expanded gcc -shared -L../../../../../lib/os2/gccomf -Zomf -v -o ../../../../../bin/os2/gccomf/harbour.dll -Wl, @__dyn__.tmp __dyn__.def -lsocket Using built-in specs. Target: i386-pc-os2-emx Configured with: ./configure --prefix=/usr/local44 --enable-shared --enable-languages=c,c++,fortran --with-gnu-as --disable-bootstrap --disable-libstdcxx-pch --enable-threads Thread model: os2 gcc version 4.4.2 (GCC) COMPILER_PATH=E:/usr/local442/bin/../libexec/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/bin/../libexec/gcc/;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/bin/ LIBRARY_PATH=E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/bin/../lib/gcc/;E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/lib/;E:/usr/lib/;./;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/lib/;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../;/usr/lib/ COLLECT_GCC_OPTIONS='-shared' '-L../../../../../lib/os2/gccomf' '-Zomf' '-v' '-o' '../../../../../bin/os2/gccomf/harbour.dll' '-mtune=i386' emxomfld.exe -Zdll -o ../../../../../bin/os2/gccomf/harbour.dll E:/usr/lib/dll0.obj -L../../../../../lib/os2/gccomf -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2 -LE:/usr/local442/bin/../lib/gcc -LE:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2 -LE:/usr/local442/lib -LE:/usr/lib -L. -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/lib -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../.. ../../../../../src/common/obj/os2/gccomf/expropt1.o ../../../../../src/common/obj/os2/gccomf/expropt2.o [...] ../../../../../src/vm/obj/os2/gccomf/pvalue.o ../../../../../src/vm/obj/os2/gccomf/runner.o ../../../../../src/vm/obj/os2/gccomf/vm.o __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc442 -lc_alias -lc_dll -los2 -lend emxomf: Input file `E:\harbour102\harbour\src\dynlib\obj\os2\gccomf' is not seekable emxomfld: a.out to omf conversion failed for 'E:\harbour102\harbour\src\dynlib\obj\os2\gccomf'. make[3]: *** [harbour.dll] Error 1 David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
> emxomfld.exe -Zdll -o ../../../../../bin/os2/gccomf/harbour.dll >E:/usr/lib/dll0.obj -L../../../../../lib/os2/gccomf >-LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2 [...] >../../../../../src/common/obj/os2/gccomf/expropt1.o And is using .obj in OMF type, as usual: E:/usr/lib/dll0.obj OBJ_EXT are forced to .o David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
> >../../../../../src/common/obj/os2/gccomf/expropt1.o > > And is using .obj in OMF type, as usual: > E:/usr/lib/dll0.obj > > OBJ_EXT are forced to .o Forced. I have to tell you that I can't remember the whole lengthy discussion before implementing this the way it is now, but since it takes near zero effort to switch to .obj in .mk files, .o is used consistently in build/hbmk2, and since you didn't report any problems with any of the discussed gcc versions, I must assume we settled for .o for good reason. Also note I don't personally mind what extension does gcc actually requires. Now it's "forced". If current state is suddenly wrong for whatever reasons, tell clearly what happened in between, and what you suggest now for a solution. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error compiling hbqt_hbslots.cpp
Hi Here is an error compiling with MSVC8: cl.exe -I. -I../../../../../include -nologo -TP -W4 -wd4127 -Ot2b1 -EHs-c- -Zi -DHB_LEGACY_TYPES_OFF -DUNICODE -DHB_TR_LEVEL_DEBUG -IC:\Qt\msvc\include -IC:\Qt\msvc\include/QtCore -IC:\Qt\msvc\include/QtGui -IC:\Qt\msvc\include/QtNetwork -Fohbqt_hbslots.obj -c ../../../hbqt_hbslots.cpp hbqt_hbslots.cpp ../../../hbqt_hbslots.cpp(207) : fatal error C1061: compiler limit : blocks nested too deeply mingw32-make[3]: [hbqt_hbslots.obj] Error 2 (ignored) BRGDS Franček -- View this message in context: http://old.nabble.com/Error-compiling-hbqt_hbslots.cpp-tp27689677p27689677.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Przemyslaw, it worked here and produced both harbour.dll and harbourm.dll ar -M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a & ..\..\.. \..\..\config\os2rm -f __lib__.tmp gcc -shared -L../../../../../lib/os2/gcc -o ../../../../../bin/os2/gcc/harbour .dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s emximp -o ../../../../../lib/os2/gcc/harbour.a ../../../../../bin/os2/gcc/harbou r.dll gcc -shared -L../../../../../../lib/os2/gcc -o ../../../../../../bin/os2/gcc/h arbourm.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s emximp -o ../../../../../../lib/os2/gcc/harbourm.a ../../../../../../bin/os2/gcc /harbourm.dll Question is: did it expand or not @__dyb__.tmp list before calling ld? Now I'll try with my ld.exe to see what gets passed to ld.exe. Maurilio. Przemysław Czerpak wrote: > On Mon, 22 Feb 2010, Szak�ts Viktor wrote: > > Hi, > So maybe we can simply create 2 files. One with GCC/LD options only and with reference to second file __flst__.tmp will have list of object files. Such reference can be stored in first file as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then we can pass first object file directly as GCC parameter and not include in __flst__.tmp. >>> That's a good idea. >> The file list is already separate, so to try this solution out, >> only '-Wl,' needs to be added right in front of '@__dyn__.tmp': >> --- [gcc.mk] >>$(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl,@__dyn__.tmp >> __dyn__.def $(DLIBS) $(DYSTRIP) >> --- >> This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently >> on SVN. > > Looks OK for me. > If OS2 GCC port does not need at least one .o/.obj file (in my Linux box > it doesn't) then it should work and resolve the problem without direct > call to LD. > > Maurilio or David, Can you check it? > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Przemek: >Check me if "-Wl," is inserted correctly It was wrong including space at end Second try using -v switch in gcc: __dyn__.tmp is NOT expanded :-) gcc -shared -L../../../../../lib/os2/gccomf -Zomf -v -o ../../../../../bin/os2/gccomf/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket Using built-in specs. Target: i386-pc-os2-emx Configured with: ./configure --prefix=/usr/local44 --enable-shared --enable-languages=c,c++,fortran --with-gnu-as --disable-bootstrap --disable-libstdcxx-pch --enable-threads Thread model: os2 gcc version 4.4.2 (GCC) COMPILER_PATH=E:/usr/local442/bin/../libexec/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/bin/../libexec/gcc/;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/bin/ LIBRARY_PATH=E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/bin/../lib/gcc/;E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/lib/;E:/usr/lib/;./;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/lib/;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../;/usr/lib/ COLLECT_GCC_OPTIONS='-shared' '-L../../../../../lib/os2/gccomf' '-Zomf' '-v' '-o' '../../../../../bin/os2/gccomf/harbour.dll' '-mtune=i386' emxomfld.exe -Zdll -o ../../../../../bin/os2/gccomf/harbour.dll E:/usr/lib/dll0.obj -L../../../../../lib/os2/gccomf -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2 -LE:/usr/local442/bin/../lib/gcc -LE:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2 -LE:/usr/local442/lib -LE:/usr/lib -L. -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/lib -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../.. @__dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc442 -lc_alias -lc_dll -los2 -lend Warning! W1058: file ldN4tZz5.: line(618): protmode option not valid for an OS/2 EMX dynamic link library emximp -o ../../../../../lib/os2/gccomf/harbour.lib ../../../../../bin/os2/gccomf/harbour.dll make[3]: Leaving directory `E:/harbour102/harbour/src/dynlib/obj/os2/gccomf' make[3]: Entering directory `E:/harbour102/harbour/src/dynlib/mt' make[4]: Entering directory `E:/harbour102/harbour/src/dynlib/mt/obj/os2/gccomf' gcc -shared -L../../../../../../lib/os2/gccomf -Zomf -v -o ../../../../../../bin/os2/gccomf/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket Using built-in specs. Target: i386-pc-os2-emx Configured with: ./configure --prefix=/usr/local44 --enable-shared --enable-languages=c,c++,fortran --with-gnu-as --disable-bootstrap --disable-libstdcxx-pch --enable-threads Thread model: os2 gcc version 4.4.2 (GCC) COMPILER_PATH=E:/usr/local442/bin/../libexec/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/bin/../libexec/gcc/;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/bin/ LIBRARY_PATH=E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/bin/../lib/gcc/;E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2/;E:/usr/local442/lib/;E:/usr/lib/;./;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/lib/;E:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../;/usr/lib/ COLLECT_GCC_OPTIONS='-shared' '-L../../../../../../lib/os2/gccomf' '-Zomf' '-v' '-o' '../../../../../../bin/os2/gccomf/harbourm.dll' '-mtune=i386' emxomfld.exe -Zdll -o ../../../../../../bin/os2/gccomf/harbourm.dll E:/usr/lib/dll0.obj -L../../../../../../lib/os2/gccomf -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2 -LE:/usr/local442/bin/../lib/gcc -LE:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2 -LE:/usr/local442/lib -LE:/usr/lib -L. -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../../../i386-pc-os2-emx/lib -LE:/usr/local442/bin/../lib/gcc/i386-pc-os2-emx/4.4.2/../../.. @__dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc442 -lc_alias -lc_dll -los2 -lend Warning! W1058: file ldT6yXLH.: line(617): protmode option not valid for an OS/2 EMX dynamic link library emximp -o ../../../../../../lib/os2/gccomf/harbourm.lib ../../../../../../bin/os2/gccomf/harbourm.dll make[4]: Leaving directory `E:/harbour102/harbour/src/dynlib/mt/obj/os2/gccomf' and both .dll are created 22/02/10 10:07a 3,837,134 0 a--- harbour.dll 22/02/10 10:08a 3,837,545 0 a--- harbourm.dll Maurilio, Viktor, Przemek: solution is "-Wl," David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error compiling hbqt_hbslots.cpp
Hi Franček Prijatelj wrote: > > Hi > > Here is an error compiling with MSVC8: > > cl.exe -I. -I../../../../../include -nologo -TP -W4 -wd4127 -Ot2b1 > -EHs-c- -Zi -DHB_LEGACY_TYPES_OFF -DUNICODE -DHB_TR_LEVEL_DEBUG > -IC:\Qt\msvc\include -IC:\Qt\msvc\include/QtCore > -IC:\Qt\msvc\include/QtGui -IC:\Qt\msvc\include/QtNetwork > -Fohbqt_hbslots.obj -c ../../../hbqt_hbslots.cpp > hbqt_hbslots.cpp > ../../../hbqt_hbslots.cpp(207) : fatal error C1061: compiler limit : > blocks nested too deeply > mingw32-make[3]: [hbqt_hbslots.obj] Error 2 (ignored) > > MSVC8 has 128 nesting limit. BRGDS Franček -- View this message in context: http://old.nabble.com/Error-compiling-hbqt_hbslots.cpp-tp27689677p27689817.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Przemyslaw, Viktor, yes it works as expected, ld.exe gets called with @__dyn__.tmp as expected!! See here gcc -shared -L../../../../../lib/os2/gcc -o ../../../../../bin/os2/gcc/harbour .dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s 8< -Zdll -o ../../../../../bin/os2/gcc/harbour.dll -s E:/SVILUPPO/GCC/V3.3.5/USR/li b/dll0.o -L../../../../../lib/os2/gcc -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i 386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib -LE:/SVILUPPO/GCC/ V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/SVILUPPO/GCC/V3.3.5/USR/lib -L E:/REPOSITORY/HARBOUR/src/dynlib/obj/os2/gcc -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gc c-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib -LE :/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib -LE:/Sviluppo/gcc/v3.3.5/usr/lib @ __dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -l c_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los 2 -lgcc_so_d -lc_alias -lc_dll -los2 >8emximp -o ../../../../../lib/os2/gcc/harbour.a ../../../../../bin/os2/gcc/harbour.dll emximp: Cannot open input file `../../../../../bin/os2/gcc/harbour.dll' make[2]: *** [harbour.dll] Error 2 make[1]: *** [descend] Error 2 make: *** [dynlib] Error 2 The error come from the fact that my ld.exe does not build harbour.dll So, this should close the issue for ever :) Thanks so much, guys! Maurilio. Przemysław Czerpak wrote: > On Mon, 22 Feb 2010, Szak�ts Viktor wrote: > > Hi, > So maybe we can simply create 2 files. One with GCC/LD options only and with reference to second file __flst__.tmp will have list of object files. Such reference can be stored in first file as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then we can pass first object file directly as GCC parameter and not include in __flst__.tmp. >>> That's a good idea. >> The file list is already separate, so to try this solution out, >> only '-Wl,' needs to be added right in front of '@__dyn__.tmp': >> --- [gcc.mk] >>$(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl,@__dyn__.tmp >> __dyn__.def $(DLIBS) $(DYSTRIP) >> --- >> This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently >> on SVN. > > Looks OK for me. > If OS2 GCC port does not need at least one .o/.obj file (in my Linux box > it doesn't) then it should work and resolve the problem without direct > call to LD. > > Maurilio or David, Can you check it? > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Maurilio: >Question is: did it expand or not @__dyb__.tmp list before calling ld? As gcc -v show, does NOT expand >Now I'll try with my ld.exe to see what gets passed to ld.exe. Should be as gcc -v Problem is solved David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error compiling hbqt_hbslots.cpp
Hi Franček Prijatelj wrote: > > > Here is an error compiling with MSVC8: > > cl.exe -I. -I../../../../../include -nologo -TP -W4 -wd4127 -Ot2b1 > -EHs-c- -Zi -DHB_LEGACY_TYPES_OFF -DUNICODE -DHB_TR_LEVEL_DEBUG > -IC:\Qt\msvc\include -IC:\Qt\msvc\include/QtCore > -IC:\Qt\msvc\include/QtGui -IC:\Qt\msvc\include/QtNetwork > -Fohbqt_hbslots.obj -c ../../../hbqt_hbslots.cpp > hbqt_hbslots.cpp > ../../../hbqt_hbslots.cpp(207) : fatal error C1061: compiler limit : > blocks nested too deeply > mingw32-make[3]: [hbqt_hbslots.obj] Error 2 (ignored) > > Only solution to simplify nesting level: http://msdn.microsoft.com/en-us/library/dcda4f64%28VS.71%29.aspx BRGDS Franček -- View this message in context: http://old.nabble.com/Error-compiling-hbqt_hbslots.cpp-tp27689677p27689885.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Yes, sorry I rushed testing instead of keep reading messages. Solved! .) Maurilio. David Arturo Macias Corona wrote: > Maurilio: > >>Question is: did it expand or not @__dyb__.tmp list before calling ld? > > As gcc -v show, does NOT expand > >>Now I'll try with my ld.exe to see what gets passed to ld.exe. > > Should be as gcc -v > > Problem is solved > > David Macias > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: Harbour 13945
Great, nice cooperation. Just committed this version. Case closed. Brgds, Viktor On 2010 Feb 22, at 17:18, Maurilio Longo wrote: > Przemyslaw, Viktor, > > yes it works as expected, ld.exe gets called with @__dyn__.tmp as expected!! > > See here > > gcc -shared -L../../../../../lib/os2/gcc -o > ../../../../../bin/os2/gcc/harbour > .dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s > > 8< > -Zdll -o ../../../../../bin/os2/gcc/harbour.dll -s > E:/SVILUPPO/GCC/V3.3.5/USR/li > b/dll0.o -L../../../../../lib/os2/gcc > -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i > 386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib > -LE:/SVILUPPO/GCC/ > V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5 -LE:/SVILUPPO/GCC/V3.3.5/USR/lib > -L > E:/REPOSITORY/HARBOUR/src/dynlib/obj/os2/gcc > -LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gc > c-lib/i386-pc-os2-emx/3.3.5 -LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib > -LE > :/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib > -LE:/Sviluppo/gcc/v3.3.5/usr/lib @ > __dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias > -l > c_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll > -los > 2 -lgcc_so_d -lc_alias -lc_dll -los2 > >8emximp -o > ../../../../../lib/os2/gcc/harbour.a > ../../../../../bin/os2/gcc/harbour.dll > emximp: Cannot open input file `../../../../../bin/os2/gcc/harbour.dll' > make[2]: *** [harbour.dll] Error 2 > make[1]: *** [descend] Error 2 > make: *** [dynlib] Error 2 > > > The error come from the fact that my ld.exe does not build harbour.dll > > So, this should close the issue for ever :) > > Thanks so much, guys! > > Maurilio. > > > Przemysław Czerpak wrote: >> On Mon, 22 Feb 2010, Szak�ts Viktor wrote: >> >> Hi, >> > So maybe we can simply create 2 files. One with GCC/LD options > only and with reference to second file __flst__.tmp will have > list of object files. Such reference can be stored in first file > as: '-Wl,@__flst__.tmp'. If gcc expects at least one .o file then > we can pass first object file directly as GCC parameter and not > include in __flst__.tmp. That's a good idea. >>> The file list is already separate, so to try this solution out, >>> only '-Wl,' needs to be added right in front of '@__dyn__.tmp': >>> --- [gcc.mk] >>> $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl,@__dyn__.tmp >>> __dyn__.def $(DLIBS) $(DYSTRIP) >>> --- >>> This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently >>> on SVN. >> >> Looks OK for me. >> If OS2 GCC port does not need at least one .o/.obj file (in my Linux box >> it doesn't) then it should work and resolve the problem without direct >> call to LD. >> >> Maurilio or David, Can you check it? >> >> best regards, >> Przemek >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > > -- > __ > | | | |__| Maurilio Longo > |_|_|_|| farmaconsult s.r.l. > > > ___ > 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
[Harbour] SF.net SVN: harbour-project:[13961] trunk/harbour
Revision: 13961 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13961&view=rev Author: vszakats Date: 2010-02-22 16:24:59 + (Mon, 22 Feb 2010) Log Message: --- 2010-02-22 17:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_hbdbfmodel.cpp * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp * contrib/hbqt/hbqt_hbqtableview.cpp * contrib/hbqt/hbqt_hbevents.cpp * contrib/hbqt/hbqt_destruct.cpp * contrib/hbqt/hbqt_utils.cpp * contrib/hbqt/hbqt_hbqmainwindow.cpp * contrib/hbqt/hbqt_hbqplaintextedit.cpp * contrib/hbqt/hbqt_base.cpp * contrib/hbqt/hbqt_hbslots.cpp * Cleaned header inclusion order after adding hbapi.h to hbqt.h. * config/os2/gcc.mk ! Fixed to use '-Wl,' trick proposed by Przemek, to forward obj list script filename directly to linker. This gets around the problem where gcc tries to pass expanded scripts to subprocesses (ld) via cmdline, thus imposing a 32K limit also to script files. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/os2/gcc.mk trunk/harbour/contrib/hbqt/hbqt_base.cpp trunk/harbour/contrib/hbqt/hbqt_destruct.cpp trunk/harbour/contrib/hbqt/hbqt_hbdbfmodel.cpp trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.cpp trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp trunk/harbour/contrib/hbqt/hbqt_hbqtableview.cpp trunk/harbour/contrib/hbqt/hbqt_hbslots.cpp trunk/harbour/contrib/hbqt/hbqt_utils.cpp This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
Viktor, I'm not aware of such a macro, in the last twenty years, at least, OS/2 APIs didn't change, so maybe there was not such a need and TCPV40HDRS was introduced for one of the very few, if not the only one, subsystems to change APIs during all those years. Maurilio. Viktor Szakáts wrote: >> Viktor, >> >> I'd say a ver command should return a version >= 4.00 >> >> (E:\harbour\ftpd)ver >> >> The Operating System/2 Version is 4.50 > > That tells us the host OS version. We need > a way to tell the version of OS/2 we're > building _for_ though. Similar to _WIN32_WINNT > macro. > > Such macro may have some default defined > by headers, and it's also possible to > override it by user. This is the generic way > to force a build which targets and older > version of the OS environment (or even > newer, if the default is an older version). > >> The issue, though, is not when building on a warp 3 system, but trying to use >> a program built without this option on a warp 3 system. More or less like >> running the code to find out interface addresses on a win95 pc, because such >> a >> program requires libraries not available on and for warp 3. > > (pls see above) > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: Harbour 13945
Viktor: >> And is using .obj in OMF type, as usual: >> E:/usr/lib/dll0.obj >> >> OBJ_EXT are forced to .o >Forced. I have to tell you that I can't remember >the whole lengthy discussion before implementing >this the way it is now, but since it takes near >zero effort to switch to .obj in .mk files, .o >is used consistently in build/hbmk2, and since >you didn't report any problems with any of the >discussed gcc versions, I must assume we settled >for .o for good reason. Also note I don't personally >mind what extension does gcc actually requires. >Now it's "forced". >If current state is suddenly wrong for whatever >reasons, tell clearly what happened in between, >and what you suggest now for a solution. The reason was hbmk2 feature: "you lose the option to build multiple .c input files" You can check "OS/2: hbmk2" messages, for example Re: OS/2: hbmk2 5/11/09 04:59 AM is included below .obj is for OMF type a "convention" in OS/2 world, as .lib does too gcc -v show this convention in use of: E:/usr/lib/dll0.obj in OMF type and E:/usr/lib/dll0.o in a.out type Until today Harbour and hbmk2 work fine using .o, but we must remember .obj in OMF when using other object files which not belong to Harbour David Macias Viktor: >So in Harbour we try to force some alien extension instead >of .o which is the default extension in both OMF and a.out >modes. >> Solution is clear: sync use of object extension in both phases >I know. However I don't like this approach. Speaking >of both Harbour build and hbmk2, we use the default >extensions for all supported compilers. >For some reason this was violated by using .obj for >gccomf. Not being an OS/2 user this wasn't apparent >to me, I used what I saw. >Using non-default extensions have some drawbacks, >since you need tell each tool your extension of choice. >In case of gcc, this is -o, however in this mode, >you lose the option to build multiple .c input files >at one pass. Which in turn makes performance much >worse in certain cases. Plus it introduces an exception >in both hbmk2 and Harbour build. Latter isn't affected >too much as it doesn't use optimized calls to compiler >using multiple inputs, but in hbmk2 this would need >some extra logic to handle this exception case. >For a peace of mind and "standardness", I vote to follow >compiler defaults, whatever these are. No need to fight >what GCC developers have decided on. With the case of .obj, >we're trying to mimic other OS/2 compilers doesn't seem like >a good idea. >I could sure spend a few hours on it, but 1) I don't >have time for it now 2) This would create an >unprecedented exception for gccomf, which I don't think >is a good idea on the long run (it has to be maintained). >+1) Since this is not the default in GCC, I assume they >had a good reason to make this decision, and any >3rd party tool is better not reinvent the wheel >since it may just cause problems down the road. >Once GCC OS/2 porters decide to switch to other >extension, we can follow suit. >The idea is to use as few forced stuff and special >tricks as possible. On some occasions gcc -o _is_ used >even now, but only if inevitable (in -inc mode f.e.). >If .o/.a is unusual for OS/2-OMF, the best place to >complain is GCC OS/2 developers. Due origin from a.out type only, for gcc .obj, .lib, -Zomf, EMXOMFLD_TYPE, EXOMFLD_LINKER are aliens but they are well known and accepted in OS/2 environment Remember, os2gcc work with their own aliens and they should be well managed/applied Other aliens for gcc in OS/2 are: -Zcrtdll, -Zdll, -Zexe, -Zhigh-mem, -Zlinker, -Zmap, -Zno-autoconv, -Zautoconv, -Zargs-wild, -Zargs-resp, -Zdll-search, -Zsym, -Zhigh-low -Zno-fork, -Zno-unix, -Zbin-files, -Zbsd-signals, -Zmt, -Zmtd, -Zmts -Zno-rte, -Zsmall-conv, -Zstack, -Zso, -Zsys, -Zsysv-signals EMXOMFLD_RC_TYPE, EMXOMFLD_RC emxomfar.exe, emxomfld.exe, emxomf* family I do not understand next two: * _wildcard (int *argc, char ***argv): Same as in EMX, i.e. it expands it's arguments like a unix shell would do (but OS/2 cmd.exe doesn't), so you typically want to use this when porting a unix command line application. Instead of adding this to a program, compilation with -Zargs-wild can be used. * _response (int *argc, char ***argv): Same as in EMX. Expand response files (@FILENAME). The FILENAME contains a list of arguments, one per line. Arguments enclosed in double quotes will not be expanded. If a response file can not be opened, the argument is kept the same. -Zargs-resp will automatically compile this in. I reported one error with hbmk2.exe in os2gcc-OMF and now we know is due hbmk2.prg are not managing our own object file extension and are relying in default C compiler extensions Use of .obj just exploited this situation Is not case of os2gcc-OMF. Any other user may found the problem if change object file extension for own purposes I understand clearly because you explained it, this situation exist
Re: [Harbour] SF.net SVN: harbour-project:[13961] trunk/harbour
Viktor, just to know, what does -Wl really mean to the compiler? Best regards. Maurilio. vszak...@users.sourceforge.net wrote: > Revision: 13961 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13961&view=rev > Author: vszakats > Date: 2010-02-22 16:24:59 + (Mon, 22 Feb 2010) > > Log Message: > --- > 2010-02-22 17:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbqt/hbqt_hbdbfmodel.cpp > * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp > * contrib/hbqt/hbqt_hbqtableview.cpp > * contrib/hbqt/hbqt_hbevents.cpp > * contrib/hbqt/hbqt_destruct.cpp > * contrib/hbqt/hbqt_utils.cpp > * contrib/hbqt/hbqt_hbqmainwindow.cpp > * contrib/hbqt/hbqt_hbqplaintextedit.cpp > * contrib/hbqt/hbqt_base.cpp > * contrib/hbqt/hbqt_hbslots.cpp > * Cleaned header inclusion order after adding hbapi.h to hbqt.h. > > * config/os2/gcc.mk > ! Fixed to use '-Wl,' trick proposed by Przemek, to forward obj list > script filename directly to linker. > This gets around the problem where gcc tries to pass expanded > scripts to subprocesses (ld) via cmdline, thus imposing a 32K > limit also to script files. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/config/os2/gcc.mk > trunk/harbour/contrib/hbqt/hbqt_base.cpp > trunk/harbour/contrib/hbqt/hbqt_destruct.cpp > trunk/harbour/contrib/hbqt/hbqt_hbdbfmodel.cpp > trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqtableview.cpp > trunk/harbour/contrib/hbqt/hbqt_hbslots.cpp > trunk/harbour/contrib/hbqt/hbqt_utils.cpp > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13961] trunk/harbour
Hi Maurilio, > just to know, what does -Wl really mean to the compiler? It means to pass the option (without '-Wl,' prefix) directly to the linker subprocess. It's like -ldflags= option in hbmk2. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13961] trunk/harbour
vszakats wrote: > > Revision: 13961 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13961&view=rev > Author: vszakats > Date: 2010-02-22 16:24:59 + (Mon, 22 Feb 2010) > > Log Message: > --- > 2010-02-22 17:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbqt/hbqt_hbdbfmodel.cpp > * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp > * contrib/hbqt/hbqt_hbqtableview.cpp > * contrib/hbqt/hbqt_hbevents.cpp > * contrib/hbqt/hbqt_destruct.cpp > * contrib/hbqt/hbqt_utils.cpp > * contrib/hbqt/hbqt_hbqmainwindow.cpp > * contrib/hbqt/hbqt_hbqplaintextedit.cpp > * contrib/hbqt/hbqt_base.cpp > * contrib/hbqt/hbqt_hbslots.cpp > * Cleaned header inclusion order after adding hbapi.h to hbqt.h. > Thank you. On WinXP everything builds fine and runs as before. Should I upload .cpp sources or we wait for David to to more tests on OS ? - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13961-trunk-harbour-tp4613241p4613380.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13957] trunk/harbour
marco bra wrote: > > Hbide from rev. 13957 playing with Document Viewer Dock > > i set as Harbour installation root "/home/ubuntu/src/harbour" and i live > the > "doc folder prefix" empty pressing the green upper row i get this runtime > error > > Unrecoverable error 6005: Exception SIGSEGV at address 0x5d > Called from QT_QTREEWIDGET_SETCURRENTITEM(0) > Called from QTREEWIDGET:SETCURRENTITEM(0) in ../../../TQTreeWidget.prg > Called from IDEHARBOURHELP:EXECEVENT(428) in ideharbourhelp.prg > Called from (b)IDEHARBOURHELP_INSTALLSIGNALS(336) in ideharbourhelp.prg > Called from QT_QEVENTLOOP_PROCESSEVENTS(0) > Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg > Called from APPEVENT(0) in ../../../xbpgeneric.prg > Called from HBIDE:CREATE(417) in hbide.prg > Called from MAIN(110) in hbide.prg > This is strange error as this line is guarded against such action. Can you exactly send step-by-step actions toy took, including the navigation, to let me understand how I can reproduce it ? I assume, when you run hbIDE, the documentation tree is already populated. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13957-trunk-harbour-tp4611158p4613415.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: hbqt, advances
Hi David Many thanks for your efforts and a valuable fact that you opened a ticket with netlabs. Probably it will pave the way to understand some hidden points where Harbour encounters a GPF without any understandable reason. Also we may get clarified why "delete" operator is not called when an object is destroyed. Though it is future, your effort has shown that Qt support cares for these issues, if they are approached. > 2) Pritpal: > 1. Add #ifndef QT_NO_PRINTER / #endif around the parts in the source > code that use printing classes (QAbstractPrintDialog, QPageSetupDialog > etc.) This btw will let it build on all platforms that don't provide > printing support for some reason, not only OS/2. > > 3) Pritpal: > #ifndef QT_NO_ACCESSIBILITY / #endif around the places that complain > about missing accessibility methods. > > Below are text with relevant facts of tests, info, responses, ... > > Qt for OS/2 (4.6.1) will be available soon, with printer support using > CUPS > It will be extremely difficult if not impossible. The reason is, Qt wrappers are generated dynamically and no developer's tweaking is enabled in them. This is only possible if I re-write the generator with OS problem in mind, which I am not aware at all. The other solution could be to write overloading wrappers to these functions in a .cpp, say, hbqt_hbos.cpp, which is included per OS basis. As Qt has announced that in 4.6.2 they will provide, we should wait till then. No? - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/OS-2-hbqt-advances-tp4611775p4613521.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13961] trunk/harbour
Which is the function of hbdbfmodel class ? Bruno 2010/2/22 > Revision: 13961 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13961&view=rev > Author: vszakats > Date: 2010-02-22 16:24:59 + (Mon, 22 Feb 2010) > > Log Message: > --- > 2010-02-22 17:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbqt/hbqt_hbdbfmodel.cpp > * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp > * contrib/hbqt/hbqt_hbqtableview.cpp > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
