Date: Wed, 19 Jan 2005 00:04:21 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 506 ************************************************** Tuesday 18 January 2005 Number 506 ************************************************** Subjects for today 1 GCC 3.3.5 / LIBC 0.6 Beta 4 : Knut St. Osmundsen" 2 Re: wchar.h and InnoTek libc : Knut St. Osmundsen" 3 Re: bsdtar (was Zope) : Knut St. Osmundsen" 4 Re: Python v2.4 : John Poltorak 5 Re: GCC 3.3.5 / LIBC 0.6 Beta 4 : John Poltorak 6 New GCC and fork on K6 etc : lsunley at mb.sympatico.ca 7 Re: New GCC and fork on K6 etc : Dave Yeo" 8 Re: New GCC and fork on K6 etc : lsunley at mb.sympatico.ca 9 Re: Bridge software : Steven Levine" 10 Re: Program to demonstrate fork DLL load errors : John Poltorak 11 GNU Test : John Poltorak 12 Re: Python v2.4 : Andrew MacIntyre **= Email 1 ==========================** Date: Mon, 17 Jan 2005 13:54:58 +0100 From: "Knut St. Osmundsen" Subject: GCC 3.3.5 / LIBC 0.6 Beta 4 Hi, I've just put out a new build. It's 98% bugfixing. The 2% of new stuff is in the wchar.h category. The build isn't very well tested because I was very pressed on time, but unless I made some blunders in the early hours it should be working ok. Here it is: ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-beta4.zip Enjoy! Kind Regards, knut **= Email 2 ==========================** Date: Mon, 17 Jan 2005 14:00:12 +0100 From: "Knut St. Osmundsen" Subject: Re: wchar.h and InnoTek libc Dave Yeo wrote: > Hi has anyone got any of the functions in wchar.h to link? Twice in > the last 2 days I've had source (wget-cvs and bsdtar) fail in old emx > due to wchar.h. In both cases they compile under InnoTek libc but > fail to link. While some of the failures are due to not being > implemented yet (&todo) others such as wcscmp look like they are > implemented but aren't locatable in /usr/lib and produce undefined > symbol errors > Dave The beta2 was missing the strictly string related wide functions. I've added them for beta4. There still are missing wide functions in the stream category, these require some more work to port. I'm not promissing when these will be done. Kind Regards, knut **= Email 3 ==========================** Date: Mon, 17 Jan 2005 14:10:47 +0100 From: "Knut St. Osmundsen" Subject: Re: bsdtar (was Zope) Dave Yeo wrote: > On Sat, 15 Jan 2005 15:38:00 -0800, Dave Yeo wrote: > > >>>> Another TAR to consider is BSD TAR. >>> >>> Do you have a URL for that? >> >> Not really. Might want to check this one out >> http://people.freebsd.org/~kientzle/libarchive/ Still going to have >> drive letter problems though. > > > I got most of libarchive and bsdtar to compile but they fail linking > due to unfinished parts of Innotek_libc. They will not compile on EMX > due to dependence on wchar.h and possibly others. Missing symbols > include _fchdir _mkfifo Which are labeled TODO in libc includes and a > bunch from wchar.h There most likely are older versions that don't > depend on wchar.h (wchar.h seems to be for unicode, wide chars) > Dave mkfifo() ~= named pipes. for tar you can probably just stub it at present since neither emx nor libc presently implemnts unix fifos. It's on my list of things I wanna figure out how works, so it might turn up before long (perhaps together with local sockets). fchdir() is not possible even to emulate properly with the current open() and opendir() implementation. You'll have to patch the code where it's used. This will probably turn up sooner than mkfifo since it's more useful. Kind Regards, knut **= Email 4 ==========================** Date: Mon, 17 Jan 2005 19:07:52 +0000 From: John Poltorak Subject: Re: Python v2.4 On Mon, Jan 17, 2005 at 08:16:27AM +1000, Andrew MacIntyre wrote: > John Poltorak wrote: > > Now that Python v2.4 has been released should I be able to build it myself > > on OS/2? > > > > ISTR that the OS/2 patches for v2.3.4 only consisted of a number of > > Makefiles and the only source change was the addition of emx_link. > > > > Wouldn't same patches also work with v2.4? > > emx_link is included in the 2.4 source tarball, I noticed that and am a bit confused... I'm actually trying to get to grips with Mailman (again) and my notes don't make any sense. I take it that you are referring to _emx_link.py and this is the new name for what was previously known to as emx_emul.py ... Is this how I should code the patch for Lockfile.py now:- ? --- mailman-2.1.5/Mailman/LockFile.py~ Tue Apr 1 04:28:16 2003 +++ mailman-2.1.5/Mailman/LockFile.py Sun Jan 16 22:11:56 2005 at at -65,6 +65,11 at at import random import traceback from stat import ST_NLINK, ST_MTIME + +if os.name == 'os2': + from _emx_link import link as os2_link + os.link = os2_link + del os2_link # Units are floating-point seconds. DEFAULT_LOCK_LIFETIME = 15 > so you just need to tweak > the Makefile, and if running Zope/Plone change the thread stack size as > previously discussed (this will be made into a Makefile knob for the next > release). So, as far as your current distribution of Python stands, does it need to rebuilt with a different thread stack size to be suitable for running Zope with Plone? > > -- > ------------------------------------------------------------------------- > 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 **= Email 5 ==========================** Date: Mon, 17 Jan 2005 21:42:58 +0000 From: John Poltorak Subject: Re: GCC 3.3.5 / LIBC 0.6 Beta 4 On Mon, Jan 17, 2005 at 01:54:58PM +0100, Knut St. Osmundsen wrote: > Hi, > > I've just put out a new build. It's 98% bugfixing. The 2% of new stuff > is in the wchar.h category. The build isn't very well tested because I > was very pressed on time, but unless I made some blunders in the early > hours it should be working ok. > > Here it is: > ftp://ftp.netlabs.org/pub/gcc/GCC-3.3.5-beta4.zip Just thought I'd add this:- The ReleaseNote.os2 for this release states: "GCC v3.3.5 / LIBC v0.6 - Beta 4: -------------------------------- Thanks to Lorne, Froloff and nickk for sending me patches, debugging problems and testing fixes. New features: o Added st_dev and st_ino calculation for fstat and stat. o Added most of the wide string functions. N.B. the stream functions are still missing. o New functions: SafeDosStartSession(), wcscat(), wcschr(), wcscmp(), wcscoll(), wcscpy(), wcscspn(), wcslcat(), wcslcpy(), wcslen(), wcsncat(), wcsncmp(), wcsncpy(), wcspbrk(), wcsrchr(), wcsspn(), wcsstr(), wcstok() and wcswidth() Bug fixes: o settimeofday() year problem. o Some underflow/overflow problems tested for by many Configure scripts was fixed by using a 64-bit time type internally. o fxsave/fxrstore problem in fork(). (This isn't tested because lack of (reliable) obsolete hardware.) o Fixed fork() and DosLoadModule problem in child. o nl_langinfo(CODESET) now returns something useful, adding a few ascii codeset aliases at the same time. o Bug in socket inheritance over exec/spawn. o Missing semphore and signal blocking when processing external signals. o Two rmdir errno problems, and made it fail on symlink. o Fixed incorrect monetary locale for the "C" locale after setlocale call. o Fixed signal queue node leak. o Fixed missing release of signal semaphore and signal unblocking in a failure code path. o Fixed a few filehandle conversion bugs in os2_select. o Fixed libsocket to set errno to ENOSOCK when given a filehandle instead of a socket. Previous was ENOSYS. o Corrected NP_NBLK define in os2emx.h. o Export __mcount stub. LIBCxx.prf export non-stub. o Added missing libdl stub libraries (dlfcn is in libc as of last release). o Fixed missing WNOHANG handling in the wait functions. o Adjusted the ECHILD and EINVAL errnos usage in the wait functions to match the waitpid() spec. o ??? Todos before LIBC06.DLL: 0. Fix all bugs. :-) 1. Reimplement opendir in BSD style (+fchdir). 2. Shared IPC structures for XSI msq, sem and shm. 3. Missing job pgid functions. 4. Port GLIBC intl/*. gettext is a pita! because it's passing FILE pointers around between different LIBCs. objdump is constantly broken between LIBC versions. 5. Figure out the EA exclusive read access trouble. 6. Calc ino_t on file creation and store it in EAs. 7. Some sysctl() required for coreutils + a bit of tcpip additions. 8. adjtime() implementation." > Enjoy! You're a star Knut! > Kind Regards, > knut -- John **= Email 6 ==========================** Date: Mon, 17 Jan 2005 20:30:43 -0500 From: lsunley at mb.sympatico.ca Subject: New GCC and fork on K6 etc Has anyone tried building and running that fork() test program I sent out a while ago. I'd like to know if Knut's update for LIBC has a working fork on K6-2's and/or pentium pros Lorne -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 7 ==========================** Date: Mon, 17 Jan 2005 20:31:01 -0800 From: "Dave Yeo" Subject: Re: New GCC and fork on K6 etc On Mon, 17 Jan 2005 20:30:43 -0500, lsunley at mb.sympatico.ca wrote: >Has anyone tried building and running that fork() test program I sent out >a while ago. > >I'd like to know if Knut's update for LIBC has a working fork on K6-2's >and/or pentium pros Have now [R:\tmp]testfork Starting program pid=3876 Fork started pid=3877 main line in pid=3876 Fork 2 started pid=3878 Fork 2 main line in pid=3878 Fork 2 main line in pid=3877 Dave **= Email 8 ==========================** Date: Mon, 17 Jan 2005 22:54:01 -0500 From: lsunley at mb.sympatico.ca Subject: Re: New GCC and fork on K6 etc In <20050118043049.6419BD496B at generation.lgisp.net>, on 01/17/05 at 08:31 PM, "Dave Yeo" said: >On Mon, 17 Jan 2005 20:30:43 -0500, lsunley at mb.sympatico.ca wrote: >>Has anyone tried building and running that fork() test program I sent out >>a while ago. >> >>I'd like to know if Knut's update for LIBC has a working fork on K6-2's >>and/or pentium pros >Have now >[R:\tmp]testfork >Starting program pid=3876 >Fork started pid=3877 >main line in pid=3876 >Fork 2 started pid=3878 >Fork 2 main line in pid=3878 >Fork 2 main line in pid=3877 >Dave WONDERFUL!!! At least now I can take the warning messages out the the GA release Due out tomorrow night... I have to re-test everything and pull out some workarounds I had put in for the older LIBC. -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 9 ==========================** Date: Mon, 17 Jan 2005 22:40:46 -0800 From: "Steven Levine" Subject: Re: Bridge software In , on 01/13/05 at 07:27 PM, Steve Wendt said: >I don't see how that has anything to do with what I said. Can you point >me to a binary Linux module I can download that will work with any Linux >2.2.x, 2.4.x, and/or 2.6.x kernel? Oh I finally understand your point. I was a bit slow on the uptake. This is true, but I see it as an interim problem. There's not much that can be done about it while the kernels are undergoing rapid development. Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 10 ==========================** Date: Tue, 18 Jan 2005 10:11:38 +0000 From: John Poltorak Subject: Re: Program to demonstrate fork DLL load errors On Mon, Jan 03, 2005 at 11:59:34PM -0500, lsunley at mb.sympatico.ca wrote: > This zip file has two simple test cases that demonstrate problems with > loading DLL's in a fork()ed program > > buildit.cmd - build commands > testfork.c - makes testfork.exe > testit.c testit.def - makes testit.dll > testfork2.c - makes testfork2.exe > testit2.c testit2.def - makes testit2.dll > > testfork dlopen's and dlsym's a DLL and then attempts a fork. The DLL > loads correctly and the routine address resolves but the fork fails... > > testfork2 forks and then attempts to dlopen and dlsym a DLL. The fork > works but the dlopen returns a 295 error and (needless to say) dlsym > fails. > > Executables included - you need libc06b2.dll to run the tests. If this was originally attached, it looks as though it has been stripped off by the mailing list software. Is there any where to download it? Now that gcc has been updated, it may worth be checking especially as I have a system with an AMD K6. > Lorne Sunley > > -- > ----------------------------------------------------------- > lsunley at mb.sympatico.ca > ----------------------------------------------------------- > -- John **= Email 11 ==========================** Date: Tue, 18 Jan 2005 10:31:06 +0000 From: John Poltorak Subject: GNU Test GNU Test (part of the shell utilities) has numerous options, but I don't see one which tests to see if a file is accessible. ie I want to check to see if a file is locked. Do any of the options for test look suitable? And if not how else could I tell if I can access a file before trying to read it? -- John **= Email 12 ==========================** Date: Tue, 18 Jan 2005 20:58:24 +1000 From: Andrew MacIntyre Subject: Re: Python v2.4 John Poltorak wrote: >>emx_link is included in the 2.4 source tarball, > > > I noticed that and am a bit confused... I'm actually trying to get to > grips with Mailman (again) and my notes don't make any sense. > > I take it that you are referring to _emx_link.py and this is the new name > for what was previously known to as emx_emul.py ... > > Is this how I should code the patch for Lockfile.py now:- ? > > > --- mailman-2.1.5/Mailman/LockFile.py~ Tue Apr 1 04:28:16 2003 > +++ mailman-2.1.5/Mailman/LockFile.py Sun Jan 16 22:11:56 2005 > at at -65,6 +65,11 at at > import random > import traceback > from stat import ST_NLINK, ST_MTIME > + > +if os.name == 'os2': > + from _emx_link import link as os2_link > + os.link = os2_link > + del os2_link > > # Units are floating-point seconds. > DEFAULT_LOCK_LIFETIME = 15 This patch should not be needed with the 2.4 distribution (source or binary). It wasn't supposed to be needed with my binary 2.3.4 distribution either, but I've just noticed that I forgot the change to Lib/os.py that is in 2.4 which meant the above patch is still required... :-( I'll try and make sure that this is done properly in the 2.3.5 binary distribution (2.3.5 is a bug-fix wrap-up release of the 2.3 branch, expected to appear next week). >>so you just need to tweak >>the Makefile, and if running Zope/Plone change the thread stack size as >>previously discussed (this will be made into a Makefile knob for the next >>release). > > > So, as far as your current distribution of Python stands, does it need to > rebuilt with a different thread stack size to be suitable for running > Zope with Plone? I built the 2.4 binary distribution with a thread stack size of 128k, rather than the default of 64k. I see that I didn't note that in the release notes or include a patch :-( Sorry about that! Whether 128k is sufficient I don't know. I expect that you will let me know in short order ;-) I've applied a patch in Python CVS (to the 2.3, 2.4 and head branches) which makes this tunable from the Makefile - the 2.3.5/2.4.1 source tarballs (when released) will have this. I have a longer term plan for making this a runtime tunable (on OS/2 and Pthreads platforms at least), but I'm not sure whether this will get a guernsey from the Pythonistas who matter. -- ------------------------------------------------------------------------- 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