From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 19 Sep 2003 14:11:43 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 198 ************************************************** Thursday 18 September 2003 Number 198 ************************************************** Subjects for today 1 Re: waitpid : why does this not work? : Andreas Buening 2 Re: [Ux2bs] Innotek LIBC : Andreas Buening 3 Re: [Ux2bs] Innotek LIBC : Andreas Buening 4 Re: Re: [Ux2bs] Innotek LIBC : Andreas Buening 5 Re: [Ux2bs] Innotek LIBC : Adrian Gschwend" 6 Re: [Ux2bs] Innotek LIBC : Adrian Gschwend" 7 Re: Re: [Ux2bs] Innotek LIBC : Adrian Gschwend" 8 Re: Re: [Ux2bs] Innotek LIBC : Alexander Newman 9 Re: [Ux2bs] Innotek LIBC : Stefan.Neis at t-online.de 10 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" 11 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" 12 Re: Re: [Ux2bs] Innotek LIBC : Stefan Neis 13 Re: autoconf question, was Re: [Ux2bs] Innotek LIBC : Stefan Neis 14 Re: Re: Re: [Ux2bs] Innotek LIBC : Dave and Natalie" **= Email 1 ==========================** Date: Fri, 19 Sep 2003 01:36:56 +0200 From: Andreas Buening Subject: Re: waitpid : why does this not work? Thomas Hoffmann wrote: I'm not an expert in signals but, since you've got that many responses, I'll try to answer your questions. ;-) > I did not find too many discussion about waitpid() on older OS/2+emx > archives, so I will ask this here: > > According to some sample code e.g. in the glibc documentation something > like this should collect all the children of a process in a signal > handler for SIGCLD/SIGCHLD: [code] > But it does not work at all for me: an infinite loop starts as soon as > this handler is entered. [snip] SIGCHLD is different on OS/2. This means you'd better forget about what you've read in any Unix docs. If you use -Zsys, you don't have SIGCHLD. If you uncritically compile Unix programs that use a SIGCHLD handler, there is a good chance that your program will produce a deadlock. However, I don't know why your code doesn't work. Bye, Andreas **= Email 2 ==========================** Date: Fri, 19 Sep 2003 01:37:08 +0200 From: Andreas Buening Subject: Re: [Ux2bs] Innotek LIBC Adrian Gschwend wrote: > > Again a forward, I took away the header and killed some Fwd's in the > subject to make it more readable :) Where is this discussion being hold? > > Adrian Gschwend schrieb: > > > > > >> Just to keep their expectations realistic. There is _currently_ > >> fork() implementation, > > > > > > I guess from context, there's a "no" missing? > Ah, sorry. fork() isn't implemented, it's just a stub which complains > and returns -1. > (The reason is simple, EM code is GPL thus not suitable in a library.) Ehm, what? Sorry, am I the only one who doesn't understand this statement? > >> neither does select() work on files - file handles and socket > >> handles are not _yet_ shared. Does this mean Innotek has removed the existing fork() and select() implementation? Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Fri, 19 Sep 2003 01:37:08 +0200 From: Andreas Buening Subject: Re: [Ux2bs] Innotek LIBC Adrian Gschwend wrote: > > Again a forward, I took away the header and killed some Fwd's in the > subject to make it more readable :) Where is this discussion being hold? > > Adrian Gschwend schrieb: > > > > > >> Just to keep their expectations realistic. There is _currently_ > >> fork() implementation, > > > > > > I guess from context, there's a "no" missing? > Ah, sorry. fork() isn't implemented, it's just a stub which complains > and returns -1. > (The reason is simple, EM code is GPL thus not suitable in a library.) Ehm, what? Sorry, am I the only one who doesn't understand this statement? > >> neither does select() work on files - file handles and socket > >> handles are not _yet_ shared. Does this mean Innotek has removed the existing fork() and select() implementation? Bye, Andreas **= Email 4 ==========================** Date: Fri, 19 Sep 2003 01:37:12 +0200 From: Andreas Buening Subject: Re: Re: [Ux2bs] Innotek LIBC Stefan Neis wrote: > Question for configure experts: Any idea how to have make configure fall > back to "gcc" for a C++ compiler if it can't find any of its standard c++ > compilers (c++, g++, CC, aCC, etc.)? I think the simplest way is to use CXX="gcc" LIBS="-lstdcpp" ./configure ... Bye, Andreas **= Email 5 ==========================** Date: Fri, 19 Sep 2003 09:46:08 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: [Ux2bs] Innotek LIBC On Fri, 19 Sep 2003 01:37:08 +0200, Andreas Buening wrote: >Where is this discussion being hold? Well it started on Ux2BS, but Knut is not on this list so I forwarded it to him. It would help if this discussion is just hold on UnixOS2, AFAIK Knut reads that one. >Ehm, what? Sorry, am I the only one who doesn't understand this >statement? Innotek cannot use GPL code for this library. We do not have to discuss reasons here, it's just like this. And EMX is GPL so its code cannot be used. >Does this mean Innotek has removed the existing fork() and >select() implementation? AFAIK yes, EM did not agree to change the license so far. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 6 ==========================** Date: Fri, 19 Sep 2003 09:46:08 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: [Ux2bs] Innotek LIBC On Fri, 19 Sep 2003 01:37:08 +0200, Andreas Buening wrote: >Where is this discussion being hold? Well it started on Ux2BS, but Knut is not on this list so I forwarded it to him. It would help if this discussion is just hold on UnixOS2, AFAIK Knut reads that one. >Ehm, what? Sorry, am I the only one who doesn't understand this >statement? Innotek cannot use GPL code for this library. We do not have to discuss reasons here, it's just like this. And EMX is GPL so its code cannot be used. >Does this mean Innotek has removed the existing fork() and >select() implementation? AFAIK yes, EM did not agree to change the license so far. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 7 ==========================** Date: Fri, 19 Sep 2003 10:33:39 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: Re: [Ux2bs] Innotek LIBC On Thu, 18 Sep 2003 21:20:40 -0700 (PDT), Steve Wendt wrote: >libc has to be distributed with applications, e.g. Mozilla, while gcc does not. It's >easier to make the IBM lawyers happy when you give them a BSD-licensed >library to distribute than a GPL-licensed one. That's exactly the problem. It's not really an Innotek issue but an IBM issue. And Innotek has to satisfy IBM with this library at first so GPL is a problem for the library. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 8 ==========================** Date: Fri, 19 Sep 2003 11:32:54 +1000 From: Alexander Newman Subject: Re: Re: [Ux2bs] Innotek LIBC > Andreas Buening wrote: > > Adrian Gschwend wrote: > > > > Again a forward, I took away the header and killed some Fwd's in > the > > subject to make it more readable :) > > Where is this discussion being hold? > > > > > Adrian Gschwend schrieb: > > > > > > > > >> Just to keep their expectations realistic. There is _currently_ > > >> fork() implementation, > > > > > > > > > I guess from context, there's a "no" missing? > > Ah, sorry. fork() isn't implemented, it's just a stub which > complains > > and returns -1. > > (The reason is simple, EM code is GPL thus not suitable in a > library.) > > Ehm, what? Sorry, am I the only one who doesn't understand this > statement? I don't either, not that means much ;). Did he leave something out, e.g., 'in an *Innotek* library? Given that (most of?) the gcc suite is under GPL, on the face of it this statment is weird. Unless Innotek are going to reverse engineer the entire suite, which would seem a little bit like reinventing the wheel (and a total waste of time). Straange. Alex. **= Email 9 ==========================** Date: Fri, 19 Sep 2003 12:15:21 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: [Ux2bs] Innotek LIBC Andreas Buening schrieb: > Does this mean Innotek has removed the > existing fork() and > select() implementation? IIRC, somebody said they took the sys-library (i.e. what's used by -Zsys) as the base of their libc, so there was no fork/select anyway. :-( No need to actively remove something. ;-) Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 10 ==========================** Date: Fri, 19 Sep 2003 15:59:51 +0100 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC Andreas Buening wrote: > Adrian Gschwend wrote: > >>> Adrian Gschwend schrieb: >>> >>>> Just to keep their expectations realistic. There is _currently_ >>>> fork() implementation, >>> >>> >>> >>> I guess from context, there's a "no" missing? >> >> >> Ah, sorry. fork() isn't implemented, it's just a stub which >> complains and returns -1. (The reason is simple, EM code is GPL >> thus not suitable in a library.) > > > > Ehm, what? Sorry, am I the only one who doesn't understand this > statement? Assert context LIBC. Steve Wendt got this right. (thanks) (Linking GPL library code with applications or libraries which are not GPL compatible doesn't work. Even if the GPL code is in a DLL there are potential problems, depending on how the judge will read the GPL.) If you care for discussing GPL and such matters any further, you should call your favorite copyright and license lawyer. >>>> neither does select() work on files - file handles and socket >>>> handles are not _yet_ shared. > > > > Does this mean Innotek has removed the existing fork() and select() > implementation? No, we didn't remove anything as LIBC is not built on the GPLed EMX.DLL sources, but the -Zsys lib sources. We've been adding to them, and intend to continue to do so perhaps with some help from you guys. Kind Regards, knut **= Email 11 ==========================** Date: Fri, 19 Sep 2003 16:05:23 +0100 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC Adrian Gschwend wrote: > On Thu, 18 Sep 2003 21:20:40 -0700 (PDT), Steve Wendt wrote: > > >> libc has to be distributed with applications, e.g. Mozilla, while >> gcc does not. It's easier to make the IBM lawyers happy when you >> give them a BSD-licensed library to distribute than a GPL-licensed >> one. > > > > That's exactly the problem. It's not really an Innotek issue but an > IBM issue. And Innotek has to satisfy IBM with this library at first > so GPL is a problem for the library. Actually the problem have just as much to do with any any user which wanna make non GPL compatible applications. For instance, the favorite movie player and subject for license fighting in the OS/2 community, warpvision (GUI), couldn't be linked (statically at least) with a LIBC which was GPL based. Nor could you distribute your (statically linked at least) hello world binary in a non GPL fashion. The dissent around whether or not you can link with a dynamic load library, is something the judge would have to decide on. Hence one would not put any customer (paying or non) in a such a situation. Ok. Keen on more GPL discussions? Go see you lawyer friends. Now, have anyone actually tried GCC/LIBC beta2 by now? Any suggestions, problems, ideas, contributions? Kind Regards, knut **= Email 12 ==========================** Date: Fri, 19 Sep 2003 16:51:19 +0200 (CEST) From: Stefan Neis Subject: Re: Re: [Ux2bs] Innotek LIBC On Fri, 19 Sep 2003, Alexander Newman wrote: > > Given that (most of?) the gcc suite is under GPL, on the face of it this > statment is weird. You're missing the point: For the licences of _your_ program/code, the GPL in any _program_ you're using to compile it is totally irrelevant (as it even explicitly state). However, if you link _any_ GPL'd library, that forces you to put all _your_ code under GPL as well. (No, how that affects libraries in form of DLLs is a bit unclear to me, but apparently some people do see problems ...). EMX is confusing the issue a bit as it "integrates" compiler _and_ libc in one distribution while those are separated on all other platforms. However, note that while gcc is under GPL, libc normally is not (even GNU libc has a different licence, and native libc's (like on Solaris, HP/UX, AIX, *BSD) all have much more permissive licences). What is confusing _me_ completely is the claim that EMX libraries are under GPL. At the very least I seem to remember some exception clause which seems essentially equivalent to _L_GPL. :-o Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 13 ==========================** Date: Fri, 19 Sep 2003 17:02:50 +0200 (CEST) From: Stefan Neis Subject: Re: autoconf question, was Re: [Ux2bs] Innotek LIBC On Fri, 19 Sep 2003, Andreas Buening wrote: > > Question for configure experts: Any idea how to have make configure fall > > back to "gcc" for a C++ compiler if it can't find any of its standard c++ > > compilers (c++, g++, CC, aCC, etc.)? > > I think the simplest way is to use > CXX="gcc" LIBS="-lstdcpp" ./configure ... While that's fine for myself, it's not exactly what I want to tell people trying to compile wxWindows ... Although "Assuming gcc-3.2.1, simply call ./configure, if you have an older version try something like 'CXX="gcc" LIBS="-lstdcpp" ./configure'" doesn't sound too bad, either... Regards, Stefan **= Email 14 ==========================** Date: Fri, 19 Sep 2003 20:33:45 -0800 From: "Dave and Natalie" Subject: Re: Re: Re: [Ux2bs] Innotek LIBC 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