Date: Thu, 14 Apr 2005 00:04:24 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 540 ************************************************** Wednesday 13 April 2005 Number 540 ************************************************** Subjects for today 1 Re: Python 2.4.1 EMX port released. : Knut St. Osmundsen" 2 Re: Python 2.4.1 EMX port released. : Andrew MacIntyre 3 Re: xvidcore : Paul Smedley" 4 Re: Python 2.4.1 EMX port released. : Stefan.Neis at t-online.de 5 Compiling Apache2 with Innotek GCC : Paul Smedley **= Email 1 ==========================** Date: Tue, 12 Apr 2005 16:09:35 +0200 From: "Knut St. Osmundsen" Subject: Re: Python 2.4.1 EMX port released. Stefan.Neis at t-online.de wrote: > Steven Levine schrieb: > > >>FWIW, many ported unix apps would be easier to manage >>under OS/2 if there was a way to control the thread stack >>size either with a configuration variable or an enviroment >>variable. > > > Maybe that's something to ask Knut for (which of course will > only help programs created with Innotek's libc)... > Not sure what you mean by a "configuration variable", but I > don't think it would be very difficult to check an environment > variable for wanted stack size on thread creation. Maybe > something like "if the call passes in '0' as stack size, check > the environment variable and set the stack size accordingly, > use default value if no environment variable found". Or maybe > use '-1' or some other value that's sure to not be currently used > to trigger the new behaviour. That way, all programs wanting > to support configurable thread stack size would still need to > be slightly modified and recompiled, but that shouldn't be a > big problem. It should work like a MAX(cbEnvStackSize, cbCallerSpecifiedStacksize). I'll look into it when I have a LIBC weekend again (should be soon now). > Of course, thread creation is probably protected by a mutex, > so anything increasing the time during which the mutex is > locked is probably bad, but I hope that looking up an > environment variable is not going to take long enough to > cause a real problem. getenv isn't all that fast, but it'll be done for the first call only so it won't be much of a problem. Don't know if I'm doing DosCreateThread inside a mutex, the getenv can safely be done outside such a lock. Kind Regards, knut **= Email 2 ==========================** Date: Wed, 13 Apr 2005 09:18:54 +1100 From: Andrew MacIntyre Subject: Re: Python 2.4.1 EMX port released. Knut St. Osmundsen wrote: > Stefan.Neis at t-online.de wrote: >> Steven Levine schrieb: >>> FWIW, many ported unix apps would be easier to manage >>> under OS/2 if there was a way to control the thread stack >>> size either with a configuration variable or an enviroment >>> variable. >> >> Maybe that's something to ask Knut for (which of course will >> only help programs created with Innotek's libc)... >> Not sure what you mean by a "configuration variable", but I >> don't think it would be very difficult to check an environment >> variable for wanted stack size on thread creation. Maybe >> something like "if the call passes in '0' as stack size, check >> the environment variable and set the stack size accordingly, >> use default value if no environment variable found". Or maybe >> use '-1' or some other value that's sure to not be currently used >> to trigger the new behaviour. That way, all programs wanting >> to support configurable thread stack size would still need to >> be slightly modified and recompiled, but that shouldn't be a >> big problem. I agree that _beginthread should accept a value of 0 to mean "platform default" as it does on Win32. At the moment, neither VAC++ or EMX libc handle this from the docs I have. This should be a useful minimum (VAC++ docs say 8kB & must be multiples of 4kB; EMX docs say minimum 32kB; I would suggest either 32kB or 64kB), and understand the environment variable as proposed above. > It should work like a MAX(cbEnvStackSize, cbCallerSpecifiedStacksize). > I'll look into it when I have a LIBC weekend again (should be soon now). I don't agree with this in the face of fully committed thread stacks - second guessing the programmer specifying a specific non-zero (ie non-default) stack size could be quite awkward in some cases. IMO a better (but more work) approach would be to support branding the value into the exe ala emxbind, or a commandline option (like -s for EMX.EXE). If Innotek's libc can avoid fully committing the thread stacks, then Knut's suggestion is Ok by me. As far as Python is concerned, I have a patch in development that will make setting the thread stack size an option via a function in Python's thread module (which can then be set in sitecustomise.py or an application's main script). This turns out to be useful on other platforms (notably FreeBSD, and probably other BSDs) as well as OS/2, because they have a default thread stack size that it is too small for Zope et al. I plan to have this patch in Python 2.5, and will probably release it in my binary distribution of Python 2.4.2 when it appears later this year (it won't be accepted into the 2.4 branch sources as an API change). ------------------------------------------------------------------------- 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 3 ==========================** Date: Wed, 13 Apr 2005 14:04:06 +0930 From: "Paul Smedley" Subject: Re: xvidcore On 10/4/2005, "Dave Yeo" wrote: >On Sun, 10 Apr 2005 20:42:26 +0930, Paul Smedley wrote: > >>Hi All, >>Has anyone tried compiling xvidcore >>(http://downloads.xvid.org/downloads/xvidcore-1.1.0-beta2.zip) under OS/2. >> >>I've tried this today and all I get on running make is: >>[STUDY|e:/dev/xvidcore-1.1.0-beta2/build/generic]make >> L: libxvidcore.a >>ar: decoder.o: No such file or directory >>make: *** [libxvidcore.a] Error 1 >>[STUDY|e:/dev/xvidcore-1.1.0-beta2/build/generic]exit >> >>I'm kind of suspecting the makefile is broken on OS/2. > >Just tried, I'd say the makefile is broken on OS/2 or its a make bug. Got the same output as you. >I'd say your going to have to write an OS/2 makefile especially if you want a DLL I got a bit further with this. The configure script is generating a seriously broken platform.inc with the OS/2 specific stuff in it. I compared the platform.inc that configure generated with a platform.inc from mingw (GCC for Windows) and at least got some gcc action :) Makefile also has issues as it can't find the source correctly - I need a makefile 101 lesson so that I can try and work out what's happening!! Cheers, Paul. **= Email 4 ==========================** Date: Wed, 13 Apr 2005 12:33:49 +0100 From: Stefan.Neis at t-online.de Subject: Re: Python 2.4.1 EMX port released. Hi, > > It should work like a MAX(cbEnvStackSize, cbCallerSpecifiedStacksize). > > I'll look into it when I have a LIBC weekend again (should be soon now) **= Email 5 ==========================** Date: Wed, 13 Apr 2005 20:25:33 +0930 From: Paul Smedley Subject: Compiling Apache2 with Innotek GCC Hi All, I thought I'd take a shot at compiling Apache 2 2.0.53 this evening using Innotek GCC. Unfortunately I didn't even get through the configure script, with it dying with: checking for ld used by gcc... ./configure.lineno: s%\\%/%g: No such file or directory no configure: error: no acceptable ld found in $PATH of course, if I run ld from the same prompt, it is found. Any ideas? Cheers, Paul.