From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 31 Oct 2003 14:14:11 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 227 ************************************************** Thursday 30 October 2003 Number 227 ************************************************** Subjects for today 1 autoconf, was: Re: Building Python : Stefan Neis 2 Re: Building Python : Stefan Neis 3 Re: Posix/2 : Stefan Neis 4 Re: Building Python : Dave and Natalie" **= Email 1 ==========================** Date: Fri, 31 Oct 2003 17:30:25 +0100 (CET) From: Stefan Neis Subject: autoconf, was: Re: Building Python > No. Last I knew, Python's configure.in was working with autoconf 2.53 and > I hadn't heard any promising noises about OS/2 versions of autoconf later > than 2.13. Actually, autoconf-2.57 is doing pretty well. After adding a few OS/2 specific lines to configure.in, I'm now even able to successfully run the Unix-generated configure script(s) for wxWindows on my OS/2 system. :-) > configure.in will need some non-trivial changes to get an OS/2 build that: > - does the right thing with threads; > - sets up the core DLL and the associated import libraries correctly; and > - supports dynamicly loadable extensions viably. The first doesn't really sound like a big problem, but the other two sound at least difficult. I suppose you're using export by name for the core DLL? > As it stands, I expect a configure build to result in a monolithic, > staticly linked, python.exe. Such a beast can't support dynamicly loaded > extensions, so the desired extensions have to be manually edited into > Modules/Setup so that they get built into the monolithic interpreter. > This is not overly attractive compared to the dynamic loading support in > the EMX port Makefile. Hm, there are libraries providing dlopen/dlsym/dlclose for OS/2, using those, it might be possible to dynamically load extensions even via a configure-based build without too many problems, but those are just vague guesses on my part... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 2 ==========================** Date: Fri, 31 Oct 2003 17:36:50 +0100 (CET) From: Stefan Neis Subject: Re: Building Python On Thu, 30 Oct 2003, John Poltorak wrote: > > configure.in will need some non-trivial changes to get an OS/2 build that: > > - does the right thing with threads; > > - sets up the core DLL and the associated import libraries correctly; and > > - supports dynamicly loadable extensions viably. > > I don't pretend to understand these things, but I though you could use > newer versions of Autoconf to produce DLLs. It always depends on the package and how it goes about building shared objects/DLLs. If it's using the "right" version of libtool, then chances seem to be quite good that you can get DLLs for OS/2 without too much problems, if it uses a different version or uses its own set of rules, things are different. And if you even want to get backwards compatible ordinals for export by ordinal, you can just forget about doing it via autoconf/configure (one of the reasons why I would prefer export by name, even if it slightly slower). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Fri, 31 Oct 2003 17:47:09 +0100 (CET) From: Stefan Neis Subject: Re: Posix/2 On Wed, 22 Oct 2003, John Poltorak wrote: > What is the current status of Posix/2 Nobody is currently working on it, AFAIK (my spare time available for programming being entirely consumed by wxWindows, currently; situation seems similar for others). Also, it "works for me". > and does the development of libc by > Innotek have any bearing on its future? Personally, I think Posix/2 would be a nice addition on top of Innotek's libc, or could even be incorporated into it over time (although that might result in some licencing debates...) but currently Innotek's libc is missing some core Unix functionality that's required for Posix/2 (most notably unified sockets/file handle space, I think. I don't think Posix/2 contains anything that's using fork(), so the missing fork() is not a problem from the Posix/2 point of view, but it doesn't provide the missing fork() either...) I suppose asking that same question on the Posix/2 mailing list might result in some more reactions/comments... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Fri, 31 Oct 2003 19:10:28 -0800 From: "Dave and Natalie" Subject: Re: Building Python On Fri, 31 Oct 2003 17:36:50 +0100 (CET), Stefan Neis wrote: > And if you even want to get backwards >compatible ordinals for export by ordinal, you can just forget about doing >it via autoconf/configure (one of the reasons why I would prefer export by >name, even if it slightly slower). Is it possible to change from export by ordinal to export by name without breaking older stuff? Dave