From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 2 Dec 2002 04:42:32 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 386 ************************************************** Sunday 01 December 2002 Number 386 ************************************************** Subjects for today 1 Re: wxOS2 : Ken Ames 2 Re: wxOS2 : Stefan Neis 3 RE: wxWindows-2.3.4 : Dave Webster 4 RE: wxWindows-2.3.4 : Dave Webster 5 Re: os2-unix list is now also hosted via news : email at eracc.hypermart.net (ERACC Lists) 6 os2-unix list is now also hosted via news : Robert_K_Cook at comerica.com 7 Re: wxWindows-2.3.4 : Ken Ames 8 Sendmail v8.12.3 : John Poltorak 9 RE: wxWindows-2.3.4 : Dave Webster 10 Re: wxOS2 : Stefan Neis 11 RE: wxWindows-2.3.4 : Hakan" 12 Re: wxWindows-2.3.4 : Ken Ames 13 RE: wxWindows-2.3.4 : Dave Webster 14 Re: config.site : Ted Sikora 15 RE: wxWindows-2.3.4 : Dave Webster 16 RE: wxWindows-2.3.4 : Hakan" 17 Re: wxWindows-2.3.4 : Ken Ames 18 Procmail : John Poltorak 19 Re: wxWindows-2.3.4 : Ken Ames 20 RE: wxWindows-2.3.4 : Dave Webster 21 Re: wxOS2 : Yuri Dario" 22 Re: os2-unix list is now also hosted via news : John Poltorak 23 Re: os2-unix list is now also hosted via news : John Poltorak 24 Re: wxWindows-2.3.4 : Ken Ames 25 RE: wxWindows-2.3.4 : Dave Webster 26 RE: wxWindows-2.3.4 : Hakan" 27 RE: wxWindows-2.3.4 : Dave Webster 28 RE: wxWindows-2.3.4 : Hakan" 29 RE: wxWindows-2.3.4 : Steve Wendt 30 RE: wxWindows-2.3.4 : Steve Wendt 31 Re: wxWindows-2.3.4 : Ken Ames **= Email 1 ==========================** Date: Mon, 02 Dec 2002 00:08:19 -0800 From: Ken Ames Subject: Re: wxOS2 hi Stefan, so you use gcc then? which version? I do need to update my gcc build env. since it is still at version 2.81 and I do not want to do that more then once. Thanks. Ken Stefan Neis wrote: >On Sun, 1 Dec 2002, Ken Ames wrote: > > > >>ok, did not get much of a response in wxwindows developers group so here >>it is. anyone know how to fix this problem? >> >> > >Actually, I never used VAC++, so I have no idea what's going on, but I >hope David will find some time to look at this ... > > Regards, > Stefan > > **= Email 2 ==========================** Date: Mon, 2 Dec 2002 00:45:01 +0100 (CET) From: Stefan Neis Subject: Re: wxOS2 On Sun, 1 Dec 2002, Ken Ames wrote: > ok, did not get much of a response in wxwindows developers group so here > it is. anyone know how to fix this problem? Actually, I never used VAC++, so I have no idea what's going on, but I hope David will find some time to look at this ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Mon, 2 Dec 2002 08:03:12 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 Users might see the VA4 build files in the distribution but I abandoned maintaining those about a year or so ago. Maintenance of VA 4 compilable code was a real nightmare and since that is now a dead product I didn't see the merit in putting any more effort into maintaining it. -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Thursday, November 28, 2002 7:34 AM To: os2-unix at eyup.org Subject: Re: wxWindows-2.3.4 On Thu, 28 Nov 2002, Adrian Gschwend wrote: > you are using GCC to compile it right? I tried with VAC some month ago > but it failed (can't remember where, didn't had the time to check it > more). Exactly. VAC++ 3 (which is what David who is doing all the work is using) should work just as well (or even better), while VAC++ 4 is a real problem... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Mon, 2 Dec 2002 08:07:52 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 Unfortunately I synched up my latest OS/2 code just AFTER they cut the 2.3.4 snapshot and missed getting that into the Setup.h file. There was also a needed fix to intl.cpp in /common that doesn't look like it made it in time. I finally freed up enough time this past week to check on the compilability of the code for the first time in over a month and looks like I was about a day late. Users need to read the installation instructions before building with VA 3.0 FP 8 as you need to set some environment variables to point to your specific installation of the OS2 toolkit and such... -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Saturday, November 30, 2002 5:36 AM To: os2-unix at eyup.org Subject: Re: wxWindows-2.3.4 On Fri, 29 Nov 2002, Ken Ames wrote: > well, another release that won't build. bombs out on the first file it > tries to compile. This and what errors I had building 2.3.3 seem like > things that would or should be handled way before any release is thought > of. I hope it gets fixed soon. > > copy "X:\WXWINDOWS-2.3.4"\include\wx\os2\setup.h > "X:\WXWINDOWS-2.3.4"\include\wx\setup.h > 1 file(s) copied. > > X:\WXWINDOWS-2.3.4\include\wx\chkconf.h(100:9) : error EDC3086: > "wxUSE_PROLOGIOmust be defined." > X:\WXWINDOWS-2.3.4\include\wx\chkconf.h(1189:9) : error EDC3086: "wxr > resources require PrologIO" > NMAKE : fatal error U1077: 'G:\OS2\CMD.EXE' : return code '12' > Stop. Sh*t! We don't start from the "raw"distribution often enough, it seems. "setup.h" (the one you copied above) needs to include the extra line #define wxUSE_PROLOGIO 1 It's somewhat amazing that it ever build without it, until there's been a consistency check which flags it as an error when it's not defined... Thanks for finding and reporting, Stefan P.S.: wx-dev at lists.wxwindows.org might be slightly more appropriate for such stuff (and it would also make realize others that OS/2 actually does exist). -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 5 ==========================** Date: Mon, 02 Dec 2002 08:54:41 -0600 From: email at eracc.hypermart.net (ERACC Lists) Subject: Re: os2-unix list is now also hosted via news In: <20021202143338.H88 at eyup.org> On: Mon, 2 Dec 2002 14:33:38 +0000 Screaming: Re: os2-unix list is now also hosted via news John Poltorak did rant: +On Mon, Dec 02, 2002 at 09:22:11AM -0500, Robert_K_Cook at comerica.com +wrote: > gmane.org, a spamfree news<->mail gateway is now includes +os2-unix. > +> It is listed under gmane.comp.porting.unix-to-os2 +> +> All future posts will archived there or you can access posts via your +> newsreader/web browser. +> +> Just add a new server: news://news.gmane.org/ + + +What exactly is this? +I'm not sure that this is something we want. +Does anyone else have a view on this? I thought there were already one or two places where this list is archived. Yup. I just looked in my saved messages for the list and found reference to: http://www.eyup.org (from you, John) and http://borneo.gmd.de/~veit/os2/unixsearch.html (from Holger V.) I think having a couple of lines on each list message that refers to these archives may be useful. Something like: List archive: http://www.eyup.org List archive: http://borneo.gmd.de/~veit/os2/unixsearch.html Perhaps another way to archive the list won't hurt. I don't see how anyone could post to the news server though and get the benefits of the list user replies unless the list maintainer and the news server host collaborate to make it work. To me it is not apparent that happened. ;-) Gene -- +=========================-=>Unix & OS/2<=-=========================+ # Owner and C.E.O. - ERA Computer Consulting - Jackson, TN USA # # eCS,OS/2,UnixWare,OpenServer & Linux Business Computing Solutions # # Please visit our www pages at http://eracc.hypermart.net/ # +===================================================================+ We run IBM OS/2 v.4.00, Revision 9.036 Sysinfo: 41 Processes, 161 Threads, uptime is 12d 8h 47m 3s 465ms **= Email 6 ==========================** Date: Mon, 2 Dec 2002 09:22:11 -0500 From: Robert_K_Cook at comerica.com Subject: os2-unix list is now also hosted via news gmane.org, a spamfree news<->mail gateway is now includes os2-unix. It is listed under gmane.comp.porting.unix-to-os2 All future posts will archived there or you can access posts via your newsreader/web browser. Just add a new server: news://news.gmane.org/ **= Email 7 ==========================** Date: Mon, 02 Dec 2002 09:53:16 -0800 From: Ken Ames Subject: Re: wxWindows-2.3.4 hi Dave, Dave Webster wrote: >Unfortunately I synched up my latest OS/2 code just AFTER they cut the 2.3.4 >snapshot and missed getting that into the Setup.h file. There was also a >needed fix to intl.cpp in /common that doesn't look like it made it in time. >I finally freed up enough time this past week to check on the compilability >of the code for the first time in over a month and looks like I was about a >day late. > > glad to hear you got a bit of free time. I did read the and follow the installation instructions regarding vac3 fp8 which is what I am using. set the environment variables just as it said. Although I have VAC 3.6.5 and VAC 4.0 here, I do not use them because the readme.os2 says vac 3.08. Thanks. Ken >Users need to read the installation instructions before building with VA 3.0 >FP 8 as you need to set some environment variables to point to your specific >installation of the OS2 toolkit and such... > >-----Original Message----- >From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >Sent: Saturday, November 30, 2002 5:36 AM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > >On Fri, 29 Nov 2002, Ken Ames wrote: > > > >>well, another release that won't build. bombs out on the first file it >>tries to compile. This and what errors I had building 2.3.3 seem like >>things that would or should be handled way before any release is thought >>of. I hope it gets fixed soon. >> >> copy "X:\WXWINDOWS-2.3.4"\include\wx\os2\setup.h >> >> > > > >>"X:\WXWINDOWS-2.3.4"\include\wx\setup.h >> 1 file(s) copied. >> >>X:\WXWINDOWS-2.3.4\include\wx\chkconf.h(100:9) : error EDC3086: >>"wxUSE_PROLOGIOmust be defined." >>X:\WXWINDOWS-2.3.4\include\wx\chkconf.h(1189:9) : error EDC3086: "wxr >>resources require PrologIO" >>NMAKE : fatal error U1077: 'G:\OS2\CMD.EXE' : return code '12' >>Stop. >> >> > >Sh*t! >We don't start from the "raw"distribution often enough, it seems. >"setup.h" (the one you copied above) needs to include the extra >line >#define wxUSE_PROLOGIO 1 >It's somewhat amazing that it ever build without it, until there's been >a consistency check which flags it as an error when it's not defined... > > Thanks for finding and reporting, > Stefan > >P.S.: wx-dev at lists.wxwindows.org might be slightly more appropriate for > such stuff (and it would also make realize others that OS/2 > actually does exist). > > **= Email 8 ==========================** Date: Mon, 2 Dec 2002 10:36:32 +0000 From: John Poltorak Subject: Sendmail v8.12.3 Is anyone using Sendmail v8.12.3 instead of IBM's Sendmail for OS/2? If so, I could do with some tips to get it up and running properly... -- John **= Email 9 ==========================** Date: Mon, 2 Dec 2002 11:13:02 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 It has to do with the usage of a codestore and the way headers, global constants, and statics are coded in the library interplay witht he codestore. It is a near impossible tangle of dependencies and constructs that render a VA 4 wxWindows project virtually unmaintainable. Then there are the samples and demos, which are separately mintained from the library itself, which for use under VA 4 have to be part of the codestore to be debugged. wxWindows is a classic makefile style project and is NOT coded to deal with the concept of codestores. Added in with the fact that VA 4 itself, with the its only fixpack, is still a grossly buggy mess and IBM has cancelled future support for it on OS/2 that makes time spent trying to coax an Open Source project to compatitability with it's completely non-traditional model, a waste of time and effort. -----Original Message----- From: Hakan [mailto:agents at meddatainc.com] Sent: Monday, December 02, 2002 10:39 AM To: os2-unix at eyup.org Subject: RE: wxWindows-2.3.4 Dave, Can you tell us what the compatibility problems were? I am currently using VAC++ 4 for one of my own projects, mainly, but not solely, due to its greater conformance with standard C++, and would surely be interested in knowing what the issues are with respect to the code for vxWindows. Thanks. Hakan On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >Users might see the VA4 build files in the distribution but I abandoned >maintaining those about a year or so ago. Maintenance of VA 4 compilable >code was a real nightmare and since that is now a dead product I didn't see >the merit in putting any more effort into maintaining it. > >-----Original Message----- >From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >Sent: Thursday, November 28, 2002 7:34 AM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > >On Thu, 28 Nov 2002, Adrian Gschwend wrote: > >> you are using GCC to compile it right? I tried with VAC some month ago >> but it failed (can't remember where, didn't had the time to check it >> more). > >Exactly. VAC++ 3 (which is what David who is doing all the work is using) >should work just as well (or even better), while VAC++ 4 is a real >problem... > > Regards, > Stefan >-- >Micro$oft is not an answer. It is a question. The answer is 'no'. > > > **= Email 10 ==========================** Date: Mon, 2 Dec 2002 11:34:44 +0100 (CET) From: Stefan Neis Subject: Re: wxOS2 On Mon, 2 Dec 2002, Ken Ames wrote: > hi Stefan, > so you use gcc then? which version? I do need to update my gcc build > env. since it is still at version 2.81 That's what I'm also still using. I prefer to keep out of all those problems with the version specific name mangling that we did see for the so called "gcc-2.96", for gcc-3.0, 3.1, 3.2. First let the dust settle over all those changes, and then update once (hoping, there _will_ be an OS/2 port of the "final" version). > and I do not want to do that more > then once. Thanks. Same feeling here ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 11 ==========================** Date: Mon, 02 Dec 2002 11:39:09 -0500 (EST) From: "Hakan" Subject: RE: wxWindows-2.3.4 Dave, Can you tell us what the compatibility problems were? I am currently using VAC++ 4 for one of my own projects, mainly, but not solely, due to its greater conformance with standard C++, and would surely be interested in knowing what the issues are with respect to the code for vxWindows. Thanks. Hakan On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >Users might see the VA4 build files in the distribution but I abandoned >maintaining those about a year or so ago. Maintenance of VA 4 compilable >code was a real nightmare and since that is now a dead product I didn't see >the merit in putting any more effort into maintaining it. > >-----Original Message----- >From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >Sent: Thursday, November 28, 2002 7:34 AM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > >On Thu, 28 Nov 2002, Adrian Gschwend wrote: > >> you are using GCC to compile it right? I tried with VAC some month ago >> but it failed (can't remember where, didn't had the time to check it >> more). > >Exactly. VAC++ 3 (which is what David who is doing all the work is using) >should work just as well (or even better), while VAC++ 4 is a real >problem... > > Regards, > Stefan >-- >Micro$oft is not an answer. It is a question. The answer is 'no'. > > > **= Email 12 ==========================** Date: Mon, 02 Dec 2002 11:59:41 -0800 From: Ken Ames Subject: Re: wxWindows-2.3.4 Dave Webster wrote: >There are icc files for an OS/2 build on the CVS tree, still. You are >welcome to download them and fiddle with them if you desire. They worked >quite well once upon a time. > > vac 3 with fixpak 8 applied is what I have been trying to use. I guess you want me to use gcc so I will. :) they seem to work rather inconsistent now. Yuri Dario says my latest error looks like an ilib bug and I agree. >The single biggest bug on VA4 is it's HUGE memory leak. On a system with >128MB ram the wx build generates and OS/2 swap file over 256MB large. On >smaller systems, it just crashes on every build. There are, at time of IBM >dropping support, over 1000 APARS against this version covering various >issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >that didn't otherwise get it for free? > I have it, bought it from mensys, dont use it, crashes too much and generates some bad code. > >It is also an enormous CPU and memory hog. Don't even try using it on a >system less than PIII650 with less than 256MB ram. A lot of OS/2 users have >much smaller systems than that. While I have no problem with VA 3.0 FP8 on >a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >selling features left for OS/2 or eCS is it's very small footprint, even for >developers. > >VA4 is definitely on the cutting edge of C++ standards and development >environment. In fact, it probably too far ahead for comfort. Its technical >superiority is not enough to overcome the enormous inertia behind the >traditional header/makefile build paradigm. And of course, it's most fatal >flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >debugged, product, even if discontinued. > >I just wish Watcom could get up to snuff. As it is, it is not even as good >as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >fully impelemented stl library. But the codestore is a concept whose time >is still YEARS away from being accepted by the masses. > watcom is coming along. c++ compiler is a topic of discussion lately. seems they are going to start on it soon (I hope). > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 12:23 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave (and others), > >While I initially had problems with the codestore concept I am now able >to work with it vs. against it. It is, however, a pity that version 4 >does not have the config option added to version 5 of the compiler for >AIX to disable "orderless compile" and thus maintain compatibility with >conventionally structured source code. With that said, it is still >possible to have a VAC++ 4 ICC file (config file) which allows you to >maintain conventionally structured code with all their #include >statements and the code can compile on both VAC++ 4 and traditional >compilers. > >You are referring to a "grossly buggy mess" with respect to VAC++ -- >can you elaborate? While I have certainly come across problems with >the IDE itself where it throws exceptions etc (closing the IDE and >relaunching it takes care of that problem) I have yet to come across >any code generation problems. I know that the version 4 of the >compiler also comes with a command-line version of the compiler and >other tools which I *assume* is what is being used by the IDE itself >and thus should be as conformant as the IDE version. > >Again, what attracted me to VAC++ 4 was for starters conformance with >standard C++. While I am certain it may not be 100% compliant, I do >not yet know where it falls short -- I simply have not pushed it that >far yet. On that topic, how compliant is the latest version of gcc? > >BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler >together with Aaron Lawrence's excellent replacement for view.exe, >NewView.exe, to view the toolkit documentation. > >I am certainly interested in hearing the opinions of others as well >when it comes to VAC++ vs. other compilers knowing full well that VAC++ >is no longer supported by IBM. > >Hakan > >On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: > > > >>It has to do with the usage of a codestore and the way headers, global >>constants, and statics are coded in the library interplay witht he >>codestore. It is a near impossible tangle of dependencies and constructs >>that render a VA 4 wxWindows project virtually unmaintainable. Then there >>are the samples and demos, which are separately mintained from the library >>itself, which for use under VA 4 have to be part of the codestore to be >>debugged. wxWindows is a classic makefile style project and is NOT coded >> >> >to > > >>deal with the concept of codestores. >> >>Added in with the fact that VA 4 itself, with the its only fixpack, is >>still a grossly buggy mess and IBM has cancelled future support for it on >>OS/2 that makes time spent trying to coax an Open Source project to >>compatitability with it's completely non-traditional model, a waste of time >>and effort. >> >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Monday, December 02, 2002 10:39 AM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows-2.3.4 >> >> >>Dave, >> >>Can you tell us what the compatibility problems were? I am currently >>using VAC++ 4 for one of my own projects, mainly, but not solely, due >>to its greater conformance with standard C++, and would surely be >>interested in knowing what the issues are with respect to the code for >>vxWindows. >> >>Thanks. >> >>Hakan >> >>On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >> >> >> >>>Users might see the VA4 build files in the distribution but I abandoned >>>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>>code was a real nightmare and since that is now a dead product I didn't >>> >>> >see > > >>>the merit in putting any more effort into maintaining it. >>> >>>-----Original Message----- >>>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>>Sent: Thursday, November 28, 2002 7:34 AM >>>To: os2-unix at eyup.org >>>Subject: Re: wxWindows-2.3.4 >>> >>> >>>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >>> >>> >>> >>>>you are using GCC to compile it right? I tried with VAC some month ago >>>>but it failed (can't remember where, didn't had the time to check it >>>>more). >>>> >>>> >>>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>>should work just as well (or even better), while VAC++ 4 is a real >>>problem... >>> >>> Regards, >>> Stefan >>>-- >>>Micro$oft is not an answer. It is a question. The answer is 'no'. >>> >>> >>> >>> >>> >> >> >> >> > > > > > > **= Email 13 ==========================** Date: Mon, 2 Dec 2002 12:17:43 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 Never tried with VAC 3.6. It should work OK with that. -----Original Message----- From: Ken Ames [mailto:kenames at pacbell.net] Sent: Monday, December 02, 2002 11:53 AM To: os2-unix at eyup.org Subject: Re: wxWindows-2.3.4 hi Dave, Dave Webster wrote: >Unfortunately I synched up my latest OS/2 code just AFTER they cut the 2.3.4 >snapshot and missed getting that into the Setup.h file. There was also a >needed fix to intl.cpp in /common that doesn't look like it made it in time. >I finally freed up enough time this past week to check on the compilability >of the code for the first time in over a month and looks like I was about a >day late. > > glad to hear you got a bit of free time. I did read the and follow the installation instructions regarding vac3 fp8 which is what I am using. set the environment variables just as it said. Although I have VAC 3.6.5 and VAC 4.0 here, I do not use them because the readme.os2 says vac 3.08. Thanks. Ken >Users need to read the installation instructions before building with VA 3.0 >FP 8 as you need to set some environment variables to point to your specific >installation of the OS2 toolkit and such... > >-----Original Message----- >From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >Sent: Saturday, November 30, 2002 5:36 AM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > >On Fri, 29 Nov 2002, Ken Ames wrote: > > > >>well, another release that won't build. bombs out on the first file it >>tries to compile. This and what errors I had building 2.3.3 seem like >>things that would or should be handled way before any release is thought >>of. I hope it gets fixed soon. >> >> copy "X:\WXWINDOWS-2.3.4"\include\wx\os2\setup.h >> >> > > > >>"X:\WXWINDOWS-2.3.4"\include\wx\setup.h >> 1 file(s) copied. >> >>X:\WXWINDOWS-2.3.4\include\wx\chkconf.h(100:9) : error EDC3086: >>"wxUSE_PROLOGIOmust be defined." >>X:\WXWINDOWS-2.3.4\include\wx\chkconf.h(1189:9) : error EDC3086: "wxr >>resources require PrologIO" >>NMAKE : fatal error U1077: 'G:\OS2\CMD.EXE' : return code '12' >>Stop. >> >> > >Sh*t! >We don't start from the "raw"distribution often enough, it seems. >"setup.h" (the one you copied above) needs to include the extra >line >#define wxUSE_PROLOGIO 1 >It's somewhat amazing that it ever build without it, until there's been >a consistency check which flags it as an error when it's not defined... > > Thanks for finding and reporting, > Stefan > >P.S.: wx-dev at lists.wxwindows.org might be slightly more appropriate for > such stuff (and it would also make realize others that OS/2 > actually does exist). > > **= Email 14 ==========================** Date: Mon, 02 Dec 2002 12:58:50 -0500 From: Ted Sikora Subject: Re: config.site Michael Zolk wrote: > > On Tue, Nov 19, 2002 at 08:41:46AM -0500, tsikora at ntplx.net wrote: > > > On another note. A line should be added to installpkg/removepkg to > > delete the contents of the /install directory after an install. It's > > annoying getting the pop-up for duplicates everytime a new package is > > installed. > > Is it an unzip error message? When does it occur? > -- No when you install a pkg the contents from the previous pkg install stay in /install then when a new package is installed the unzip 'save del overwrite, etc.' message comes up because duplicate files exist. -- Ted Sikora tsikora at ntplx.net **= Email 15 ==========================** Date: Mon, 2 Dec 2002 13:17:51 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 There are icc files for an OS/2 build on the CVS tree, still. You are welcome to download them and fiddle with them if you desire. They worked quite well once upon a time. The single biggest bug on VA4 is it's HUGE memory leak. On a system with 128MB ram the wx build generates and OS/2 swap file over 256MB large. On smaller systems, it just crashes on every build. There are, at time of IBM dropping support, over 1000 APARS against this version covering various issues. And at $1800 for a non-supported, buggy product, who'd ever buy it that didn't otherwise get it for free? It is also an enormous CPU and memory hog. Don't even try using it on a system less than PIII650 with less than 256MB ram. A lot of OS/2 users have much smaller systems than that. While I have no problem with VA 3.0 FP8 on a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest selling features left for OS/2 or eCS is it's very small footprint, even for developers. VA4 is definitely on the cutting edge of C++ standards and development environment. In fact, it probably too far ahead for comfort. Its technical superiority is not enough to overcome the enormous inertia behind the traditional header/makefile build paradigm. And of course, it's most fatal flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, debugged, product, even if discontinued. I just wish Watcom could get up to snuff. As it is, it is not even as good as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a fully impelemented stl library. But the codestore is a concept whose time is still YEARS away from being accepted by the masses. -----Original Message----- From: Hakan [mailto:agents at meddatainc.com] Sent: Monday, December 02, 2002 12:23 PM To: os2-unix at eyup.org Subject: RE: wxWindows-2.3.4 Dave (and others), While I initially had problems with the codestore concept I am now able to work with it vs. against it. It is, however, a pity that version 4 does not have the config option added to version 5 of the compiler for AIX to disable "orderless compile" and thus maintain compatibility with conventionally structured source code. With that said, it is still possible to have a VAC++ 4 ICC file (config file) which allows you to maintain conventionally structured code with all their #include statements and the code can compile on both VAC++ 4 and traditional compilers. You are referring to a "grossly buggy mess" with respect to VAC++ -- can you elaborate? While I have certainly come across problems with the IDE itself where it throws exceptions etc (closing the IDE and relaunching it takes care of that problem) I have yet to come across any code generation problems. I know that the version 4 of the compiler also comes with a command-line version of the compiler and other tools which I *assume* is what is being used by the IDE itself and thus should be as conformant as the IDE version. Again, what attracted me to VAC++ 4 was for starters conformance with standard C++. While I am certain it may not be 100% compliant, I do not yet know where it falls short -- I simply have not pushed it that far yet. On that topic, how compliant is the latest version of gcc? BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler together with Aaron Lawrence's excellent replacement for view.exe, NewView.exe, to view the toolkit documentation. I am certainly interested in hearing the opinions of others as well when it comes to VAC++ vs. other compilers knowing full well that VAC++ is no longer supported by IBM. Hakan On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: >It has to do with the usage of a codestore and the way headers, global >constants, and statics are coded in the library interplay witht he >codestore. It is a near impossible tangle of dependencies and constructs >that render a VA 4 wxWindows project virtually unmaintainable. Then there >are the samples and demos, which are separately mintained from the library >itself, which for use under VA 4 have to be part of the codestore to be >debugged. wxWindows is a classic makefile style project and is NOT coded to >deal with the concept of codestores. > >Added in with the fact that VA 4 itself, with the its only fixpack, is >still a grossly buggy mess and IBM has cancelled future support for it on >OS/2 that makes time spent trying to coax an Open Source project to >compatitability with it's completely non-traditional model, a waste of time >and effort. > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 10:39 AM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave, > >Can you tell us what the compatibility problems were? I am currently >using VAC++ 4 for one of my own projects, mainly, but not solely, due >to its greater conformance with standard C++, and would surely be >interested in knowing what the issues are with respect to the code for >vxWindows. > >Thanks. > >Hakan > >On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: > >>Users might see the VA4 build files in the distribution but I abandoned >>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>code was a real nightmare and since that is now a dead product I didn't see >>the merit in putting any more effort into maintaining it. >> >>-----Original Message----- >>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>Sent: Thursday, November 28, 2002 7:34 AM >>To: os2-unix at eyup.org >>Subject: Re: wxWindows-2.3.4 >> >> >>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >> >>> you are using GCC to compile it right? I tried with VAC some month ago >>> but it failed (can't remember where, didn't had the time to check it >>> more). >> >>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>should work just as well (or even better), while VAC++ 4 is a real >>problem... >> >> Regards, >> Stefan >>-- >>Micro$oft is not an answer. It is a question. The answer is 'no'. >> >> >> > > > > **= Email 16 ==========================** Date: Mon, 02 Dec 2002 13:23:01 -0500 (EST) From: "Hakan" Subject: RE: wxWindows-2.3.4 Dave (and others), While I initially had problems with the codestore concept I am now able to work with it vs. against it. It is, however, a pity that version 4 does not have the config option added to version 5 of the compiler for AIX to disable "orderless compile" and thus maintain compatibility with conventionally structured source code. With that said, it is still possible to have a VAC++ 4 ICC file (config file) which allows you to maintain conventionally structured code with all their #include statements and the code can compile on both VAC++ 4 and traditional compilers. You are referring to a "grossly buggy mess" with respect to VAC++ -- can you elaborate? While I have certainly come across problems with the IDE itself where it throws exceptions etc (closing the IDE and relaunching it takes care of that problem) I have yet to come across any code generation problems. I know that the version 4 of the compiler also comes with a command-line version of the compiler and other tools which I *assume* is what is being used by the IDE itself and thus should be as conformant as the IDE version. Again, what attracted me to VAC++ 4 was for starters conformance with standard C++. While I am certain it may not be 100% compliant, I do not yet know where it falls short -- I simply have not pushed it that far yet. On that topic, how compliant is the latest version of gcc? BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler together with Aaron Lawrence's excellent replacement for view.exe, NewView.exe, to view the toolkit documentation. I am certainly interested in hearing the opinions of others as well when it comes to VAC++ vs. other compilers knowing full well that VAC++ is no longer supported by IBM. Hakan On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: >It has to do with the usage of a codestore and the way headers, global >constants, and statics are coded in the library interplay witht he >codestore. It is a near impossible tangle of dependencies and constructs >that render a VA 4 wxWindows project virtually unmaintainable. Then there >are the samples and demos, which are separately mintained from the library >itself, which for use under VA 4 have to be part of the codestore to be >debugged. wxWindows is a classic makefile style project and is NOT coded to >deal with the concept of codestores. > >Added in with the fact that VA 4 itself, with the its only fixpack, is >still a grossly buggy mess and IBM has cancelled future support for it on >OS/2 that makes time spent trying to coax an Open Source project to >compatitability with it's completely non-traditional model, a waste of time >and effort. > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 10:39 AM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave, > >Can you tell us what the compatibility problems were? I am currently >using VAC++ 4 for one of my own projects, mainly, but not solely, due >to its greater conformance with standard C++, and would surely be >interested in knowing what the issues are with respect to the code for >vxWindows. > >Thanks. > >Hakan > >On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: > >>Users might see the VA4 build files in the distribution but I abandoned >>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>code was a real nightmare and since that is now a dead product I didn't see >>the merit in putting any more effort into maintaining it. >> >>-----Original Message----- >>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>Sent: Thursday, November 28, 2002 7:34 AM >>To: os2-unix at eyup.org >>Subject: Re: wxWindows-2.3.4 >> >> >>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >> >>> you are using GCC to compile it right? I tried with VAC some month ago >>> but it failed (can't remember where, didn't had the time to check it >>> more). >> >>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>should work just as well (or even better), while VAC++ 4 is a real >>problem... >> >> Regards, >> Stefan >>-- >>Micro$oft is not an answer. It is a question. The answer is 'no'. >> >> >> > > > > **= Email 17 ==========================** Date: Mon, 02 Dec 2002 13:35:09 -0800 From: Ken Ames Subject: Re: wxWindows-2.3.4 you did not explicitely but did imply or I was imagining. whatever the case but my problem remains. vac 3.0 with fixpak 8 applied will NOT compile wxOS2. I did a cvs update from the cvs server listed on wxWindows home page and got 0 (zero) updated files so, cvs needs repair on their end. either in the readme files or setup postings or whatever. I repeat, I am trying to use VAC 3.0 with fixpak 8 applied and compile does NOT work Dave Webster wrote: >Where did I say gcc? icc (.icc) are VA 4.0 build files not gcc (EMX). >Stefan has a working EMX (gcc) distrubution, but I personally use VA3.0 FP8 >and now have a clean compiling version for both static and dynamic libraries >on the latest CVS tree. You are free to use gcc/EMX or VA 3.0 FP8 against >Os2 toolkit V4.5 or later. Both work just fine. Watcom C++ support is >unknown since neither Stefan nor I use it and no one else has tried it. > > can you point to the latest cvs tree?U mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/panels.rdf U mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/search.rdf checkout finish: Mon Dec 2 11:04:39 pst 2002 Generating configures using autoconf SYS1079: << was unexpected at this time. configure.in:37: error: m4_file_append: cannot write: /tmp/forbidden.rx configure.in:37: the top level gmake.exe[1]: *** [real_checkout] Error 2 gmake.exe[1]: Leaving directory `/' gmake: *** [checkout] Error 2 >-----Original Message----- >From: Ken Ames [mailto:kenames at pacbell.net] >Sent: Monday, December 02, 2002 2:00 PM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > > > >Dave Webster wrote: > > > >>There are icc files for an OS/2 build on the CVS tree, still. You are >>welcome to download them and fiddle with them if you desire. They worked >>quite well once upon a time. >> >> >> >> >vac 3 with fixpak 8 applied is what I have been trying to use. I guess >you want me to use gcc so I will. :) >they seem to work rather inconsistent now. Yuri Dario says my latest >error looks like an ilib bug and I agree. > the last sentence above indicated you wanted me to use gcc. If it is not an ilib bug please tell me. > > > >>The single biggest bug on VA4 is it's HUGE memory leak. On a system with >>128MB ram the wx build generates and OS/2 swap file over 256MB large. On >>smaller systems, it just crashes on every build. There are, at time of IBM >>dropping support, over 1000 APARS against this version covering various >>issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >>that didn't otherwise get it for free? >> >> >> I have a copy of VAC4. I do NOT use it, buggy! no good. crashes, etc.... everyone knows vac4 story - dead end. >I have it, bought it from mensys, dont use it, crashes too much and >generates some bad code. > > > >>It is also an enormous CPU and memory hog. Don't even try using it on a >>system less than PIII650 with less than 256MB ram. A lot of OS/2 users >> >> >have > > >>much smaller systems than that. While I have no problem with VA 3.0 FP8 on >>a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >>selling features left for OS/2 or eCS is it's very small footprint, even >> >> >for > > >>developers. >> >>VA4 is definitely on the cutting edge of C++ standards and development >>environment. In fact, it probably too far ahead for comfort. Its >> >> >technical > > >>superiority is not enough to overcome the enormous inertia behind the >>traditional header/makefile build paradigm. And of course, it's most fatal >>flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >>debugged, product, even if discontinued. >> >>I just wish Watcom could get up to snuff. As it is, it is not even as good >>as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >>we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >>fully impelemented stl library. But the codestore is a concept whose time >>is still YEARS away from being accepted by the masses. >> >> >> >watcom is coming along. c++ compiler is a topic of discussion lately. >seems they are going to start on it soon (I hope). > > > as it stands from here at the moment, wxOS2 is unbuildable with vac3.08 so I am hoping you will supply the missing pieces. please excuse anything that may seem like I am trying to make you angry as I am most definitly NOT trying to do that. I am simply trying to get a cross platform solution in place here. wxOS2 has been far to long in coming but I realize you are a busy man and still must make a living. Ken **= Email 18 ==========================** Date: Mon, 2 Dec 2002 13:40:16 +0000 From: John Poltorak Subject: Procmail Has anyone tried building a recent version of Procmail on OS/2? -- John **= Email 19 ==========================** Date: Mon, 02 Dec 2002 13:55:38 -0800 From: Ken Ames Subject: Re: wxWindows-2.3.4 hi Dave, Dave Webster wrote: >I have to support the most popular environment for my platform that I can >due to the very limited amount of time I have to devote to wxWindows. (My >day job is writing financial management and telephony switches for nonStop >Guardian, HPUX and WIN32 servers). > >That means VA 3.x and EMX. Stefan does the EMX and I do VA 3.0. You are >the first person I've ever run accross that actually still uses VA 4.0 after >IBM dumped it. And I cannot afford the time needed to make the constant >adjustments to support codestore based development. > I am sorry and I do not know how you got the impression I am using VAC4 but I am not. Hakan says he does. I use VAC 3.08 and that is the environment where my build is failing. You have a building tree on vac3.08 and this is what I would like. Ken > >My current machine is PIV 2.4 GHZ with 1GB ram but VA 4.0 is still a non >starter for me for its need to have a lot of special additions to the wx >codebase to make it compile. > >Like I said, I have old .icc file that used to work. If you wish to become >involved in wxWindows and support VA 4.0, you are free to do so. Otherwise, >it won't happen. > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 2:23 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave, > >My interest was in your experience with VAC++ applied to vxWindows or >to other projects. I am actually beginning to write my own class >library for PM, for my own use. My library is heavily influenced by >IBM's class libraries, both the version which came with CSet 2.1 and >the newer one delivered with VAC++ 4, libraries I believe are very well >designed. > > > >>The single biggest bug on VA4 is it's HUGE memory leak. On a system with >>128MB ram the wx build generates and OS/2 swap file over 256MB large. On >>smaller systems, it just crashes on every build. There are, at time of IBM >>dropping support, over 1000 APARS against this version covering various >>issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >>that didn't otherwise get it for free? >> >> > >My development machine is a PPro machine with four processors, each >running at 200 MHz, and with 1Gb memory. VAC++ is very snappy and >responsive on this machine and compiles are very quick (my projects are >still very small, though.) This machine, bought on eBay two years ago >for approx. $1000, was probably used as a server but is great for >development, especially since I run WSEB SMP and use the SciTech >display drivers. With that amount of memory I have not seen any use of >swap files and the amount of available memory never goes below 700K. > >Where can I find the APAR list? I fhink one has to separate APARs >against the compiler, against the IDE environment, the runtime library >(including the STL), and against the IBM Class Library -- of the over >1000 APARs you mention, how many fall in each category? Since I do not >use any part of the IBM Class Library, I am not concerned with APARs >pertaining to this library. The IDE is buggy but I can live with it, >albeit grudgingly since when the IDE crashes, it can quickly be brought >back to life again. I use Visual SlickEdit for editing the files and >it rarely crashes. Bugs in the compiler and the runtime library or the >STL are more serious and I am certainly interested in learning about >outstanding APARs against those, especially since I just converted my >main project to use the STL. > > > >>It is also an enormous CPU and memory hog. Don't even try using it on a >>system less than PIII650 with less than 256MB ram. A lot of OS/2 users >> >> >have > > >>much smaller systems than that. While I have no problem with VA 3.0 FP8 on >>a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >>selling features left for OS/2 or eCS is it's very small footprint, even >> >> >for > > >>developers. >> >> > >As mentioned above, I am using it on a much slower machine and the >compiler/linker performs admirably. With respect to the memory >footprint of OS/2, I do not think that is a selling-point today >although I run WSEB and Warp on several even slower machines, one a >souped up PS/2 model 80 with a Cyrix processor running at the >equivalent of 75-90 MHz Pentium with 64 Mb of memory and also several >PS/2 servers with 66 MHz Pentium processors and 64 - 256 Mb of memory. >On all systems, Warp/WSEB runs fine, however, I would not use any of >them for demanding tasks. Further, I believe the amount of memory is >more important than the processor speed itself since any processor is >slowed down swapping to disk. You also have to differentiate between >someone developing for OS/2 and someone using the finished application, >while the former is demanding of system resources, properly designed >applications tend to be much less so. > >As for your development system, you would probably see a greater >improvement in build times if you added more memory to your development >machine, more so than having a faster processor. > > > >>VA4 is definitely on the cutting edge of C++ standards and development >>environment. In fact, it probably too far ahead for comfort. Its >> >> >technical > > >>superiority is not enough to overcome the enormous inertia behind the >>traditional header/makefile build paradigm. And of course, it's most fatal >>flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >>debugged, product, even if discontinued. >> >> > >Well, VA 3.x is no longer supported either and VAC++ 4. offers some >level of conformance with standard C++. > > > >>I just wish Watcom could get up to snuff. As it is, it is not even as good >>as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >>we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >>fully impelemented stl library. But the codestore is a concept whose time >>is still YEARS away from being accepted by the masses. >> >> > >As stated in my previous message, it is simple to set up your >configuration file (ICC file) so that projects compile with both VAC++ >and traditional compilers. In my experience, no changes have to be >made to the source or include files themselves. > >I have not used either Watcom nor gcc -- if anyone has any good >arguments for using either compiler, I am listening. > >Hakan > > > >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Monday, December 02, 2002 12:23 PM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows-2.3.4 >> >> >>Dave (and others), >> >>While I initially had problems with the codestore concept I am now able >>to work with it vs. against it. It is, however, a pity that version 4 >>does not have the config option added to version 5 of the compiler for >>AIX to disable "orderless compile" and thus maintain compatibility with >>conventionally structured source code. With that said, it is still >>possible to have a VAC++ 4 ICC file (config file) which allows you to >>maintain conventionally structured code with all their #include >>statements and the code can compile on both VAC++ 4 and traditional >>compilers. >> >>You are referring to a "grossly buggy mess" with respect to VAC++ -- >>can you elaborate? While I have certainly come across problems with >>the IDE itself where it throws exceptions etc (closing the IDE and >>relaunching it takes care of that problem) I have yet to come across >>any code generation problems. I know that the version 4 of the >>compiler also comes with a command-line version of the compiler and >>other tools which I *assume* is what is being used by the IDE itself >>and thus should be as conformant as the IDE version. >> >>Again, what attracted me to VAC++ 4 was for starters conformance with >>standard C++. While I am certain it may not be 100% compliant, I do >>not yet know where it falls short -- I simply have not pushed it that >>far yet. On that topic, how compliant is the latest version of gcc? >> >>BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler >>together with Aaron Lawrence's excellent replacement for view.exe, >>NewView.exe, to view the toolkit documentation. >> >>I am certainly interested in hearing the opinions of others as well >>when it comes to VAC++ vs. other compilers knowing full well that VAC++ >>is no longer supported by IBM. >> >>Hakan >> >>On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: >> >> >> >>>It has to do with the usage of a codestore and the way headers, global >>>constants, and statics are coded in the library interplay witht he >>>codestore. It is a near impossible tangle of dependencies and constructs >>>that render a VA 4 wxWindows project virtually unmaintainable. Then there >>>are the samples and demos, which are separately mintained from the library >>>itself, which for use under VA 4 have to be part of the codestore to be >>>debugged. wxWindows is a classic makefile style project and is NOT coded >>> >>> >>to >> >> >>>deal with the concept of codestores. >>> >>>Added in with the fact that VA 4 itself, with the its only fixpack, is >>>still a grossly buggy mess and IBM has cancelled future support for it on >>>OS/2 that makes time spent trying to coax an Open Source project to >>>compatitability with it's completely non-traditional model, a waste of >>> >>> >time > > >>>and effort. >>> >>>-----Original Message----- >>>From: Hakan [mailto:agents at meddatainc.com] >>>Sent: Monday, December 02, 2002 10:39 AM >>>To: os2-unix at eyup.org >>>Subject: RE: wxWindows-2.3.4 >>> >>> >>>Dave, >>> >>>Can you tell us what the compatibility problems were? I am currently >>>using VAC++ 4 for one of my own projects, mainly, but not solely, due >>>to its greater conformance with standard C++, and would surely be >>>interested in knowing what the issues are with respect to the code for >>>vxWindows. >>> >>>Thanks. >>> >>>Hakan >>> >>>On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >>> >>> >>> >>>>Users might see the VA4 build files in the distribution but I abandoned >>>>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>>>code was a real nightmare and since that is now a dead product I didn't >>>> >>>> >>see >> >> >>>>the merit in putting any more effort into maintaining it. >>>> >>>>-----Original Message----- >>>>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>>>Sent: Thursday, November 28, 2002 7:34 AM >>>>To: os2-unix at eyup.org >>>>Subject: Re: wxWindows-2.3.4 >>>> >>>> >>>>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >>>> >>>> >>>> >>>>>you are using GCC to compile it right? I tried with VAC some month ago >>>>>but it failed (can't remember where, didn't had the time to check it >>>>>more). >>>>> >>>>> >>>>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>>>should work just as well (or even better), while VAC++ 4 is a real >>>>problem... >>>> >>>> Regards, >>>> Stefan >>>>-- >>>>Micro$oft is not an answer. It is a question. The answer is 'no'. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > > > **= Email 20 ==========================** Date: Mon, 2 Dec 2002 14:30:57 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 Where did I say gcc? icc (.icc) are VA 4.0 build files not gcc (EMX). Stefan has a working EMX (gcc) distrubution, but I personally use VA3.0 FP8 and now have a clean compiling version for both static and dynamic libraries on the latest CVS tree. You are free to use gcc/EMX or VA 3.0 FP8 against Os2 toolkit V4.5 or later. Both work just fine. Watcom C++ support is unknown since neither Stefan nor I use it and no one else has tried it. -----Original Message----- From: Ken Ames [mailto:kenames at pacbell.net] Sent: Monday, December 02, 2002 2:00 PM To: os2-unix at eyup.org Subject: Re: wxWindows-2.3.4 Dave Webster wrote: >There are icc files for an OS/2 build on the CVS tree, still. You are >welcome to download them and fiddle with them if you desire. They worked >quite well once upon a time. > > vac 3 with fixpak 8 applied is what I have been trying to use. I guess you want me to use gcc so I will. :) they seem to work rather inconsistent now. Yuri Dario says my latest error looks like an ilib bug and I agree. >The single biggest bug on VA4 is it's HUGE memory leak. On a system with >128MB ram the wx build generates and OS/2 swap file over 256MB large. On >smaller systems, it just crashes on every build. There are, at time of IBM >dropping support, over 1000 APARS against this version covering various >issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >that didn't otherwise get it for free? > I have it, bought it from mensys, dont use it, crashes too much and generates some bad code. > >It is also an enormous CPU and memory hog. Don't even try using it on a >system less than PIII650 with less than 256MB ram. A lot of OS/2 users have >much smaller systems than that. While I have no problem with VA 3.0 FP8 on >a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >selling features left for OS/2 or eCS is it's very small footprint, even for >developers. > >VA4 is definitely on the cutting edge of C++ standards and development >environment. In fact, it probably too far ahead for comfort. Its technical >superiority is not enough to overcome the enormous inertia behind the >traditional header/makefile build paradigm. And of course, it's most fatal >flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >debugged, product, even if discontinued. > >I just wish Watcom could get up to snuff. As it is, it is not even as good >as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >fully impelemented stl library. But the codestore is a concept whose time >is still YEARS away from being accepted by the masses. > watcom is coming along. c++ compiler is a topic of discussion lately. seems they are going to start on it soon (I hope). > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 12:23 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave (and others), > >While I initially had problems with the codestore concept I am now able >to work with it vs. against it. It is, however, a pity that version 4 >does not have the config option added to version 5 of the compiler for >AIX to disable "orderless compile" and thus maintain compatibility with >conventionally structured source code. With that said, it is still >possible to have a VAC++ 4 ICC file (config file) which allows you to >maintain conventionally structured code with all their #include >statements and the code can compile on both VAC++ 4 and traditional >compilers. > >You are referring to a "grossly buggy mess" with respect to VAC++ -- >can you elaborate? While I have certainly come across problems with >the IDE itself where it throws exceptions etc (closing the IDE and >relaunching it takes care of that problem) I have yet to come across >any code generation problems. I know that the version 4 of the >compiler also comes with a command-line version of the compiler and >other tools which I *assume* is what is being used by the IDE itself >and thus should be as conformant as the IDE version. > >Again, what attracted me to VAC++ 4 was for starters conformance with >standard C++. While I am certain it may not be 100% compliant, I do >not yet know where it falls short -- I simply have not pushed it that >far yet. On that topic, how compliant is the latest version of gcc? > >BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler >together with Aaron Lawrence's excellent replacement for view.exe, >NewView.exe, to view the toolkit documentation. > >I am certainly interested in hearing the opinions of others as well >when it comes to VAC++ vs. other compilers knowing full well that VAC++ >is no longer supported by IBM. > >Hakan > >On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: > > > >>It has to do with the usage of a codestore and the way headers, global >>constants, and statics are coded in the library interplay witht he >>codestore. It is a near impossible tangle of dependencies and constructs >>that render a VA 4 wxWindows project virtually unmaintainable. Then there >>are the samples and demos, which are separately mintained from the library >>itself, which for use under VA 4 have to be part of the codestore to be >>debugged. wxWindows is a classic makefile style project and is NOT coded >> >> >to > > >>deal with the concept of codestores. >> >>Added in with the fact that VA 4 itself, with the its only fixpack, is >>still a grossly buggy mess and IBM has cancelled future support for it on >>OS/2 that makes time spent trying to coax an Open Source project to >>compatitability with it's completely non-traditional model, a waste of time >>and effort. >> >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Monday, December 02, 2002 10:39 AM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows-2.3.4 >> >> >>Dave, >> >>Can you tell us what the compatibility problems were? I am currently >>using VAC++ 4 for one of my own projects, mainly, but not solely, due >>to its greater conformance with standard C++, and would surely be >>interested in knowing what the issues are with respect to the code for >>vxWindows. >> >>Thanks. >> >>Hakan >> >>On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >> >> >> >>>Users might see the VA4 build files in the distribution but I abandoned >>>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>>code was a real nightmare and since that is now a dead product I didn't >>> >>> >see > > >>>the merit in putting any more effort into maintaining it. >>> >>>-----Original Message----- >>>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>>Sent: Thursday, November 28, 2002 7:34 AM >>>To: os2-unix at eyup.org >>>Subject: Re: wxWindows-2.3.4 >>> >>> >>>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >>> >>> >>> >>>>you are using GCC to compile it right? I tried with VAC some month ago >>>>but it failed (can't remember where, didn't had the time to check it >>>>more). >>>> >>>> >>>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>>should work just as well (or even better), while VAC++ 4 is a real >>>problem... >>> >>> Regards, >>> Stefan >>>-- >>>Micro$oft is not an answer. It is a question. The answer is 'no'. >>> >>> >>> >>> >>> >> >> >> >> > > > > > > **= Email 21 ==========================** Date: Mon, 02 Dec 2002 14:31:30 +0100 (CET) From: "Yuri Dario" Subject: Re: wxOS2 Hi Ken, >also, further into the build process I get the following errors: >LIB0003: Error (adler32):Module redefinition ignored >(X:\WXWINDOWS-2.3.4\src\zlib\..\zlib\DebugOS2\adler32.obj) see answer to wxWindows-2.3.4 thread: same here, it seems a ilib bug. I tried to build the dll, but wx23.def is not correct. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 22 ==========================** Date: Mon, 2 Dec 2002 14:33:38 +0000 From: John Poltorak Subject: Re: os2-unix list is now also hosted via news On Mon, Dec 02, 2002 at 09:22:11AM -0500, Robert_K_Cook at comerica.com wrote: > gmane.org, a spamfree news<->mail gateway is now includes os2-unix. > > It is listed under gmane.comp.porting.unix-to-os2 > > All future posts will archived there or you can access posts via your > newsreader/web browser. > > Just add a new server: news://news.gmane.org/ What exactly is this? I'm not sure that this is something we want. Does anyone else have a view on this? -- John **= Email 23 ==========================** Date: Mon, 2 Dec 2002 14:47:55 +0000 From: John Poltorak Subject: Re: os2-unix list is now also hosted via news On Mon, Dec 02, 2002 at 02:33:38PM +0000, John Poltorak wrote: > On Mon, Dec 02, 2002 at 09:22:11AM -0500, Robert_K_Cook at comerica.com wrote: > > gmane.org, a spamfree news<->mail gateway is now includes os2-unix. > > > > It is listed under gmane.comp.porting.unix-to-os2 > > > > All future posts will archived there or you can access posts via your > > newsreader/web browser. > > > > Just add a new server: news://news.gmane.org/ > > > What exactly is this? > > I'm not sure that this is something we want. > > Does anyone else have a view on this? I've just removed this subscriber since I've never heard of him and he made no attempt to ask about using the mailing list externally before proceeding to do so. -- John **= Email 24 ==========================** Date: Mon, 02 Dec 2002 15:03:25 -0800 From: Ken Ames Subject: Re: wxWindows-2.3.4 hi Dave, I did the update a few minutes after you're msg came in that said you updated the cvs tree. Dave Webster wrote: >When did you do the update? If it was this weekend then the files didn't >yet make it. It was late Sunday night (US Central time) that I finally got >the last files updated. Compiled just fine here this morning. Can speak to >EMX but VA 3.0 FP8 is currently compilable. Sorry for the confusion, but >try another synch, you should get several OS/2 .h and .cpp plus a new > no problem. confusion often reigns when I am involved. I most surely mean NO offense to you or anyone. Ken >intl.cpp file from /common at the very least. > >-----Original Message----- >From: Ken Ames [mailto:kenames at pacbell.net] >Sent: Monday, December 02, 2002 3:35 PM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > >you did not explicitely but did imply or I was imagining. whatever the >case but my problem remains. vac 3.0 with fixpak 8 applied will NOT >compile wxOS2. I did a cvs update from the cvs server listed on >wxWindows home page and got 0 (zero) updated files so, cvs needs repair >on their end. either in the readme files or setup postings or whatever. >I repeat, I am trying to use VAC 3.0 with fixpak 8 applied and compile >does NOT work > >Dave Webster wrote: > > > >>Where did I say gcc? icc (.icc) are VA 4.0 build files not gcc (EMX). >>Stefan has a working EMX (gcc) distrubution, but I personally use VA3.0 FP8 >>and now have a clean compiling version for both static and dynamic >> >> >libraries > > >>on the latest CVS tree. You are free to use gcc/EMX or VA 3.0 FP8 against >>Os2 toolkit V4.5 or later. Both work just fine. Watcom C++ support is >>unknown since neither Stefan nor I use it and no one else has tried it. >> >> >> >> >can you point to the latest cvs tree?U >mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/panels.rdf >U mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/search.rdf > >checkout finish: Mon Dec 2 11:04:39 pst 2002 >Generating configures using autoconf >SYS1079: << was unexpected at this time. >configure.in:37: error: m4_file_append: cannot write: /tmp/forbidden.rx >configure.in:37: the top level >gmake.exe[1]: *** [real_checkout] Error 2 >gmake.exe[1]: Leaving directory `/' >gmake: *** [checkout] Error 2 > > > > >>-----Original Message----- >>From: Ken Ames [mailto:kenames at pacbell.net] >>Sent: Monday, December 02, 2002 2:00 PM >>To: os2-unix at eyup.org >>Subject: Re: wxWindows-2.3.4 >> >> >> >> >>Dave Webster wrote: >> >> >> >> >> >>>There are icc files for an OS/2 build on the CVS tree, still. You are >>>welcome to download them and fiddle with them if you desire. They worked >>>quite well once upon a time. >>> >>> >>> >>> >>> >>> >>vac 3 with fixpak 8 applied is what I have been trying to use. I guess >>you want me to use gcc so I will. :) >>they seem to work rather inconsistent now. Yuri Dario says my latest >>error looks like an ilib bug and I agree. >> >> >> >the last sentence above indicated you wanted me to use gcc. If it is not >an ilib bug please tell me. > > > >> >> >> >> >>>The single biggest bug on VA4 is it's HUGE memory leak. On a system with >>>128MB ram the wx build generates and OS/2 swap file over 256MB large. On >>>smaller systems, it just crashes on every build. There are, at time of >>> >>> >IBM > > >>>dropping support, over 1000 APARS against this version covering various >>>issues. And at $1800 for a non-supported, buggy product, who'd ever buy >>> >>> >it > > >>>that didn't otherwise get it for free? >>> >>> >>> >>> >>> >I have a copy of VAC4. I do NOT use it, buggy! no good. crashes, etc.... >everyone knows vac4 story - dead end. > > > >>I have it, bought it from mensys, dont use it, crashes too much and >>generates some bad code. >> >> >> >> >> >>>It is also an enormous CPU and memory hog. Don't even try using it on a >>>system less than PIII650 with less than 256MB ram. A lot of OS/2 users >>> >>> >>> >>> >>have >> >> >> >> >>>much smaller systems than that. While I have no problem with VA 3.0 FP8 >>> >>> >on > > >>>a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >>>selling features left for OS/2 or eCS is it's very small footprint, even >>> >>> >>> >>> >>for >> >> >> >> >>>developers. >>> >>>VA4 is definitely on the cutting edge of C++ standards and development >>>environment. In fact, it probably too far ahead for comfort. Its >>> >>> >>> >>> >>technical >> >> >> >> >>>superiority is not enough to overcome the enormous inertia behind the >>>traditional header/makefile build paradigm. And of course, it's most >>> >>> >fatal > > >>>flaw, is it is no longer supported by anyone. At least VA 3.x is a >>> >>> >mature, > > >>>debugged, product, even if discontinued. >>> >>>I just wish Watcom could get up to snuff. As it is, it is not even as >>> >>> >good > > >>>as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. >>> >>> >What > > >>>we need is the Watcom compiler complete with the latest OS/2 toolkit WITH >>> >>> >a > > >>>fully impelemented stl library. But the codestore is a concept whose time >>>is still YEARS away from being accepted by the masses. >>> >>> >>> >>> >>> >>watcom is coming along. c++ compiler is a topic of discussion lately. >>seems they are going to start on it soon (I hope). >> >> >> >> >> >as it stands from here at the moment, wxOS2 is unbuildable with vac3.08 >so I am hoping you will supply the missing pieces. >please excuse anything that may seem like I am trying to make you angry >as I am most definitly NOT trying to do that. I am simply trying to get >a cross platform solution in place here. wxOS2 has been far to long in >coming but I realize you are a busy man and still must make a living. > >Ken > > > > > > **= Email 25 ==========================** Date: Mon, 2 Dec 2002 15:05:49 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 I have to support the most popular environment for my platform that I can due to the very limited amount of time I have to devote to wxWindows. (My day job is writing financial management and telephony switches for nonStop Guardian, HPUX and WIN32 servers). That means VA 3.x and EMX. Stefan does the EMX and I do VA 3.0. You are the first person I've ever run accross that actually still uses VA 4.0 after IBM dumped it. And I cannot afford the time needed to make the constant adjustments to support codestore based development. My current machine is PIV 2.4 GHZ with 1GB ram but VA 4.0 is still a non starter for me for its need to have a lot of special additions to the wx codebase to make it compile. Like I said, I have old .icc file that used to work. If you wish to become involved in wxWindows and support VA 4.0, you are free to do so. Otherwise, it won't happen. -----Original Message----- From: Hakan [mailto:agents at meddatainc.com] Sent: Monday, December 02, 2002 2:23 PM To: os2-unix at eyup.org Subject: RE: wxWindows-2.3.4 Dave, My interest was in your experience with VAC++ applied to vxWindows or to other projects. I am actually beginning to write my own class library for PM, for my own use. My library is heavily influenced by IBM's class libraries, both the version which came with CSet 2.1 and the newer one delivered with VAC++ 4, libraries I believe are very well designed. >The single biggest bug on VA4 is it's HUGE memory leak. On a system with >128MB ram the wx build generates and OS/2 swap file over 256MB large. On >smaller systems, it just crashes on every build. There are, at time of IBM >dropping support, over 1000 APARS against this version covering various >issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >that didn't otherwise get it for free? My development machine is a PPro machine with four processors, each running at 200 MHz, and with 1Gb memory. VAC++ is very snappy and responsive on this machine and compiles are very quick (my projects are still very small, though.) This machine, bought on eBay two years ago for approx. $1000, was probably used as a server but is great for development, especially since I run WSEB SMP and use the SciTech display drivers. With that amount of memory I have not seen any use of swap files and the amount of available memory never goes below 700K. Where can I find the APAR list? I fhink one has to separate APARs against the compiler, against the IDE environment, the runtime library (including the STL), and against the IBM Class Library -- of the over 1000 APARs you mention, how many fall in each category? Since I do not use any part of the IBM Class Library, I am not concerned with APARs pertaining to this library. The IDE is buggy but I can live with it, albeit grudgingly since when the IDE crashes, it can quickly be brought back to life again. I use Visual SlickEdit for editing the files and it rarely crashes. Bugs in the compiler and the runtime library or the STL are more serious and I am certainly interested in learning about outstanding APARs against those, especially since I just converted my main project to use the STL. >It is also an enormous CPU and memory hog. Don't even try using it on a >system less than PIII650 with less than 256MB ram. A lot of OS/2 users have >much smaller systems than that. While I have no problem with VA 3.0 FP8 on >a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >selling features left for OS/2 or eCS is it's very small footprint, even for >developers. As mentioned above, I am using it on a much slower machine and the compiler/linker performs admirably. With respect to the memory footprint of OS/2, I do not think that is a selling-point today although I run WSEB and Warp on several even slower machines, one a souped up PS/2 model 80 with a Cyrix processor running at the equivalent of 75-90 MHz Pentium with 64 Mb of memory and also several PS/2 servers with 66 MHz Pentium processors and 64 - 256 Mb of memory. On all systems, Warp/WSEB runs fine, however, I would not use any of them for demanding tasks. Further, I believe the amount of memory is more important than the processor speed itself since any processor is slowed down swapping to disk. You also have to differentiate between someone developing for OS/2 and someone using the finished application, while the former is demanding of system resources, properly designed applications tend to be much less so. As for your development system, you would probably see a greater improvement in build times if you added more memory to your development machine, more so than having a faster processor. >VA4 is definitely on the cutting edge of C++ standards and development >environment. In fact, it probably too far ahead for comfort. Its technical >superiority is not enough to overcome the enormous inertia behind the >traditional header/makefile build paradigm. And of course, it's most fatal >flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >debugged, product, even if discontinued. Well, VA 3.x is no longer supported either and VAC++ 4. offers some level of conformance with standard C++. >I just wish Watcom could get up to snuff. As it is, it is not even as good >as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >fully impelemented stl library. But the codestore is a concept whose time >is still YEARS away from being accepted by the masses. As stated in my previous message, it is simple to set up your configuration file (ICC file) so that projects compile with both VAC++ and traditional compilers. In my experience, no changes have to be made to the source or include files themselves. I have not used either Watcom nor gcc -- if anyone has any good arguments for using either compiler, I am listening. Hakan > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 12:23 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave (and others), > >While I initially had problems with the codestore concept I am now able >to work with it vs. against it. It is, however, a pity that version 4 >does not have the config option added to version 5 of the compiler for >AIX to disable "orderless compile" and thus maintain compatibility with >conventionally structured source code. With that said, it is still >possible to have a VAC++ 4 ICC file (config file) which allows you to >maintain conventionally structured code with all their #include >statements and the code can compile on both VAC++ 4 and traditional >compilers. > >You are referring to a "grossly buggy mess" with respect to VAC++ -- >can you elaborate? While I have certainly come across problems with >the IDE itself where it throws exceptions etc (closing the IDE and >relaunching it takes care of that problem) I have yet to come across >any code generation problems. I know that the version 4 of the >compiler also comes with a command-line version of the compiler and >other tools which I *assume* is what is being used by the IDE itself >and thus should be as conformant as the IDE version. > >Again, what attracted me to VAC++ 4 was for starters conformance with >standard C++. While I am certain it may not be 100% compliant, I do >not yet know where it falls short -- I simply have not pushed it that >far yet. On that topic, how compliant is the latest version of gcc? > >BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler >together with Aaron Lawrence's excellent replacement for view.exe, >NewView.exe, to view the toolkit documentation. > >I am certainly interested in hearing the opinions of others as well >when it comes to VAC++ vs. other compilers knowing full well that VAC++ >is no longer supported by IBM. > >Hakan > >On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: > >>It has to do with the usage of a codestore and the way headers, global >>constants, and statics are coded in the library interplay witht he >>codestore. It is a near impossible tangle of dependencies and constructs >>that render a VA 4 wxWindows project virtually unmaintainable. Then there >>are the samples and demos, which are separately mintained from the library >>itself, which for use under VA 4 have to be part of the codestore to be >>debugged. wxWindows is a classic makefile style project and is NOT coded >to >>deal with the concept of codestores. >> >>Added in with the fact that VA 4 itself, with the its only fixpack, is >>still a grossly buggy mess and IBM has cancelled future support for it on >>OS/2 that makes time spent trying to coax an Open Source project to >>compatitability with it's completely non-traditional model, a waste of time >>and effort. >> >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Monday, December 02, 2002 10:39 AM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows-2.3.4 >> >> >>Dave, >> >>Can you tell us what the compatibility problems were? I am currently >>using VAC++ 4 for one of my own projects, mainly, but not solely, due >>to its greater conformance with standard C++, and would surely be >>interested in knowing what the issues are with respect to the code for >>vxWindows. >> >>Thanks. >> >>Hakan >> >>On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >> >>>Users might see the VA4 build files in the distribution but I abandoned >>>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>>code was a real nightmare and since that is now a dead product I didn't >see >>>the merit in putting any more effort into maintaining it. >>> >>>-----Original Message----- >>>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>>Sent: Thursday, November 28, 2002 7:34 AM >>>To: os2-unix at eyup.org >>>Subject: Re: wxWindows-2.3.4 >>> >>> >>>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >>> >>>> you are using GCC to compile it right? I tried with VAC some month ago >>>> but it failed (can't remember where, didn't had the time to check it >>>> more). >>> >>>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>>should work just as well (or even better), while VAC++ 4 is a real >>>problem... >>> >>> Regards, >>> Stefan >>>-- >>>Micro$oft is not an answer. It is a question. The answer is 'no'. >>> >>> >>> >> >> >> >> > > > > **= Email 26 ==========================** Date: Mon, 02 Dec 2002 15:23:27 -0500 (EST) From: "Hakan" Subject: RE: wxWindows-2.3.4 Dave, My interest was in your experience with VAC++ applied to vxWindows or to other projects. I am actually beginning to write my own class library for PM, for my own use. My library is heavily influenced by IBM's class libraries, both the version which came with CSet 2.1 and the newer one delivered with VAC++ 4, libraries I believe are very well designed. >The single biggest bug on VA4 is it's HUGE memory leak. On a system with >128MB ram the wx build generates and OS/2 swap file over 256MB large. On >smaller systems, it just crashes on every build. There are, at time of IBM >dropping support, over 1000 APARS against this version covering various >issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >that didn't otherwise get it for free? My development machine is a PPro machine with four processors, each running at 200 MHz, and with 1Gb memory. VAC++ is very snappy and responsive on this machine and compiles are very quick (my projects are still very small, though.) This machine, bought on eBay two years ago for approx. $1000, was probably used as a server but is great for development, especially since I run WSEB SMP and use the SciTech display drivers. With that amount of memory I have not seen any use of swap files and the amount of available memory never goes below 700K. Where can I find the APAR list? I fhink one has to separate APARs against the compiler, against the IDE environment, the runtime library (including the STL), and against the IBM Class Library -- of the over 1000 APARs you mention, how many fall in each category? Since I do not use any part of the IBM Class Library, I am not concerned with APARs pertaining to this library. The IDE is buggy but I can live with it, albeit grudgingly since when the IDE crashes, it can quickly be brought back to life again. I use Visual SlickEdit for editing the files and it rarely crashes. Bugs in the compiler and the runtime library or the STL are more serious and I am certainly interested in learning about outstanding APARs against those, especially since I just converted my main project to use the STL. >It is also an enormous CPU and memory hog. Don't even try using it on a >system less than PIII650 with less than 256MB ram. A lot of OS/2 users have >much smaller systems than that. While I have no problem with VA 3.0 FP8 on >a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >selling features left for OS/2 or eCS is it's very small footprint, even for >developers. As mentioned above, I am using it on a much slower machine and the compiler/linker performs admirably. With respect to the memory footprint of OS/2, I do not think that is a selling-point today although I run WSEB and Warp on several even slower machines, one a souped up PS/2 model 80 with a Cyrix processor running at the equivalent of 75-90 MHz Pentium with 64 Mb of memory and also several PS/2 servers with 66 MHz Pentium processors and 64 - 256 Mb of memory. On all systems, Warp/WSEB runs fine, however, I would not use any of them for demanding tasks. Further, I believe the amount of memory is more important than the processor speed itself since any processor is slowed down swapping to disk. You also have to differentiate between someone developing for OS/2 and someone using the finished application, while the former is demanding of system resources, properly designed applications tend to be much less so. As for your development system, you would probably see a greater improvement in build times if you added more memory to your development machine, more so than having a faster processor. >VA4 is definitely on the cutting edge of C++ standards and development >environment. In fact, it probably too far ahead for comfort. Its technical >superiority is not enough to overcome the enormous inertia behind the >traditional header/makefile build paradigm. And of course, it's most fatal >flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >debugged, product, even if discontinued. Well, VA 3.x is no longer supported either and VAC++ 4. offers some level of conformance with standard C++. >I just wish Watcom could get up to snuff. As it is, it is not even as good >as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >fully impelemented stl library. But the codestore is a concept whose time >is still YEARS away from being accepted by the masses. As stated in my previous message, it is simple to set up your configuration file (ICC file) so that projects compile with both VAC++ and traditional compilers. In my experience, no changes have to be made to the source or include files themselves. I have not used either Watcom nor gcc -- if anyone has any good arguments for using either compiler, I am listening. Hakan > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 12:23 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave (and others), > >While I initially had problems with the codestore concept I am now able >to work with it vs. against it. It is, however, a pity that version 4 >does not have the config option added to version 5 of the compiler for >AIX to disable "orderless compile" and thus maintain compatibility with >conventionally structured source code. With that said, it is still >possible to have a VAC++ 4 ICC file (config file) which allows you to >maintain conventionally structured code with all their #include >statements and the code can compile on both VAC++ 4 and traditional >compilers. > >You are referring to a "grossly buggy mess" with respect to VAC++ -- >can you elaborate? While I have certainly come across problems with >the IDE itself where it throws exceptions etc (closing the IDE and >relaunching it takes care of that problem) I have yet to come across >any code generation problems. I know that the version 4 of the >compiler also comes with a command-line version of the compiler and >other tools which I *assume* is what is being used by the IDE itself >and thus should be as conformant as the IDE version. > >Again, what attracted me to VAC++ 4 was for starters conformance with >standard C++. While I am certain it may not be 100% compliant, I do >not yet know where it falls short -- I simply have not pushed it that >far yet. On that topic, how compliant is the latest version of gcc? > >BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler >together with Aaron Lawrence's excellent replacement for view.exe, >NewView.exe, to view the toolkit documentation. > >I am certainly interested in hearing the opinions of others as well >when it comes to VAC++ vs. other compilers knowing full well that VAC++ >is no longer supported by IBM. > >Hakan > >On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: > >>It has to do with the usage of a codestore and the way headers, global >>constants, and statics are coded in the library interplay witht he >>codestore. It is a near impossible tangle of dependencies and constructs >>that render a VA 4 wxWindows project virtually unmaintainable. Then there >>are the samples and demos, which are separately mintained from the library >>itself, which for use under VA 4 have to be part of the codestore to be >>debugged. wxWindows is a classic makefile style project and is NOT coded >to >>deal with the concept of codestores. >> >>Added in with the fact that VA 4 itself, with the its only fixpack, is >>still a grossly buggy mess and IBM has cancelled future support for it on >>OS/2 that makes time spent trying to coax an Open Source project to >>compatitability with it's completely non-traditional model, a waste of time >>and effort. >> >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Monday, December 02, 2002 10:39 AM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows-2.3.4 >> >> >>Dave, >> >>Can you tell us what the compatibility problems were? I am currently >>using VAC++ 4 for one of my own projects, mainly, but not solely, due >>to its greater conformance with standard C++, and would surely be >>interested in knowing what the issues are with respect to the code for >>vxWindows. >> >>Thanks. >> >>Hakan >> >>On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >> >>>Users might see the VA4 build files in the distribution but I abandoned >>>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>>code was a real nightmare and since that is now a dead product I didn't >see >>>the merit in putting any more effort into maintaining it. >>> >>>-----Original Message----- >>>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>>Sent: Thursday, November 28, 2002 7:34 AM >>>To: os2-unix at eyup.org >>>Subject: Re: wxWindows-2.3.4 >>> >>> >>>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >>> >>>> you are using GCC to compile it right? I tried with VAC some month ago >>>> but it failed (can't remember where, didn't had the time to check it >>>> more). >>> >>>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>>should work just as well (or even better), while VAC++ 4 is a real >>>problem... >>> >>> Regards, >>> Stefan >>>-- >>>Micro$oft is not an answer. It is a question. The answer is 'no'. >>> >>> >>> >> >> >> >> > > > > **= Email 27 ==========================** Date: Mon, 2 Dec 2002 16:01:37 -0600 From: Dave Webster Subject: RE: wxWindows-2.3.4 When did you do the update? If it was this weekend then the files didn't yet make it. It was late Sunday night (US Central time) that I finally got the last files updated. Compiled just fine here this morning. Can speak to EMX but VA 3.0 FP8 is currently compilable. Sorry for the confusion, but try another synch, you should get several OS/2 .h and .cpp plus a new intl.cpp file from /common at the very least. -----Original Message----- From: Ken Ames [mailto:kenames at pacbell.net] Sent: Monday, December 02, 2002 3:35 PM To: os2-unix at eyup.org Subject: Re: wxWindows-2.3.4 you did not explicitely but did imply or I was imagining. whatever the case but my problem remains. vac 3.0 with fixpak 8 applied will NOT compile wxOS2. I did a cvs update from the cvs server listed on wxWindows home page and got 0 (zero) updated files so, cvs needs repair on their end. either in the readme files or setup postings or whatever. I repeat, I am trying to use VAC 3.0 with fixpak 8 applied and compile does NOT work Dave Webster wrote: >Where did I say gcc? icc (.icc) are VA 4.0 build files not gcc (EMX). >Stefan has a working EMX (gcc) distrubution, but I personally use VA3.0 FP8 >and now have a clean compiling version for both static and dynamic libraries >on the latest CVS tree. You are free to use gcc/EMX or VA 3.0 FP8 against >Os2 toolkit V4.5 or later. Both work just fine. Watcom C++ support is >unknown since neither Stefan nor I use it and no one else has tried it. > > can you point to the latest cvs tree?U mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/panels.rdf U mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/search.rdf checkout finish: Mon Dec 2 11:04:39 pst 2002 Generating configures using autoconf SYS1079: << was unexpected at this time. configure.in:37: error: m4_file_append: cannot write: /tmp/forbidden.rx configure.in:37: the top level gmake.exe[1]: *** [real_checkout] Error 2 gmake.exe[1]: Leaving directory `/' gmake: *** [checkout] Error 2 >-----Original Message----- >From: Ken Ames [mailto:kenames at pacbell.net] >Sent: Monday, December 02, 2002 2:00 PM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > > > >Dave Webster wrote: > > > >>There are icc files for an OS/2 build on the CVS tree, still. You are >>welcome to download them and fiddle with them if you desire. They worked >>quite well once upon a time. >> >> >> >> >vac 3 with fixpak 8 applied is what I have been trying to use. I guess >you want me to use gcc so I will. :) >they seem to work rather inconsistent now. Yuri Dario says my latest >error looks like an ilib bug and I agree. > the last sentence above indicated you wanted me to use gcc. If it is not an ilib bug please tell me. > > > >>The single biggest bug on VA4 is it's HUGE memory leak. On a system with >>128MB ram the wx build generates and OS/2 swap file over 256MB large. On >>smaller systems, it just crashes on every build. There are, at time of IBM >>dropping support, over 1000 APARS against this version covering various >>issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >>that didn't otherwise get it for free? >> >> >> I have a copy of VAC4. I do NOT use it, buggy! no good. crashes, etc.... everyone knows vac4 story - dead end. >I have it, bought it from mensys, dont use it, crashes too much and >generates some bad code. > > > >>It is also an enormous CPU and memory hog. Don't even try using it on a >>system less than PIII650 with less than 256MB ram. A lot of OS/2 users >> >> >have > > >>much smaller systems than that. While I have no problem with VA 3.0 FP8 on >>a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >>selling features left for OS/2 or eCS is it's very small footprint, even >> >> >for > > >>developers. >> >>VA4 is definitely on the cutting edge of C++ standards and development >>environment. In fact, it probably too far ahead for comfort. Its >> >> >technical > > >>superiority is not enough to overcome the enormous inertia behind the >>traditional header/makefile build paradigm. And of course, it's most fatal >>flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >>debugged, product, even if discontinued. >> >>I just wish Watcom could get up to snuff. As it is, it is not even as good >>as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >>we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >>fully impelemented stl library. But the codestore is a concept whose time >>is still YEARS away from being accepted by the masses. >> >> >> >watcom is coming along. c++ compiler is a topic of discussion lately. >seems they are going to start on it soon (I hope). > > > as it stands from here at the moment, wxOS2 is unbuildable with vac3.08 so I am hoping you will supply the missing pieces. please excuse anything that may seem like I am trying to make you angry as I am most definitly NOT trying to do that. I am simply trying to get a cross platform solution in place here. wxOS2 has been far to long in coming but I realize you are a busy man and still must make a living. Ken **= Email 28 ==========================** Date: Mon, 02 Dec 2002 17:57:09 -0500 (EST) From: "Hakan" Subject: RE: wxWindows-2.3.4 Dave, I'll ask again, do you have a reference to where I can find the "over 1000 APARs" against VAC++ 4? Hakan On Mon, 2 Dec 2002 15:05:49 -0600, Dave Webster wrote: >I have to support the most popular environment for my platform that I can >due to the very limited amount of time I have to devote to wxWindows. (My >day job is writing financial management and telephony switches for nonStop >Guardian, HPUX and WIN32 servers). > >That means VA 3.x and EMX. Stefan does the EMX and I do VA 3.0. You are >the first person I've ever run accross that actually still uses VA 4.0 after >IBM dumped it. And I cannot afford the time needed to make the constant >adjustments to support codestore based development. > >My current machine is PIV 2.4 GHZ with 1GB ram but VA 4.0 is still a non >starter for me for its need to have a lot of special additions to the wx >codebase to make it compile. > >Like I said, I have old .icc file that used to work. If you wish to become >involved in wxWindows and support VA 4.0, you are free to do so. Otherwise, >it won't happen. > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Monday, December 02, 2002 2:23 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows-2.3.4 > > >Dave, > >My interest was in your experience with VAC++ applied to vxWindows or >to other projects. I am actually beginning to write my own class >library for PM, for my own use. My library is heavily influenced by >IBM's class libraries, both the version which came with CSet 2.1 and >the newer one delivered with VAC++ 4, libraries I believe are very well >designed. > >>The single biggest bug on VA4 is it's HUGE memory leak. On a system with >>128MB ram the wx build generates and OS/2 swap file over 256MB large. On >>smaller systems, it just crashes on every build. There are, at time of IBM >>dropping support, over 1000 APARS against this version covering various >>issues. And at $1800 for a non-supported, buggy product, who'd ever buy it >>that didn't otherwise get it for free? > >My development machine is a PPro machine with four processors, each >running at 200 MHz, and with 1Gb memory. VAC++ is very snappy and >responsive on this machine and compiles are very quick (my projects are >still very small, though.) This machine, bought on eBay two years ago >for approx. $1000, was probably used as a server but is great for >development, especially since I run WSEB SMP and use the SciTech >display drivers. With that amount of memory I have not seen any use of >swap files and the amount of available memory never goes below 700K. > >Where can I find the APAR list? I fhink one has to separate APARs >against the compiler, against the IDE environment, the runtime library >(including the STL), and against the IBM Class Library -- of the over >1000 APARs you mention, how many fall in each category? Since I do not >use any part of the IBM Class Library, I am not concerned with APARs >pertaining to this library. The IDE is buggy but I can live with it, >albeit grudgingly since when the IDE crashes, it can quickly be brought >back to life again. I use Visual SlickEdit for editing the files and >it rarely crashes. Bugs in the compiler and the runtime library or the >STL are more serious and I am certainly interested in learning about >outstanding APARs against those, especially since I just converted my >main project to use the STL. > >>It is also an enormous CPU and memory hog. Don't even try using it on a >>system less than PIII650 with less than 256MB ram. A lot of OS/2 users >have >>much smaller systems than that. While I have no problem with VA 3.0 FP8 on >>a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >>selling features left for OS/2 or eCS is it's very small footprint, even >for >>developers. > >As mentioned above, I am using it on a much slower machine and the >compiler/linker performs admirably. With respect to the memory >footprint of OS/2, I do not think that is a selling-point today >although I run WSEB and Warp on several even slower machines, one a >souped up PS/2 model 80 with a Cyrix processor running at the >equivalent of 75-90 MHz Pentium with 64 Mb of memory and also several >PS/2 servers with 66 MHz Pentium processors and 64 - 256 Mb of memory. >On all systems, Warp/WSEB runs fine, however, I would not use any of >them for demanding tasks. Further, I believe the amount of memory is >more important than the processor speed itself since any processor is >slowed down swapping to disk. You also have to differentiate between >someone developing for OS/2 and someone using the finished application, >while the former is demanding of system resources, properly designed >applications tend to be much less so. > >As for your development system, you would probably see a greater >improvement in build times if you added more memory to your development >machine, more so than having a faster processor. > >>VA4 is definitely on the cutting edge of C++ standards and development >>environment. In fact, it probably too far ahead for comfort. Its >technical >>superiority is not enough to overcome the enormous inertia behind the >>traditional header/makefile build paradigm. And of course, it's most fatal >>flaw, is it is no longer supported by anyone. At least VA 3.x is a mature, >>debugged, product, even if discontinued. > >Well, VA 3.x is no longer supported either and VAC++ 4. offers some >level of conformance with standard C++. > >>I just wish Watcom could get up to snuff. As it is, it is not even as good >>as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. What >>we need is the Watcom compiler complete with the latest OS/2 toolkit WITH a >>fully impelemented stl library. But the codestore is a concept whose time >>is still YEARS away from being accepted by the masses. > >As stated in my previous message, it is simple to set up your >configuration file (ICC file) so that projects compile with both VAC++ >and traditional compilers. In my experience, no changes have to be >made to the source or include files themselves. > >I have not used either Watcom nor gcc -- if anyone has any good >arguments for using either compiler, I am listening. > >Hakan > >> >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Monday, December 02, 2002 12:23 PM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows-2.3.4 >> >> >>Dave (and others), >> >>While I initially had problems with the codestore concept I am now able >>to work with it vs. against it. It is, however, a pity that version 4 >>does not have the config option added to version 5 of the compiler for >>AIX to disable "orderless compile" and thus maintain compatibility with >>conventionally structured source code. With that said, it is still >>possible to have a VAC++ 4 ICC file (config file) which allows you to >>maintain conventionally structured code with all their #include >>statements and the code can compile on both VAC++ 4 and traditional >>compilers. >> >>You are referring to a "grossly buggy mess" with respect to VAC++ -- >>can you elaborate? While I have certainly come across problems with >>the IDE itself where it throws exceptions etc (closing the IDE and >>relaunching it takes care of that problem) I have yet to come across >>any code generation problems. I know that the version 4 of the >>compiler also comes with a command-line version of the compiler and >>other tools which I *assume* is what is being used by the IDE itself >>and thus should be as conformant as the IDE version. >> >>Again, what attracted me to VAC++ 4 was for starters conformance with >>standard C++. While I am certain it may not be 100% compliant, I do >>not yet know where it falls short -- I simply have not pushed it that >>far yet. On that topic, how compliant is the latest version of gcc? >> >>BTW, I use Visual SlickEdit version 4 with the VAC++ 4 compiler >>together with Aaron Lawrence's excellent replacement for view.exe, >>NewView.exe, to view the toolkit documentation. >> >>I am certainly interested in hearing the opinions of others as well >>when it comes to VAC++ vs. other compilers knowing full well that VAC++ >>is no longer supported by IBM. >> >>Hakan >> >>On Mon, 2 Dec 2002 11:13:02 -0600, Dave Webster wrote: >> >>>It has to do with the usage of a codestore and the way headers, global >>>constants, and statics are coded in the library interplay witht he >>>codestore. It is a near impossible tangle of dependencies and constructs >>>that render a VA 4 wxWindows project virtually unmaintainable. Then there >>>are the samples and demos, which are separately mintained from the library >>>itself, which for use under VA 4 have to be part of the codestore to be >>>debugged. wxWindows is a classic makefile style project and is NOT coded >>to >>>deal with the concept of codestores. >>> >>>Added in with the fact that VA 4 itself, with the its only fixpack, is >>>still a grossly buggy mess and IBM has cancelled future support for it on >>>OS/2 that makes time spent trying to coax an Open Source project to >>>compatitability with it's completely non-traditional model, a waste of >time >>>and effort. >>> >>>-----Original Message----- >>>From: Hakan [mailto:agents at meddatainc.com] >>>Sent: Monday, December 02, 2002 10:39 AM >>>To: os2-unix at eyup.org >>>Subject: RE: wxWindows-2.3.4 >>> >>> >>>Dave, >>> >>>Can you tell us what the compatibility problems were? I am currently >>>using VAC++ 4 for one of my own projects, mainly, but not solely, due >>>to its greater conformance with standard C++, and would surely be >>>interested in knowing what the issues are with respect to the code for >>>vxWindows. >>> >>>Thanks. >>> >>>Hakan >>> >>>On Mon, 2 Dec 2002 08:03:12 -0600, Dave Webster wrote: >>> >>>>Users might see the VA4 build files in the distribution but I abandoned >>>>maintaining those about a year or so ago. Maintenance of VA 4 compilable >>>>code was a real nightmare and since that is now a dead product I didn't >>see >>>>the merit in putting any more effort into maintaining it. >>>> >>>>-----Original Message----- >>>>From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] >>>>Sent: Thursday, November 28, 2002 7:34 AM >>>>To: os2-unix at eyup.org >>>>Subject: Re: wxWindows-2.3.4 >>>> >>>> >>>>On Thu, 28 Nov 2002, Adrian Gschwend wrote: >>>> >>>>> you are using GCC to compile it right? I tried with VAC some month ago >>>>> but it failed (can't remember where, didn't had the time to check it >>>>> more). >>>> >>>>Exactly. VAC++ 3 (which is what David who is doing all the work is using) >>>>should work just as well (or even better), while VAC++ 4 is a real >>>>problem... >>>> >>>> Regards, >>>> Stefan >>>>-- >>>>Micro$oft is not an answer. It is a question. The answer is 'no'. >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > **= Email 29 ==========================** Date: Mon, 2 Dec 2002 19:18:21 -0800 (PST) From: Steve Wendt Subject: RE: wxWindows-2.3.4 On Mon, 2 Dec 2002, Hakan wrote: > Well, VA 3.x is no longer supported either and VAC++ 4. offers some > level of conformance with standard C++. VA 3.6.5 is still getting fixes, thanks to IBM's Mozilla team. **= Email 30 ==========================** Date: Mon, 2 Dec 2002 19:18:58 -0800 (PST) From: Steve Wendt Subject: RE: wxWindows-2.3.4 On Mon, 2 Dec 2002, Hakan wrote: > any code generation problems. I know that the version 4 of the > compiler also comes with a command-line version of the compiler and > other tools which I *assume* is what is being used by the IDE itself > and thus should be as conformant as the IDE version. I think all of the command-line stuff is version 3.6.5. **= Email 31 ==========================** Date: Mon, 02 Dec 2002 23:36:33 -0800 From: Ken Ames Subject: Re: wxWindows-2.3.4 hi Dave, I am currently stumped. I do a fresh "cvs checkout wxOS2" and I get it but a LOT of the cvs files are older then what is packaged in the 2.3.4 release. I think this is why I am not seeing the new files you committed. the cvs web page on wxwindows.org says doing the above should send the development branch but doesn't seem to send the latest stuff. I have even done a full checkout with no help either. I MUST be missing something. Maybe you have an explanation (I hope). I look forward to hearing back and thanks. Ken Dave Webster wrote: >When did you do the update? If it was this weekend then the files didn't >yet make it. It was late Sunday night (US Central time) that I finally got >the last files updated. Compiled just fine here this morning. Can speak to >EMX but VA 3.0 FP8 is currently compilable. Sorry for the confusion, but >try another synch, you should get several OS/2 .h and .cpp plus a new >intl.cpp file from /common at the very least. > >-----Original Message----- >From: Ken Ames [mailto:kenames at pacbell.net] >Sent: Monday, December 02, 2002 3:35 PM >To: os2-unix at eyup.org >Subject: Re: wxWindows-2.3.4 > > >you did not explicitely but did imply or I was imagining. whatever the >case but my problem remains. vac 3.0 with fixpak 8 applied will NOT >compile wxOS2. I did a cvs update from the cvs server listed on >wxWindows home page and got 0 (zero) updated files so, cvs needs repair >on their end. either in the readme files or setup postings or whatever. >I repeat, I am trying to use VAC 3.0 with fixpak 8 applied and compile >does NOT work > >Dave Webster wrote: > > > >>Where did I say gcc? icc (.icc) are VA 4.0 build files not gcc (EMX). >>Stefan has a working EMX (gcc) distrubution, but I personally use VA3.0 FP8 >>and now have a clean compiling version for both static and dynamic >> >> >libraries > > >>on the latest CVS tree. You are free to use gcc/EMX or VA 3.0 FP8 against >>Os2 toolkit V4.5 or later. Both work just fine. Watcom C++ support is >>unknown since neither Stefan nor I use it and no one else has tried it. >> >> >> >> >can you point to the latest cvs tree?U >mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/panels.rdf >U mozilla/l10n/langpacks/en-GB/defaults/profile/en-GB/search.rdf > >checkout finish: Mon Dec 2 11:04:39 pst 2002 >Generating configures using autoconf >SYS1079: << was unexpected at this time. >configure.in:37: error: m4_file_append: cannot write: /tmp/forbidden.rx >configure.in:37: the top level >gmake.exe[1]: *** [real_checkout] Error 2 >gmake.exe[1]: Leaving directory `/' >gmake: *** [checkout] Error 2 > > > > >>-----Original Message----- >>From: Ken Ames [mailto:kenames at pacbell.net] >>Sent: Monday, December 02, 2002 2:00 PM >>To: os2-unix at eyup.org >>Subject: Re: wxWindows-2.3.4 >> >> >> >> >>Dave Webster wrote: >> >> >> >> >> >>>There are icc files for an OS/2 build on the CVS tree, still. You are >>>welcome to download them and fiddle with them if you desire. They worked >>>quite well once upon a time. >>> >>> >>> >>> >>> >>> >>vac 3 with fixpak 8 applied is what I have been trying to use. I guess >>you want me to use gcc so I will. :) >>they seem to work rather inconsistent now. Yuri Dario says my latest >>error looks like an ilib bug and I agree. >> >> >> >the last sentence above indicated you wanted me to use gcc. If it is not >an ilib bug please tell me. > > > >> >> >> >> >>>The single biggest bug on VA4 is it's HUGE memory leak. On a system with >>>128MB ram the wx build generates and OS/2 swap file over 256MB large. On >>>smaller systems, it just crashes on every build. There are, at time of >>> >>> >IBM > > >>>dropping support, over 1000 APARS against this version covering various >>>issues. And at $1800 for a non-supported, buggy product, who'd ever buy >>> >>> >it > > >>>that didn't otherwise get it for free? >>> >>> >>> >>> >>> >I have a copy of VAC4. I do NOT use it, buggy! no good. crashes, etc.... >everyone knows vac4 story - dead end. > > > >>I have it, bought it from mensys, dont use it, crashes too much and >>generates some bad code. >> >> >> >> >> >>>It is also an enormous CPU and memory hog. Don't even try using it on a >>>system less than PIII650 with less than 256MB ram. A lot of OS/2 users >>> >>> >>> >>> >>have >> >> >> >> >>>much smaller systems than that. While I have no problem with VA 3.0 FP8 >>> >>> >on > > >>>a old PII 266 with 64MB ram, VA4 won't even run. And one of the biggest >>>selling features left for OS/2 or eCS is it's very small footprint, even >>> >>> >>> >>> >>for >> >> >> >> >>>developers. >>> >>>VA4 is definitely on the cutting edge of C++ standards and development >>>environment. In fact, it probably too far ahead for comfort. Its >>> >>> >>> >>> >>technical >> >> >> >> >>>superiority is not enough to overcome the enormous inertia behind the >>>traditional header/makefile build paradigm. And of course, it's most >>> >>> >fatal > > >>>flaw, is it is no longer supported by anyone. At least VA 3.x is a >>> >>> >mature, > > >>>debugged, product, even if discontinued. >>> >>>I just wish Watcom could get up to snuff. As it is, it is not even as >>> >>> >good > > >>>as VA 3.0 FP 8 and EMX is just too "Unix-like" for me to bother with. >>> >>> >What > > >>>we need is the Watcom compiler complete with the latest OS/2 toolkit WITH >>> >>> >a > > >>>fully impelemented stl library. But the codestore is a concept whose time >>>is still YEARS away from being accepted by the masses. >>> >>> >>> >>> >>> >>watcom is coming along. c++ compiler is a topic of discussion lately. >>seems they are going to start on it soon (I hope). >> >> >> >> >> >as it stands from here at the moment, wxOS2 is unbuildable with vac3.08 >so I am hoping you will supply the missing pieces. >please excuse anything that may seem like I am trying to make you angry >as I am most definitly NOT trying to do that. I am simply trying to get >a cross platform solution in place here. wxOS2 has been far to long in >coming but I realize you are a busy man and still must make a living. > >Ken > > > > > >