Date: Sun, 4 Jan 2004 00:04:02 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 282 ************************************************** Saturday 03 January 2004 Number 282 ************************************************** Subjects for today 1 Innotek GCC 3.2.1 Beta3 status : Dave Webster 2 Re: Innotek GCC 3.2.1 Beta3 status : Steve Wendt" 3 Re: Innotek GCC 3.2.1 Beta3 status : Yuri Dario" 4 Re: Innotek GCC 3.2.1 Beta3 status : Yuri Dario" 5 Re: perl question : Lyn St George" 6 Re: perl question : Lyn St George" **= Email 1 ==========================** Date: Fri, 2 Jan 2004 15:11:02 -0600 From: Dave Webster Subject: Innotek GCC 3.2.1 Beta3 status Just to let you know what I've uncovered with Innotek's latest Beta release. I have a very large, very up-to-date C++ library that I thought would be a real good stress test for this release. It came close, but I did have some problems. Here is what I posted on Innotek's problem forum, FYI: I have spent sevaral days now getting my very large library to compile and here is a list of the problems I have encountered so far. I have attempted builds with and without -Zomf. With -Zomf: For now, since the link to iLink V5.0 is broken, I set EMXOMFLD_TYPE=VAC308, as that is the best I have. emxomf on several subsystems warns about a type_tag being too long. Build continues but lots of warnings. Finally, on a subsystem towards the end of the build the whole thing dies with a "record too long" fatal error. I make use of a lot of nested classes for asynchronous operations call functor callbacks. Some of these have relatively long names, so I imagine that is the problem. This forced me to abandon all efforts to build with -Zomf. Without -Zomf (ld and emxbind): Got much further here but still a notable problem. Static builds go fine all the way through, and all my sample apps seem to work OK with static builds. Release (optomized) DLL builds seem OK, too. Trouble comes with debug (symbol table included) DLL builds. GCC322.DLL craps out with a c00000005 fatal error trying to link the debug DLL and complains about a lack of stack space available to even throw it's exception! Once again, this library is quite large, containing over 500,000 lines of code, in over 100 separate source modules. It appears either ld or emxbind (whatever is using gcc322.dll) has too small a stack to hold something that big. Only other issue is with a perplexing unresolved external in a secondary dll build of an inlined class template function. The method is declared in a class and an external "friend" function returning a std::ostream reference with a templated function arguement of ATtype. The function is defined in an included inline file. When a secondary subsystem attempts to instantiate the function with an unsigned long for AType, the linker fails to resolve the call even though the function definition, itself is "included" in the source! Very odd as gcc3.3.1 under linux or Visual Studio.NET under WIN32 do not seem to have a problem with it. Another problem I have not really delved into yet, seems to be the inability to load debug exes into gdb (using ld/emxbind build, no -Zomf). Is there a compatible version of gdb I should be using? In summary, I'm somwhat pleased. I have a VERY rigorous, very ISO compliant library and this compiler seems to handle 99.5% of it. If I can get that last .5% I working (mostly dll related stuff), I'll be in business under OS/2 again. In summary, so far: -Zomf is a dead duck for C++ code that contain a lot of nested classes, especially if the nested classed are template classes. Or a lot of templated class methods or template functions declared as class friends. Extremely large DLL builds blow GCC322.DLL up for an apparent lack of stack space. GCC3.3.1 for Linux and Visual Studio.NET have no problem with this library build at all. So it is close, but it still needs some work to be robust enough for me to actually use. As it is, I can probably use it for statically linked stuff as is. But DLL's are a bust for now. Will wait to see their response. I am hopeful these DLL issues can be resolved before the final release. Good news is strict ISO C++ support seems pretty good. **= Email 2 ==========================** Date: Fri, 02 Jan 2004 13:59:06 -0800 (PST) From: "Steve Wendt" Subject: Re: Innotek GCC 3.2.1 Beta3 status On Fri, 2 Jan 2004 15:11:02 -0600, Dave Webster wrote: >Another problem I have not really delved into yet, seems to be the inability >to load debug exes into gdb (using ld/emxbind build, no -Zomf). Is there a >compatible version of gdb I should be using? I believe that is a known problem that Innotek has no intention of fixing. Apparently there is an (unreleased) IBM debugger that works. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 3 ==========================** Date: Sat, 03 Jan 2004 10:31:12 +0100 (CET) From: "Yuri Dario" Subject: Re: Innotek GCC 3.2.1 Beta3 status Hi, >>to load debug exes into gdb (using ld/emxbind build, no -Zomf). Is there a >>compatible version of gdb I should be using? > >I believe that is a known problem that Innotek has no intention of fixing. gdb requires some major work to support new formats. >Apparently there is an (unreleased) IBM debugger that works. I'm using icsdebug (3.08) and idebug (3.6) here, both are working with -Zomf output. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 4 ==========================** Date: Sat, 03 Jan 2004 10:33:16 +0100 (CET) From: "Yuri Dario" Subject: Re: Innotek GCC 3.2.1 Beta3 status Hi, >Extremely large DLL builds blow GCC322.DLL up for an apparent lack of stack >space. GCC3.3.1 for Linux and Visual Studio.NET have no problem with this did you try to change default stack allocation (64k) with -Zstack? Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 5 ==========================** Date: Sat, 03 Jan 2004 11:53:47 +0000 From: "Lyn St George" Subject: Re: perl question On Fri, 02 Jan 2004 08:44:55 +0000 (GMT), Dave Saville wrote: >>#define HAS_GETPWENT /* fake */ >>#define HAS_CRYPT >>#define HAS_CHOWN /* fake */ >>extern int chown(const char *p, uid_t o, gid_t g); >> >>(the last is poached from the wind tree). Ilya Z does not agree with this as >>it may clash with any multi-user method in future, but it does me for now. > >Thanks - I will try this. Do I actually need real exe's to back up >those two fake entries? Certainly not the first. For the second I don't think so, though I've long had a chown.exe (it's in the InetPowerServer package, along with chmod, chgrp and ls) >-- >Regards > >Dave Saville - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting +---------------------------------------------------------------------------------- **= Email 6 ==========================** Date: Sat, 03 Jan 2004 11:53:39 +0000 From: "Lyn St George" Subject: Re: perl question On Fri, 2 Jan 2004 11:14:43 +0000, John Poltorak wrote: >How do tell if an existing Perl was built with chown? One way is 'grep /path/to/perl5/5.8.x/os2 -i chown Config.pm', which returns '' for me (and 'undef' for the chown variants). >> (the last is poached from the wind tree). Ilya Z does not agree with this as >> it may clash with any multi-user method in future, but it does me for now. > >At this point in time would it be preferable to use chown? I could put >the required changes into UX2BS so that it could default to HAS_CHOWN. Hmm ... Ilya was pretty adamant that this is "Bad Idea", though he was talking about some theoretical change in the future. I doubt that Dave S and I are the only ones who find that when chown is lacking from perl then the consequence becomes a PITA. I personally would make it the default, bearing in mind that it's so easy to rebuild perl with some other implementation if need be. - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting +----------------------------------------------------------------------------------