Date: Thu, 4 Mar 2004 00:04:01 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 305 ************************************************** Wednesday 03 March 2004 Number 305 ************************************************** Subjects for today 1 RE: GCC 3.2.2 Beta 4 : Dave Webster 2 RE: GCC 3.2.2 Beta 4 : Dave Webster 3 RE: GCC 3.2.2 Beta 4 : Dave Webster 4 RE: GCC 3.2.2 Beta 4 : Dave and Natalie" 5 Re: EMX - insufficient stack space : Mentore Siesto 6 Re: EMX - insufficient stack space : John Poltorak 7 Re: EMX - insufficient stack space : Steve Wendt 8 [wxos2] Success at OMF build : Dave Webster 9 Re: EMX - insufficient stack space : Steven Levine" **= Email 1 ==========================** Date: Tue, 2 Mar 2004 07:39:05 -0600 From: Dave Webster Subject: RE: GCC 3.2.2 Beta 4 Not working under bash or ash either. Can't figure that one out. Got it work once, but I can't remember what I did at ( at #$*#*# at &$#$!%!!??? -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Tuesday, March 02, 2004 5:13 AM To: 'os2-unix at mail.warpix.org' Subject: RE: GCC 3.2.2 Beta 4 On Mon, 1 Mar 2004, Dave Webster wrote: > Just ran configure after autoconf on the new configure.in and that bk-deps > thing still blows up the command interpreter. Have no idea why. bk-deps is still expecting something like "sh", "ash", or "bash" as command processor, _not_ "cmd"... Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 2 ==========================** Date: Tue, 2 Mar 2004 07:38:21 -0600 From: Dave Webster Subject: RE: GCC 3.2.2 Beta 4 Kind of busy for the next couple of days, but I will give it some time this weekend to get an OMF build. When I do that I may need some assistance to add an OMF option for INNOTEK to configure (so someone could do an --enable-omf type thing). Then there is the shared lib thing. Be nice if --enabled-shared worked, but with OS/2 you need those .def files. You can autogenerate them by putting emxexp in the Makefile, but you have to pass in a static .a or .lib to get the output and put the required lines at the top. Other option is simply build a static lib, even in shared mode and then emit dllar after the build to convert to a .dll. Same as you do now, only automate the step. DLL's are easier to deal with when working on apps because the .exes are so much smaller and build so much quicker, especially in debug mode. -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Tuesday, March 02, 2004 5:07 AM To: 'os2-unix at mail.warpix.org' Subject: RE: GCC 3.2.2 Beta 4 On Mon, 1 Mar 2004, Dave Webster wrote: > I really need to do -Zomf builds as > that is the only way to debug an Innotek compiled object since gdb support > is not there and not likely to ever be there. You still should be able to compile in a.out mode and convert the resulting libs via "emxomf -l"... Of course, that doesn't help with weak symbols. > The minimal link had something to do with that > pmwin.736 or whatever that is. It was late and I didn't have time to figure > that one out. I see. "nm" probably doesn't like OMF mode either, but then, "emxbind -ep" doesn't work anyway to make a PM application, so feel free to simply ignore that error... Regards, Stefan **= Email 3 ==========================** Date: Tue, 2 Mar 2004 08:48:39 -0600 From: Dave Webster Subject: RE: GCC 3.2.2 Beta 4 OK, finally got the a.out minimal to work doing as you suggest below in creating a dummy .def. I did notice that the accelerator keys no longer seem to be working? Has that been in evidence lately? They used to work just fine? Anyway, next step is a successful OMF build. With OMF, you can pass the application type directly to the linker via -linker commands on the command line. And you can debug it. I think you can download Open Watcom and use their debugger as it is an OMF debugger? Anyone confirm that? If that is not the case I can zip up the old VisualAge V3.0 ipmd debugger and get it to you some time. You will also want to get ilink5.0 from IBM at ftp://service.boulder.ibm.com/ps/products/warpzilla/ilink50.zip That is the VisualAge V3.5 linker IBM now makes available for free. Replaces LINK386, a totally obsolete linker. -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Saturday, February 28, 2004 1:46 PM To: Knut St. Osmundsen; os2-unix at mail.warpix.org Subject: Re: GCC 3.2.2 Beta 4 Hi, > I noticed two things while trying to build wxWindows with that build: (snipp) Here comes the third: For linking, I used to not use ".def files" (it's ugly to auto-create them), instead I used to run "emxbind -ep" on the wxWindows exectuables at the end of the build to set the application type to "PM application". With the new gcc build, I just get "emxbind: invalid option". For now, I created a "dummy" .def file and manually added that to the "gcc -o minimal.exe ..." line and now I have the minimal sample up and running, but having to create a definition file everytime I want to link something is not something I actually like. Is there some easier way to set the application type? Passing some suitable option to the linker or a way to make "emxbind -ep" work on the executable again? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Tue, 02 Mar 2004 08:42:57 -0800 From: "Dave and Natalie" Subject: RE: GCC 3.2.2 Beta 4 On Tue, 2 Mar 2004 08:48:39 -0600, Dave Webster wrote: > >I think you can download Open Watcom and use their debugger as it is an OMF >debugger? Anyone confirm that? They were talking about this on the developers list. Seems that Open Watcom uses different debugging info then GCC. Let us know if you find otherwise Dave **= Email 5 ==========================** Date: Tue, 2 Mar 2004 22:56:32 +0100 (CET) From: Mentore Siesto Subject: Re: EMX - insufficient stack space nOn Tue, 2 Mar 2004, John Poltorak wrote: JP >On Tue, Mar 02, 2004 at 11:08:48AM +0100, Mentore Siesto wrote: JP >> On Mon, 1 Mar 2004, John Poltorak wrote: JP >> JP >> JP >What can I do if a program aborts because of insufficient stack space in JP >> JP >EMX? JP >> JP > JP >> JP >Anyone know what triggers this error? JP >> JP >> IIRC emxstack should do the job. JP > JP >What do I do with EMXSTACK? Run it against EMX.DLL? That doesn't appear to JP >do anything. Always IIRC... Some old EMX programs are built with little stack, so running them with newer versions of EMX runtime causes them to abort due to insufficient stack space. You should use emxstack on the executables. The entire procedure is explained in the EMX docs. -- Mentore Siesto Team OS/2 Italia **= Email 6 ==========================** Date: Tue, 2 Mar 2004 22:44:59 +0000 From: John Poltorak Subject: Re: EMX - insufficient stack space On Tue, Mar 02, 2004 at 10:56:32PM +0100, Mentore Siesto wrote: > nOn Tue, 2 Mar 2004, John Poltorak wrote: > > JP >On Tue, Mar 02, 2004 at 11:08:48AM +0100, Mentore Siesto wrote: > JP >> On Mon, 1 Mar 2004, John Poltorak wrote: > JP >> > JP >> JP >What can I do if a program aborts because of insufficient stack space in > JP >> JP >EMX? > JP >> JP > > JP >> JP >Anyone know what triggers this error? > JP >> > JP >> IIRC emxstack should do the job. > JP > > JP >What do I do with EMXSTACK? Run it against EMX.DLL? That doesn't appear to > JP >do anything. > > Always IIRC... > Some old EMX programs are built with little stack, so running them with > newer versions of EMX runtime causes them to abort due to insufficient > stack space. You should use emxstack on the executables. > The entire procedure is explained in the EMX docs. I've already tried this with python.exe and it didn't make any difference having a bigger stack size. I increased it to 16kB, should I have tried a bigger value? > -- > Mentore Siesto > Team OS/2 Italia -- John **= Email 7 ==========================** Date: Tue, 2 Mar 2004 15:05:15 -0800 (PST) From: Steve Wendt Subject: Re: EMX - insufficient stack space On Tue, 2 Mar 2004, John Poltorak wrote: > I've already tried this with python.exe and it didn't make any > difference having a bigger stack size. I increased it to 16kB, should I > have tried a bigger value? A minimum of 32K is probably more useful. **= Email 8 ==========================** Date: Tue, 2 Mar 2004 17:07:34 -0600 From: Dave Webster Subject: [wxos2] Success at OMF build Finally got a complete OMF build along with a running minimal OMF sample. Basically I changed the Makefile to add -Zomf to all the options (both compile and link) in the main Makefile (same in the minimal Makefile). Changed all .o's to .obj's and .a's to .lib's Basically in the main Makefile I now have this: SHARED_LD_CXX = $(CXX) -Zdll -o SHARED_LD_MODULE_CXX = $(CXX) -Zdll -o **= Email 9 ==========================** Date: Wed, 03 Mar 2004 00:44:25 -0800 From: "Steven Levine" Subject: Re: EMX - insufficient stack space In <20040302150452.H23931 at fingers.shocking.com>, on 03/02/04 at 03:05 PM, Steve Wendt said: >> I've already tried this with python.exe and it didn't make any >> difference having a bigger stack size. I increased it to 16kB, should I >> have tried a bigger value? >A minimum of 32K is probably more useful. I agree. For something like Python would recommend at least 128KB to support deeply nested recursion in the interpreter. Of course, if python is multi-threaded, the value set by emxstack is probably unrelated to his problem. FWIW, John quoted a much larger stack value on the OS2-ISP list. One of the values he quoted is a typo. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST) ----------------------------------------------------------------------