Date: Tue, 30 Nov 2004 00:04:21 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 462 ************************************************** Monday 29 November 2004 Number 462 ************************************************** Subjects for today 1 Re: Building Zope with GCC 3.3.5 : Stefan.Neis at t-online.de 2 GCC question : Stefan.Neis at t-online.de 3 Re: Source for PING : Andrew MacIntyre 4 Re: Source for PING : John Poltorak 5 No sys/sysctl.h in GCC 3.3.5 : John Poltorak 6 Re: Building Python 2.3.4 with Innotek GCC 3.3.5 beta 1 : Knut Stange Osmundsen 7 Re: No sys/sysctl.h in GCC 3.3.5 : Stefan.Neis at t-online.de 8 Programming Python on OS/2 : John Poltorak 9 Re: No sys/sysctl.h in GCC 3.3.5 : John Poltorak **= Email 1 ==========================** Date: Sun, 28 Nov 2004 14:22:11 +0100 From: Stefan.Neis at t-online.de Subject: Re: Building Zope with GCC 3.3.5 Hi, (snipp) > -L/usr/local/python/Config -lpython23 (snipp) Does this refer to a library build with EMX? Or did you have success building python itself in the meantime? > G:/ux2bs/workdir/Zope-2.7.3-0/build-base/python-2.3/build-lib/AccessControl/cAccessC.pyd > weakld: error: Unresolved symbol (UNDEF) '_PyErr_Occurred'. > weakld: info: The symbol is referenced by: > > G:\ux2bs\workdir\Zope-2.7.3-0\build-base\python-2.3\build-temp\accesscontrol\caccesscontrol.obj > weakld: error: Unresolved symbol (UNDEF) '_PyExc_AttributeError'. > weakld: info: The symbol is referenced by: > > G:\ux2bs\workdir\Zope-2.7.3-0\build-base\python-2.3\build-temp\accesscontrol\caccesscontrol.obj > > > A large number of similar errors occurred the build stpped with:- If that library at the beginning is still the EMX-compiled version, then those errors are not surprising as Innotek and EMX use different name mangling, in short: you _cannot_ mix them. Regards, Stefan **= Email 2 ==========================** Date: Sun, 28 Nov 2004 14:34:00 +0100 From: Stefan.Neis at t-online.de Subject: GCC question Hi, While trying to build wxWindows with Innotek's gcc-3.2.2 with and without STL, I noticed an odd problem with a couple of symbols. With STL support enabled, I get unresolved references to > nm core*colr*o | grep GLOBAL U __GLOBAL__D__ZN21wxGenericColourDialog14wxCreateObjectEv U __GLOBAL__I__ZN21wxGenericColourDialog14wxCreateObjectEv Strangely, the demangler (i.e. when using "nm -C" or piping this stuff through c++filt) doesn't know anything about those symbols. Any idea what those symbols are? In case it's helpful, __ZN21wxGenericColourDialog14wxCreateObjectEv is successfully demangled to wxGenericColourDialog::wxCreateObject(). Even more strangely, in non STL enabled builds, I get > nm core*colr*o | grep GLOBAL 000037c8 t __GLOBAL__D__ZN21wxGenericColourDialog14wxCreateObjectEv 000037b0 t __GLOBAL__I__ZN21wxGenericColourDialog14wxCreateObjectEv Thus, no problems when actually trying to link things together. Apparently, there are no similar problems on other platforms... :-o Does anybody have any idea, what those symbols actually are or why inclusion of a couple of STL headers apparently converts them from locally defined symbols to references to global symbols that never get defined anywhere? TIA, Stefan **= Email 3 ==========================** Date: Mon, 29 Nov 2004 00:07:36 +1100 (EST) From: Andrew MacIntyre Subject: Re: Source for PING On Sat, 27 Nov 2004, John Poltorak wrote: > > - each of the [Net|Free|Open] sourcebases could be > > expected to have something later than the above (which is probably from > > the BSD 4.4 Lite release from CSRG at UCB). > > I have real trouble finding my way around the *BSD sources. Any chance of > a URL for ping's source? You can access FreeBSD's CVS repo via a CVSWeb interface. FreeBSD (and I think the other BSDs) generally organise the userland sources based on the target directory of the file - ping lives in /sbin, so I would start looking in $CVSROOT/usr/src/sbin/ping or $CVSROOT/src/sbin/ping. ------------------------------------------------------------------------- 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 4 ==========================** Date: Sun, 28 Nov 2004 19:09:27 +0000 From: John Poltorak Subject: Re: Source for PING On Mon, Nov 29, 2004 at 12:07:36AM +1100, Andrew MacIntyre wrote: > On Sat, 27 Nov 2004, John Poltorak wrote: > > > > - each of the [Net|Free|Open] sourcebases could be > > > expected to have something later than the above (which is probably from > > > the BSD 4.4 Lite release from CSRG at UCB). > > > > I have real trouble finding my way around the *BSD sources. Any chance of > > a URL for ping's source? > > You can access FreeBSD's CVS repo via a CVSWeb interface. FreeBSD (and I > think the other BSDs) generally organise the userland sources based on the > target directory of the file - ping lives in /sbin, so I would start > looking in $CVSROOT/usr/src/sbin/ping or $CVSROOT/src/sbin/ping. Many thanks, found it now in:- http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ping/ping.c > ------------------------------------------------------------------------- > 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: Sun, 28 Nov 2004 19:18:25 +0000 From: John Poltorak Subject: No sys/sysctl.h in GCC 3.3.5 Any chance of including sys/sysctl.h in gcc 3.3.5? This is required by more recent versions of PING. -- John **= Email 6 ==========================** Date: Sun, 28 Nov 2004 21:11:46 +0100 From: Knut Stange Osmundsen Subject: Re: Building Python 2.3.4 with Innotek GCC 3.3.5 beta 1 Andrew MacIntyre wrote: > On Sat, 27 Nov 2004, Paul Smedley wrote: > > >>A few things required change: >>1) in pc/os2emx - pyconfig.h needs editing and the '#define intptr_t' >>removing as it's already defined in Innotek GCC > > > That can be dealt with fairly easily. > > >>2) in python - thread.c - I had to comment out: >> #ifdef _POSIX_THREADS >> /*#include "thread_pthread.h" innote */ >> #endif >> as it appears that Innotek GCC defines that is has _POSIX_THREADS and >>this code gets executed as well as the _OS2_THREADS when building thread.c > > > Interesting. I can probably deal with this without too much drama. That's because _POSIX_THREADS is -1, i.e. not supported. Thus the above test is wrong. It should be: #if _POSIX_THREAD >= 0 #include "thread_pthread.h" #endif > >>3) in pc/os2emx - I had to comment out >> $(EXEOPT) -aq $(PYTHON.EXE) -h$(NFILES) >>& $(EXEOPT) -aq $(PYTHONPM.EXE) -h$(NFILES) >>Innotek GCC's emxbind doesn't support -a - and with just -q I got an >>error 'emxbind: The input and output files have the same name' > > > Without knowing what the Innotek libc's default number of file handles is > its hard to assess the impact of this. At least one of the python > regression tests needs 100 file handles. The default limit is 10000. Of course it's not increased until one of the filehandle creation functions return an error indicating that the limit was reached. VAC does something similiar, but have no upper limit. I thought that 10000 was a reasonable limit and that if you wanted more you should set the limit yourself. :-) The LIBC emxbind doesn't support -aq. And -h is for setting heapsize, not for the number of handles as $(NFILES) sort of indicates. I'm not quite sure how the -h option actually works now, but since it's there I assume that it works (Andy did these changes IIRC). Kind Regards, knut **= Email 7 ==========================** Date: Sun, 28 Nov 2004 21:23:45 +0100 From: Stefan.Neis at t-online.de Subject: Re: No sys/sysctl.h in GCC 3.3.5 Hi, Sounds like might be trying to access the network adapter on a very low level for maximum efficiency. If that's true, you probably can just forget about porting that version, even if you use e.g. Posix/2 (which has a sys/sysctl.h but at most very limited support for the methods declared in there). On that level, OS/2 really is quite different from BSD ... Regards, Stefan **= Email 8 ==========================** Date: Sun, 28 Nov 2004 20:29:03 +0000 From: John Poltorak Subject: Programming Python on OS/2 I just came across this web page:- http://www.sschwarzer.net/python/warpstock_europe_2001.html#introduction which is only three years old :-)... But if anyone wants to look at using Python on OS/2, I guess it's a good place to start, apart from there having been several versions released since that page was published. -- John **= Email 9 ==========================** Date: Sun, 28 Nov 2004 21:05:57 +0000 From: John Poltorak Subject: Re: No sys/sysctl.h in GCC 3.3.5 On Sun, Nov 28, 2004 at 09:23:45PM +0100, Stefan.Neis at t-online.de wrote: > Hi, > > Sounds like might be trying to access the network adapter on a very low > level for maximum efficiency. If that's true, you probably can just forget > about porting that version, even if you use e.g. Posix/2 (which has a > sys/sysctl.h but at most very limited support for the methods declared in > there). On that level, OS/2 really is quite different from BSD ... The addition of that header was quite recent - it only happened last year. v1.77 did not have it. When compiling that version, I get :- [S:\]gcc ping.c -lsocket ping.c: In function `main': ping.c:625: error: `NOKERNINFO' undeclared (first use in this function) ping.c:625: error: (Each undeclared identifier is reported only once ping.c:625: error: for each function it appears in.) ping.c: In function `finish': ping.c:1166: error: `NOKERNINFO' undeclared (first use in this function) ping.c: In function `pr_icmph': ping.c:1227: error: `ICMP_UNREACH_FILTER_PROHIB' undeclared (first use in this f unction) These errors are from this release:- http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sbin/ping/ping.c?rev=1.77&content-type=text/plain > Regards, > Stefan > > -- John