From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 21 Sep 2003 14:11:47 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 200 ************************************************** Saturday 20 September 2003 Number 200 ************************************************** Subjects for today 1 Re: Re: [Ux2bs] Innotek LIBC : Alex Newman" 2 Re: Re: [Ux2bs] Innotek LIBC : Alex Newman" 3 Re: [EMX] Re: waitpid : why does this not work? : Andreas Buening 4 Re: Re: [Ux2bs] Innotek LIBC : Andreas Buening **= Email 1 ==========================** Date: Sun, 21 Sep 2003 09:20:32 +1000 (EST) From: "Alex Newman" Subject: Re: Re: [Ux2bs] Innotek LIBC On Sat, 20 Sep 2003 11:38:29 -0400, T.Sikora wrote: > Dave and Natalie wrote: > > On Sat, 20 Sep 2003 10:00:42 +1000, Alexander Newman wrote: > > > > > > > >>I'm getting configure choking at the test c compile step (early on after > >>sniffing for make), it complains that it can't find "ilink.exe." Neither can I. > >>LD is set to emxomfld.exe at shell (ksh) level. > > > > > > Try not using -Zomf to build an a.out binary Seems we need ilink.exe for building OMF binaries/objects > > though seems there is a setting that allows link386 though with no debugging. Perhaps look in your > > config.log to see what the error actually was. Unluckily it seems that gcc3.22 is mostly aimed at people > > (Mozilla developers) who already have VACPP. > > Dave > > > Does this fix it? > > SET EMXOMFLD_TYPE=link386 I'm about to find out :). After reading Knut's comprehenxive reply, I think I will try unsetting LD= as well. > Running MakeOmfLibs produces a whole lot of messages and warnings. > Should I just ignore these? In the os2tools.zip, ilinkwrap.exe what does > that do? Is it required for gcc of vaccp? I get a screed of error msgs too...but can't answer the question... Cheers, Alex. **= Email 2 ==========================** Date: Sun, 21 Sep 2003 09:22:54 +1000 (EST) From: "Alex Newman" Subject: Re: Re: [Ux2bs] Innotek LIBC Mikus Grinbergs also supplied some very useful help. Thanks to all, sorry about the bandwidth consumption. Cheers, Alex. **= Email 3 ==========================** Date: Sun, 21 Sep 2003 23:36:33 +0200 From: Andreas Buening Subject: Re: [EMX] Re: waitpid : why does this not work? Ilya Zakharevich wrote: > > On Sat, Sep 20, 2003 at 05:23:01PM +0200, Andreas Buening wrote: > > There is one big difference between Unix and OS/2 systems: SIGCHLD > > never dies. On OS/2 you MUST get the ID of the child process by > > wait() or waitpid(), otherwise the signal is pending. This means, > > Let me repeat: there is no such thing as "Unix". IIRC, EM did not > invent this flavor of signal handling himselves; it exists on some > flavors of Unix as well. You mean there is a Unix system where SIGCHLD is pending until anybody calls wait() or waitpid()? > > if you install a SIGCHLD handler which does NOT call waitpid(), > > the signal handler is called in an infinite loop and the process > > hangs. I don't know whether it's an OS/2 or just an EMX feature > > but it's real. > > It is real, but (IMO) it does not support your point. Portable > programs already call wait() inside the handler. At least GNU make installs a child handler that does NOT call wait(). (That's the reason why older make ports for OS/2 have to be compiled with -Zsys, otherwise the child handler locks up the process.) From this fact I've concluded that there is no Unix system which has a pending SIGCHLD, otherwise make would lock up also on those systems. > > Btw., please do not send a copy to the UnixOS/2 list as 'CC' but > > as 'TO' because your posting is ignored otherwise (don't know why). > > I will this time, but no promises to remember this tomorrow. ;-) :-( You did it again. ;-) Please do NOT CC to the Mailing list. Bye, Andreas **= Email 4 ==========================** Date: Sun, 21 Sep 2003 23:36:49 +0200 From: Andreas Buening Subject: Re: Re: [Ux2bs] Innotek LIBC Knut St. Osmundsen wrote: > > Andreas Buening wrote: > > Is there any list of functions that have been removed compared to > > "standard emx", have been added, are beeing rewritten? > No, that's too much work. > Our focus is to get something which is useful, not a large documentation > for something which is less useful. We've neither unlimited time or > amout of money. That's a pity. Don't you think you'll need anything like this on the long term? Writing an autoconf test just to find out whether a function is declared in a header / has an entry point in the libraries / works would be a little overkill, wouldn't it? ;-) Bye, Andreas