Date: Fri, 15 Apr 2005 00:14:53 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 541 ************************************************** Thursday 14 April 2005 Number 541 ************************************************** Subjects for today 1 Re: Compiling Apache2 with Innotek GCC : Dave Yeo" 2 Re: Python 2.4.1 EMX port released. : Knut St. Osmundsen" 3 Re: Compiling Apache2 with Innotek GCC : Paul Smedley" **= Email 1 ==========================** Date: Wed, 13 Apr 2005 07:37:37 -0800 From: "Dave Yeo" Subject: Re: Compiling Apache2 with Innotek GCC On Wed, 13 Apr 2005 20:25:33 +0930, Paul Smedley wrote: >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? Set LD=ld.exe Dave **= Email 2 ==========================** Date: Wed, 13 Apr 2005 20:46:43 +0200 From: "Knut St. Osmundsen" Subject: Re: Python 2.4.1 EMX port released. Andrew MacIntyre wrote: > 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). Win32 will only use the value passed on to _beginthread as the size of the committed stack part. It will allocate a stack as specified in the executable. Which is similar to what I suggested, and you can see my argument for not bothering with having part of the stack uncommitted. As for storing it in executable would probably be cool, but alas it's more expensive to get to than a getenv() and there is the question of where to put it (could use the thread 1 size of course). So using an env.var. seems like a good enough option to me - it's not something you normally would end up doing in any case. The solution to beginthread(..0..) will of course be set to some sensible default (512kb or more is a sensible defaul imho) if the environment variable is not there to overrule it. > If Innotek's libc can avoid fully committing the thread stacks, then > Knut's suggestion is Ok by me. You mean use guardpages?!? IIRC OS/2 2.x+ doesn't bother with committing pages until they are actually touched (at least it's not doing that for most other kind of memory object - see on demand loading of pages of code/data in ..exe/.dll). Guard pages are expensive because they trigger exceptions, they requires stack probing. The result is larger and slower code. So, I see absolutly no reason to use this feature. Looking into how the stack of the main thread is configured is on my todo list. Anyway, it's virtual address space and not physical which is the OS/2 problem of today. Kind Regards, knut **= Email 3 ==========================** Date: Thu, 14 Apr 2005 10:18:25 +0930 From: "Paul Smedley" Subject: Re: Compiling Apache2 with Innotek GCC Heya Dave, On 13/4/2005, "Dave Yeo" wrote: >On Wed, 13 Apr 2005 20:25:33 +0930, Paul Smedley wrote: > >>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? > >Set LD=ld.exe Duh! I should have known that.... senior moment... :) That got configure running at least - will see how make went when I get home. Cheers, Paul.