From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 11 Oct 2003 14:13:48 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 211 ************************************************** Friday 10 October 2003 Number 211 ************************************************** Subjects for today 1 Re: Innotek LIBC and glinks : Knut St. Osmundsen" 2 Re: Innotek LIBC and glinks : Knut St. Osmundsen" **= Email 1 ==========================** Date: Sat, 11 Oct 2003 20:14:07 +0200 From: "Knut St. Osmundsen" Subject: Re: Innotek LIBC and glinks Dave and Natalie wrote: > On Thu, 09 Oct 2003 07:42:31 +1000 (EST), Alex Newman wrote: > > >> I am still having a bad time with _sigsetjmp and _siglongjmp >> (undef-ed symbols) using 322b2 attempting to build gdk-pixbuf >> 0.22.0. Anyone else having this problem? > > > The problem is that 322b2 libc has __sigsetjmp and __siglongjmp. All > I can think of offhand is redefining sigsetjmp as _sigsetjmp etc. Not > sure if will work. We're missing an alias here. Thanks for spotting it. It'll be fixed in Beta4. Kind Regards, knut PS. I've quietly put out Beta 3: ftp://ftp.innotek.de/pub/gccos2/3.2.2-beta3/ **= Email 2 ==========================** Date: Sat, 11 Oct 2003 20:24:22 +0200 From: "Knut St. Osmundsen" Subject: Re: Innotek LIBC and glinks Dave and Natalie wrote: > Sorry for taking so long to reply but I've been working a lot and had > a shortage of time for playing with this. I know that problem :) > On Wed, 24 Sep 2003 02:38:39 +0200, Knut St. Osmundsen wrote: >> Dave and Natalie wrote: >>> On Fri, 19 Sep 2003 16:05:23 +0100, Knut St. Osmundsen wrote: >>> >>>> Now, have anyone actually tried GCC/LIBC beta2 by now? Any >>>> suggestions, problems, ideas, contributions? >>> >>> >>> Running configure on glinks (Text and graphic web browser >>> includes support for pmshell) >>> (http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/links/) I get >>> these errors etc. Finds EMX, don't know if this is good or bad >>> Get this error In file included from configure:4236: >>> g:/usr/include/netinet/ip.h:79: field `ip_src' has incomplete >>> type g:/usr/include/netinet/ip.h:79: field `ip_dst' has >>> incomplete type g:/usr/include/netinet/ip.h:165: parse error >>> before "n_long" g:/usr/include/netinet/ip.h:167: field `ipt_addr' >>> has incomplete type g:/usr/include/netinet/ip.h:168: parse error >>> before "n_long" g:/usr/include/netinet/ip.h:170: parse error >>> before '}' token g:/usr/include/netinet/ip.h:171: parse error >>> before '}' token > > Using autoconf 2.13 this error disappears. I guess configure was > right when it said to report to the maintainers as a bug. I just > figured since GCC is a beta.... Hmm. I should try it with a later autoconf perhaps and see why the headers doesn't work then... >>> Building works OK until the final linking when I get this >>> 09-20-2003 07:45:31 SYS3171 PID 4b5e TID 0001 Slot 00b3 >>> G:\USR\BIN\LD.EXE c0000005 000156cf P1=00000002 P2=fffc09bc >>> P3=XXXXXXXX P4=XXXXXXXX EAX=0021aa40 EBX=00182c90 ECX=00000002 >>> EDX=0012fa18 ESI=00000005 EDI=0021aa40 DS=0053 DSACC=f0f3 >>> DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b >>> FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** >>> CS:EIP=005b:000156cf CSACC=f0df CSLIM=ffffffff >>> SS:ESP=0053:fffc09c0 SSACC=f0f3 SSLIM=ffffffff EBP=0012f718 >>> FLG=00012202 >>> >>> LD.EXE 0001:000056cf >> >> Wow! That stack address doesn't look too good.... Now the phun >> stuff here is that I just downloaded and built the latest stable >> links without any _build_ trouble. I cannot see the ip.h problem in >> the log either. Which version did you try build? However, it >> strikes me that MouOpen isn't detected. I'll look at that. I figured why MouOpen wasn't detected, the test is wrong (at least for gcc322). > Links-2.1pre11 with the included configure using this command > F:\usr\src\links-2.1pre11 > sh configure --prefix=/usr > --enable-javascript --enable-graphics --with-x --with-pmshell XFree86 > also wasn't detected but I think that maybe a configuration problem > here. > > links-.2.1pre11 builds and runs fine with gcc3.21 just needing > #define PATH_MAX MAXPATHLEN in https.c (which was in previous > tarballs) > > Rebuilding libpng ( with gcc 2.81) gets rid of the SYS3171 in LD.EXE > so something was weird in my png.a. ok. >> >>> Disabling the pmshell graphic driver allows the build to finish >>> but links dies with this error >>> X:\usr\src\links-2.1pre11>links.exe INTERNAL ERROR at >>> select.c:208: set_handlers: handle 4306 >= FD_SETSIZE 2048 >>> >>> Forcing core dump >>> >>> Process terminated by SIGSEGV >> >> This shouldn't be surprising to anyone which read the release notes >> and have followed some of the mails here. LIBC is at the moment >> using OS/2 socket handles untranslated. So, since there is like 32k >> sockets in the BSD 4.4 based stack, you might get somewhat higher >> socket handles than what BSD select would normally work with. And >> even if you were lucky and got a few low socket numbers it still >> wouldn't work since select() is called. LIBC select is at the >> moment not doing much. bsdselect() and os2_select() might be tried >> instead. > > > What is the best way to call os2_select() instead of select. I tried > defining select as os2_select and got the same errors. os2_select is not normal BSD style select, it takes different input. I hope someone else or I will find time soon to contribute the required socket handle change. > >>> Setting up enviroment for -Zomf (link386) and running configure I >>> get lots of >>> >>> 09-20-2003 19:45:53 SYS3175 PID 7bb1 TID 0001 Slot 00d8 >>> E:\OS2\LINK386.EXE c0000005 107bb7d9 P1=00000001 P2=ffffae9a >>> P3=XXXXXXXX P4=XXXXXXXX EAX=0008ae8a EBX=00000000 ECX=00000005 >>> EDX=00000053 ESI=00000c00 EDI=00000a07 DS=0047 DSACC=00f3 >>> DSLIM=0000b0cf ES=006f ESACC=00f3 ESLIM=00005fff FS=150b >>> FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** >>> CS:EIP=005b:107bb7d9 CSACC=f0df CSLIM=ffffffff >>> SS:ESP=0053:0008ae8a SSACC=f0f3 SSLIM=ffffffff EBP=ffffae92 >>> FLG=00012216 >>> >>> INNIDM.DLL 0001:0000b7d9 >> >> You've got unresolved symbols and my demangler crashes when link386 >> asks it to demangle the symbol names. I didn't manage to test that >> code, link386 didn't want do demangle anything when I wrote it. So, >> I really hope I can reproduce this and fix it. > > > This happened when configure was testing for things that aren't here > so yes unresolved symbols. The crash is fixed in the Beta 3 I quitely put out earlier this week. (ftp://ftp.innotek.de/pub/gccos2/3.2.2-beta3/) [snip] > > What symbol will refer to the new libc? eg #ifdef __EMX__ for emx We haven't added any new symbol indicating LIBC as we haven't needed one our selves. > Dave > ps built a few other ports and haven't had any problems. At that > gcc 3.2.2 seems to generate many fewer warnings then gcc 3.2.1 Good, that's the payback of my header updates :-)