Date: Thu, 9 Dec 2004 00:04:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 471 ************************************************** Wednesday 08 December 2004 Number 471 ************************************************** Subjects for today 1 Re: Updating config.guess : John Poltorak 2 Re: Updating config.guess : Henry Sobotka 3 Re: Updating config.guess : Henry Sobotka 4 Re: Updating config.guess : Andreas Buening 5 Re: Updating config.guess : John Poltorak 6 Re: Updating config.guess : Knut St. Osmundsen" 7 Re: Python built with gcc 3.3.5 ? : Andrew MacIntyre 8 Re: Updating config.guess : Stefan.Neis at t-online.de 9 Re: Updating config.guess : Stefan.Neis at t-online.de 10 Re: Python built with gcc 3.3.5 ? : John Poltorak **= Email 1 ==========================** Date: Tue, 7 Dec 2004 13:35:03 +0000 From: John Poltorak Subject: Re: Updating config.guess On Mon, Dec 06, 2004 at 07:17:25PM -0500, Henry Sobotka wrote: > What do people think of the idea of updating config.guess to distinguish > between EMX and INNOTEK LIBC? With the patch below, it spits out either > "i386-pc-os2-innotek" or "i386-pc-os2-emx" depending on which compiler > is used. This probably needs some thinking about... Can you explain why we need it? Personally I'm not keen on seeing the names of commercial companies embedded in open source software, although I'm very pleased that Innotek are funding the life extension of OS/2. If we have to differentiate I'd prefer to see an identifier such as i386-pc-os2-libc or preferably something like i386-pc-os2-posix. > h~ > > -----PATCH (based on autoconf-2.49c/config.guess dated 1-24-01)----- Why not base any change on the config.guess which comes with automake 1.9.3 ? -- John **= Email 2 ==========================** Date: Tue, 07 Dec 2004 12:30:28 -0500 From: Henry Sobotka Subject: Re: Updating config.guess Stefan.Neis at t-online.de wrote: > > Is that difference really relevant on the configure level? > Configure tends to test for lots of individual functions anyway, > so I assume that handles anything which is available for only > one of the two compilers anyway... In migrating to the new LIBC, I don't think we should destroy existing code for EMX builds, whether at the configure or app level. The *os2* block in a configure case switch may no longer be necessary. With the differentiation, we could simply change it to *os2-emx; or add an *os2-innotek if we need something that might break an EMX build. Also, with apps that use the host/target string as part of the installation path, it would make it easier to keep builds separate automatically. And right now, during the transition phase, multiple builds are probably more likely and important than, say, in a year or two. > And binaries available/to be used are the same anyway, > aren't they? I'm only now getting some free time to play around with gcc 3.3.5, so I'm not at all familiar with the details. But I do recall someone on this list mentioning a few weeks ago that it's a whole new world. > I guess autoconf maintainers won't like a patch that actually calls > a compiler and generated binary from within config.guess. Actually configure.guess is full of code, including chunks of raw ASM for some systems, that creates and compiles a dummy.c or dummy.s, outputs the string, and cleans up. h~ **= Email 3 ==========================** Date: Tue, 07 Dec 2004 12:49:06 -0500 From: Henry Sobotka Subject: Re: Updating config.guess John Poltorak wrote: > > This probably needs some thinking about... Can you explain why we need it? Because we're talking about apples and oranges, two different toolkits and two different runtime libraries, and I think we should try to keep them separate. > Personally I'm not keen on seeing the names of commercial companies > embedded in open source software, although I'm very pleased that Innotek > are funding the life extension of OS/2. If we have to differentiate I'd > prefer to see an identifier such as i386-pc-os2-libc or preferably > something like i386-pc-os2-posix. Cygwin for all intents and purposes is a trade name. When a company invests time and money in open source, the least we can do is give them credit for it. "libc" and "posix" are too general. Don't forget, there's also OpenWatcom. > Why not base any change on the config.guess which comes with automake 1.9.3 ? I simply grabbed the newest config.guess on my machine. I don't know where the "master" config.guess lives. My intention is simply to float the concept and find out what people think. config.sub might also require a patch; I haven't looked. h~ **= Email 4 ==========================** Date: Tue, 07 Dec 2004 20:58:36 +0100 From: Andreas Buening Subject: Re: Updating config.guess Henry Sobotka wrote: > > John Poltorak wrote: > > > > This probably needs some thinking about... Can you explain why we need it? > > Because we're talking about apples and oranges, two different toolkits > and two different runtime libraries, and I think we should try to keep > them separate. [...] > Cygwin for all intents and purposes is a trade name. When a company > invests time and money in open source, the least we can do is give them > credit for it. "libc" and "posix" are too general. Don't forget, there's > also OpenWatcom. It's not the purpose of the autotools to give credit to anybody. ;-) First, the i386-pc-os2-emx or whatever string is typically not used for anything. To be exactly, I don't know any package that evaluates the OS string. Maybe gcc? Second, the goal of configure is to test for features, i.e., supported functions, headers and so on, not for the name of the OS. Third, what's the big difference between emx and Innotek's libc? It's basically the same system. Not like the difference between cygwin and mingw which needs a completely different treatment (drive letters versus one root file system, "\n" versus "\r\n" for linebreaks and so on). ilibc has functions that are not provided by emx, and the number of supported Unix/BSD/Posix functions will increase in the future. So what's the best way to deal with emx vs. ilibc? Test whether the libc provides a certain function (fork, seteuid, whatever) and provide __EMX__ or __INNOTEK__ fallbacks for unsupported functions. If you put an #ifdef __INNOTEK__ into the code today, the missing function might be supported tomorrow. And the fundamental features like drive letters, backslashes and linebreaks need a special treatment, anyway (which is basically the same for emx and ilibc). Just my 0.02 cents. > I simply grabbed the newest config.guess on my machine. I don't know > where the "master" config.guess lives. There is some subdirectory of ftp://ftp.gnu.org/gnu/ where these files should be available (I don't remember the name). Bye, Andreas **= Email 5 ==========================** Date: Tue, 7 Dec 2004 21:23:30 +0000 From: John Poltorak Subject: Re: Updating config.guess On Tue, Dec 07, 2004 at 08:58:36PM +0100, Andreas Buening wrote: > > > I simply grabbed the newest config.guess on my machine. I don't know > > where the "master" config.guess lives. > > There is some subdirectory of ftp://ftp.gnu.org/gnu/ where these files > should be available (I don't remember the name). ftp://ftp.gnu.org/pub/gnu/config > Bye, > Andreas -- John **= Email 6 ==========================** Date: Wed, 08 Dec 2004 00:57:18 +0100 From: "Knut St. Osmundsen" Subject: Re: Updating config.guess Andreas Buening wrote: > Henry Sobotka wrote: > >>John Poltorak wrote: >> >>>This probably needs some thinking about... Can you explain why we need it? >> >>Because we're talking about apples and oranges, two different toolkits >>and two different runtime libraries, and I think we should try to keep >>them separate. > > > [...] > > >>Cygwin for all intents and purposes is a trade name. When a company >>invests time and money in open source, the least we can do is give them >>credit for it. "libc" and "posix" are too general. Don't forget, there's >>also OpenWatcom. > > > It's not the purpose of the autotools to give credit to anybody. ;-) > > First, the i386-pc-os2-emx or whatever string is typically not used > for anything. To be exactly, I don't know any package that evaluates > the OS string. Maybe gcc? GCC and binutils certainly uses that string. All the crosscompiling stuff is using that stuff too to check if it's actually crosscompiling. For convenience I think it's best to stick with i386-pc-os2-emx at unless we're suddenly badly incompatible with os2-emx in some crazy way. > Second, the goal of configure is to test for features, i.e., supported > functions, headers and so on, not for the name of the OS. > > Third, what's the big difference between emx and Innotek's libc? > It's basically the same system. Not like the difference between > cygwin and mingw which needs a completely different treatment (drive > letters versus one root file system, "\n" versus "\r\n" for linebreaks > and so on). ilibc has functions that are not provided by emx, and > the number of supported Unix/BSD/Posix functions will increase in the > future. So what's the best way to deal with emx vs. ilibc? > Test whether the libc provides a certain function (fork, seteuid, > whatever) and provide __EMX__ or __INNOTEK__ fallbacks for unsupported > functions. If you put an #ifdef __INNOTEK__ into the code today, the > missing function might be supported tomorrow. And the fundamental > features like drive letters, backslashes and linebreaks need a > special treatment, anyway (which is basically the same for emx and ilibc). > > Just my 0.02 cents. For correctness make that __INNOTEK_LIBC__. The most common stuff will actually be changing: #ifdef __EMX__ #else /* !__EMX__ */ #endif /* !__EMX__ */ to #if defined(__EMX__) && !defined(__INNOTEK_LIBC__) #else /* !__EMX__ || __INNOTEK_LIBC */ #endif /* !__EMX__ || __INNOTEK_LIBC */ because the new libc supports a few things old emx didn't. Just my two cents Kind Regards, knut **= Email 7 ==========================** Date: Wed, 8 Dec 2004 09:17:09 +1100 (EST) From: Andrew MacIntyre Subject: Re: Python built with gcc 3.3.5 ? On Tue, 7 Dec 2004, John Poltorak wrote: > Has there been any progress on building Python with gcc 3.3.5? Not by me, as I dont (yet) have a gcc 3.3.5 installation. WRT your stack problem with Zope/Plone, its occurred to me that the stack overflow might be in a thread, which uses a completely different stack whose size is set in the _beginthread() call when creating the thread. I've just checked, and the thread stack size is currently hardcoded to 64k. To test this theory, change the "65536" in the _beginthread() call at line 34 in Python/thread_os2.h to "262144" (which is 256k). I now recall seeing Python bug tracker reports that indicate 64k (the default for pthreads on Unix) was too low and that 128k or 256k was safer with Zope. This is especially true with gcc 3.x compilers, which are generating increasingly large stack frames compared to the 2.x compilers. I will make this easier to change - the pthreads support recognises a THREAD_STACK_SIZE macro which can be put in pyconfig.h, which I think I'll use. ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 8 ==========================** Date: Wed, 8 Dec 2004 11:38:29 +0100 From: Stefan.Neis at t-online.de Subject: Re: Updating config.guess Hi, > > Is that difference really relevant on the configure level? > > Configure tends to test for lots of individual functions anyway, > > so I assume that handles anything which is available for only > > one of the two compilers anyway... > > In migrating to the new LIBC, I don't think we should destroy existing > code for EMX builds, whether at the configure or app level. The *os2* > block in a configure case switch may no longer be necessary. With the > differentiation, we could simply change it to *os2-emx; Well, looking at wxWindows, it currently _is_ *os2-emx at all relevant locations in configure.in and adding that artificial distinctions would require changing "all" those to *os2*. Of course it no problem if that's the only configure.in that's going to need changing, but I somewhat expect it to be the typical case. > Also, > with apps that use the host/target string as part of the installation > path, it would make it easier to keep builds separate automatically. I think I've only ever seen that for gcc. > And > right now, during the transition phase, multiple builds are probably > more likely and important than, say, in a year or two. ACK. > > And binaries available/to be used are the same anyway, > > aren't they? > > I'm only now getting some free time to play around with gcc 3.3.5, so > I'm not at all familiar with the details. But I do recall someone on > this list mentioning a few weeks ago that it's a whole new world. Well, yes and no. It certainly _was_ a very different world at the time of gcc-3.2.2 with limitations and features that just where different from EMX. With all the great work Knut is putting into the new libc it's more and more becoming a true superset of EMX libraries, i.e. it offers everything EMX offered and lots of additional functions (like stuff related to symlinks). The one thing, that's really different is that it's using ".o", no matter if it's compiling for a.out or OMF format, but then, that suffix name should be autodetected by configure anyway. > > I guess autoconf maintainers won't like a patch that actually calls > > a compiler and generated binary from within config.guess. > > Actually configure.guess is full of code, including chunks of raw ASM > for some systems, that creates and compiles a dummy.c or dummy.s, > outputs the string, and cleans up. Ah, OK. I somehow seemed to remember that config.guess essentially evaluates uname output. I should have looked at it prior to claiming something ... ;-) Regards, Stefan **= Email 9 ==========================** Date: Wed, 8 Dec 2004 12:07:31 +0100 From: Stefan.Neis at t-online.de Subject: Re: Updating config.guess Hi, > > Cygwin for all intents and purposes is a trade name. When a company > > invests time and money in open source, the least we can do is give them > > credit for it. "libc" and "posix" are too general. Don't forget, there's > > also OpenWatcom. > > It's not the purpose of the autotools to give credit to anybody. ;-) Agreed. But going through extra hoops and intentionally obfuscating things by not using "-innotek" should not be necessary, either. > First, the i386-pc-os2-emx or whatever string is typically not used > for anything. To be exactly, I don't know any package that evaluates > the OS string. Maybe gcc? Well have a look at e.g. wxWidgets' configure: http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/configure.in?rev=1.902&content-type=text/vnd.viewcvs-markup It's running some tests only on certain platform, it's deciding about the flags to be used to enable thread support based on that string, it's even deciding about the validity of certain options based on that OS string (e.g. configure --with-pm (as opposed to e.g. configure --with-gtk) is valid only on *os2-emx|*os2_emx). > Second, the goal of configure is to test for features, i.e., supported > functions, headers and so on, not for the name of the OS. Yes, but what's the point in wasting time to test for e.g. pthread support on OS/2 (and a failing test might even make the user install the pthreads library that's available and rerun everything) if the code is using native threads os OS/2 anyway? Basically, I think there are valid uses of the name of the OS, however I fail to imagine a sample where the distinction between Innotek and LIBC is relevant **= Email 10 ==========================** Date: Wed, 8 Dec 2004 11:13:58 +0000 From: John Poltorak Subject: Re: Python built with gcc 3.3.5 ? On Wed, Dec 08, 2004 at 09:17:09AM +1100, Andrew MacIntyre wrote: > On Tue, 7 Dec 2004, John Poltorak wrote: > > > Has there been any progress on building Python with gcc 3.3.5? > > Not by me, as I dont (yet) have a gcc 3.3.5 installation. Given what you say below, a gcc 3.3.5 build would not make any difference to the prolems experienced... > WRT your stack problem with Zope/Plone, its occurred to me that the > stack overflow might be in a thread, which uses a completely different > stack whose size is set in the _beginthread() call when creating the > thread. > > I've just checked, and the thread stack size is currently hardcoded to > 64k. > > To test this theory, change the "65536" in the _beginthread() call at line > 34 in Python/thread_os2.h to "262144" (which is 256k). > > I now recall seeing Python bug tracker reports that indicate 64k (the > default for pthreads on Unix) was too low and that 128k or 256k was safer > with Zope. This is especially true with gcc 3.x compilers, which are > generating increasingly large stack frames compared to the 2.x compilers. > > I will make this easier to change - the pthreads support recognises a > THREAD_STACK_SIZE macro which can be put in pyconfig.h, which I think I'll > use. Fingers crossed, but it does appear that you have hit the nail on the head. A rebuild of Python with the change you mentioned is powering Zope just now and the almost immediate stack problem associated with Plone is currently absent. I'm very pleased about this. Many thanks!!! > ------------------------------------------------------------------------- > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 > andymac at pcug.org.au (alt) | Belconnen ACT 2616 > Web: http://www.andymac.org/ | Australia -- John