From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 20 Sep 2003 14:11:46 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 199 ************************************************** Friday 19 September 2003 Number 199 ************************************************** Subjects for today 1 Re: Re: [Ux2bs] Innotek LIBC : Henry Sobotka 2 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" 3 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" 4 Re: Re: Re: [Ux2bs] Innotek LIBC : Alexander Newman 5 Re: Re: [Ux2bs] Innotek LIBC : T.Sikora" 6 Re: Re: autoconf question, was Re: [Ux2bs] Innotek LIBC : Andreas Buening 7 Re: [EMX] Re: waitpid : why does this not work? : Andreas Buening 8 Re: Re: [Ux2bs] Innotek LIBC : Andreas Buening 9 Re: Re: [Ux2bs] Innotek LIBC : Dave and Natalie" 10 Re: Re: [Ux2bs] Innotek LIBC : Dave and Natalie" 11 Re: Re: [Ux2bs] Innotek LIBC : Alex Newman" 12 Re: Re: [Ux2bs] Innotek LIBC : Stefan Neis 13 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" 14 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" 15 Re: Re: [Ux2bs] Innotek LIBC : Knut St. Osmundsen" **= Email 1 ==========================** Date: Sat, 20 Sep 2003 00:49:22 -0400 From: Henry Sobotka Subject: Re: Re: [Ux2bs] Innotek LIBC Knut, for those of us on the outside, it would be useful to see a to-do list, preferably prioritized. Ditto for CVS read access, which would also give you a broader test base for changes as they're checked in. Also, has any thought been given to using some of the code written for POSIX/2, which is BSD-based? h~ **= Email 2 ==========================** Date: Sat, 20 Sep 2003 01:30:27 +0200 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC Stefan Neis wrote: > On Fri, 19 Sep 2003, Alexander Newman wrote: > > 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 Where what? EMX.DLL is GPL with an redistribution exception (at least some sources say so). However, once you start changing EMX.DLL that exception doesn't hold any longer and it's plain GPL (at least the way I read it). (see \emx\src\os2\tcpip.c for an example.) Kind Regards, knut **= Email 3 ==========================** Date: Sat, 20 Sep 2003 05:48:54 +0200 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC Alexander Newman wrote: > Moving on... Excellent! > > >> Now, have anyone actually tried GCC/LIBC beta2 by now? Any >> suggestions, problems, ideas, contributions? > > 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 start emxomfld without any parameters like the installation and release notes points out. (Hint, you need to set EMXOMFLD_LINKER and EMXOMFLD_TYPE.) I'm very sorry to say that the default emxomfld linker, ilink v5.xy isn't available yet. I assume the mozilla team will put it out sooner or later as it is required for building mozilla. In the mean time you should try use the Visual Age for C++ v3.08 linker, setting EMXOMFLD_TYPE=VAC308. If you don have this linker around, you will have to resort to link386. For that to work you need to set EMXOMFLD_LINKER=link386.exe and EMXOMFLD_TYPE=link386, then you must rerun MakeOmfLibs.cmd since there is a hack or two for link386 in emxomf. BTW. what are you builing, wxWindows? It's kind of unusual to invoke ld/emxomfld directly for highlevel C and C++ project, usually one would use g++ or gcc. > Or is this possibly a configure problem specific to the package > (gdk-pixbuf-0.17.0)? This problem doesn't occur using gcc 3.2.1 > (although others arise further down the track, but not gcc-related). > > Btw, are stdint.h, inttypes.h (and the code in their associated > lib(s)) likely to surface at any point soon? I recall reading on > around on sourceforge that there where some bugs associated with some > of the functions. stdint.h and inttypes.h are present, however there is a big at todo any new code. > Following on from this, how "complete" are the headers and libs do > you intend your port of gcc, etc., to be, OS/2-ness/isms > notwithstanding? Not sure if I understand this question (I'm probably just too tired). But the headers are updated by merging EMX isms (which are of then M$/VAC/Watcom(=PC) isms realy) into the FreeBSD 5.1 (at the moment) base header. Function not supported are either commented out with at /** at todo */ or let for the linker to complain about. There are some standard defines (_POSIX_*,*_VISIBLE* and such) which doesn't necessarily give the right picture of supported features at the moment, but when someone find code which breaks due to that I'm sure we can fix it one or the other way. (There is one such problem internally in the beta2 headers btw. The first _POSIX* #define of unidef.h shound't be there (as the comment say). Depending on #include order it may hide bits of of sys/limits.h / limits.h.) Kind Regards, knut **= Email 4 ==========================** Date: Sat, 20 Sep 2003 10:00:42 +1000 From: Alexander Newman Subject: Re: Re: Re: [Ux2bs] Innotek LIBC Thanks to Stephan and Knut for clarifying the licence question in my own mind a bit, at least. Moving on... > Now, have anyone actually tried GCC/LIBC beta2 by now? Any > suggestions, > problems, ideas, contributions? 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. Or is this possibly a configure problem specific to the package (gdk-pixbuf-0.17.0)? This problem doesn't occur using gcc 3.2.1 (although others arise further down the track, but not gcc-related). Btw, are stdint.h, inttypes.h (and the code in their associated lib(s)) likely to surface at any point soon? I recall reading on around on sourceforge that there where some bugs associated with some of the functions. Following on from this, how "complete" are the headers and libs do you intend your port of gcc, etc., to be, OS/2-ness/isms notwithstanding? Cheers, Alex. **= Email 5 ==========================** Date: Sat, 20 Sep 2003 11:38:29 -0400 From: "T.Sikora" Subject: Re: Re: [Ux2bs] Innotek LIBC 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 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? -- T.Sikora tsikora at ntplx dot net **= Email 6 ==========================** Date: Sat, 20 Sep 2003 17:22:51 +0200 From: Andreas Buening Subject: Re: Re: autoconf question, was Re: [Ux2bs] Innotek LIBC Stefan Neis wrote: > > 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... Since AC_PROG_CXX doesn't search for "gcc" by default, that's all you can do. However this affects only gcc 2.8.x and below, 2.9.x has g++. Bye, Andreas **= Email 7 ==========================** Date: Sat, 20 Sep 2003 17:23:01 +0200 From: Andreas Buening Subject: Re: [EMX] Re: waitpid : why does this not work? Ilya Zakharevich wrote: > > On Fri, Sep 19, 2003 at 01:36:56AM +0200, Andreas Buening wrote: > > > SIGCHLD is different on OS/2. > > Nonsense. There is no SIGCHLD on OS/2. However, there are some on EMX. > > In fact, there are too many: out of many different semantics of signal > processing, EMX supports two - distinguished by -Zbsd-signals and > -Zsysv-signals flags. Three. You forgot the emx-style signal handling. But I wasn't talking about different signal handler philosophies. Portable programs use sigaction() (at least they should) which is bsd-style, I guess. > > If you uncritically compile Unix programs that use a > > SIGCHLD handler, there is a good chance that your program will > > produce a deadlock. > > Same is true on Unix: there are many different semantics. If > possible, one should use POSIX interface... 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, 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. 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). Bye, Andreas **= Email 8 ==========================** Date: Sat, 20 Sep 2003 17:23:12 +0200 From: Andreas Buening Subject: Re: Re: [Ux2bs] Innotek LIBC Knut St. Osmundsen wrote: > > Andreas Buening wrote: > > 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. Sigh. So this is the billionth trial to reinvent the wheel and the thousandth trial to create a state of the art libc for OS/2 basically from scratch? Sorry, if I can't effort more enthusiasm. ;-) So you mean EM is also not willing to put his code under the term of the _L_GPL? Is there any list of functions that have been removed compared to "standard emx", have been added, are beeing rewritten? Bye, Andreas **= Email 9 ==========================** Date: Sat, 20 Sep 2003 19:50:57 -0800 From: "Dave and Natalie" Subject: Re: Re: [Ux2bs] Innotek LIBC On Sun, 21 Sep 2003 09:22:54 +1000 (EST), Alex Newman wrote: >Mikus Grinbergs also supplied some very useful help. > >Thanks to all, sorry about the bandwidth consumption. Huh? Why apoligize? We all need to learn about this new libc+gcc Dave **= Email 10 ==========================** Date: Sat, 20 Sep 2003 19:52:58 -0800 From: "Dave and Natalie" Subject: Re: Re: [Ux2bs] Innotek LIBC On Sat, 20 Sep 2003 22:04:12 +0200, Knut St. Osmundsen wrote: >Not with 'no debugging'. With link386 we must drop back to an earlier >level of debug info, HLL v3, which in some cases makes the debugger give >up displaying sources (and all the rest) for some object files. but what debugger do we use? Dave **= Email 11 ==========================** Date: Sat, 20 Sep 2003 20:51:46 +1000 (EST) From: "Alex Newman" Subject: Re: Re: [Ux2bs] Innotek LIBC On Sat, 20 Sep 2003 00:49:22 -0400, Henry Sobotka wrote: > Knut, for those of us on the outside, it would be useful to see a to-do > list, preferably prioritized. Ditto for CVS read access, which would > also give you a broader test base for changes as they're checked in. > > Also, has any thought been given to using some of the code written for > POSIX/2, which is BSD-based? e.g., cExt.*? That would be very useful. Alex. **= Email 12 ==========================** Date: Sat, 20 Sep 2003 21:19:16 +0200 (CEST) From: Stefan Neis Subject: Re: Re: [Ux2bs] Innotek LIBC On Sat, 20 Sep 2003, Knut St. Osmundsen wrote: > Where what? EMX.DLL is GPL with an redistribution exception (at least > some sources say so). Also docs/copying.emx which is what I was refering to... > However, once you start changing EMX.DLL that > exception doesn't hold any longer and it's plain GPL (at least the way I > read it). (see \emx\src\os2\tcpip.c for an example.) This, however is the part I had forgotten about. That should teach me to never start talking about licence questions without actually rereading the licence first. Sorry, Stefan **= Email 13 ==========================** Date: Sat, 20 Sep 2003 21:30:31 +0200 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC Henry Sobotka wrote: > Knut, for those of us on the outside, it would be useful to see a to-do > list, preferably prioritized. Ditto for CVS read access, which would > also give you a broader test base for changes as they're checked in. A to-do / wish list is kind of up to you guys. I have some initial items of my own, the two first I've heard repeated from several other peoples: - 64 bit I/O. Status: I've received a patch for this which I will review now. - Common handle space for files (incl. pipes) and sockets. Status: Needs planning. Ideas a feedback is appreciated. Comment: Must not hurt startup performance. - Support (non default) for default heap in high memory. Status: Planning started. Comment: GCC sometimes run out of heap while builing mozilla. As for CVS read access, that can be arranged. Only I want to see some commitments first. So, for the moment I'll do regular source snapshots of the libc/emx part. As the activity isn't that high yet, that shouldn't cause too much inconvenience. > Also, has any thought been given to using some of the code written for > POSIX/2, which is BSD-based? I don't know the POSIX/2 project very well, I've barely browsed the CVS once or twice. But certainly, if there is good code in there which could be used either in LIBC or as an additional library, please contribute it. I'm partial to a on demand approach to some of the LIBC development, for smaller items at least. Like, I'm not keen on implementing the complex math stuff (C99) unless there is a need for it. Kind Regards, knut **= Email 14 ==========================** Date: Sat, 20 Sep 2003 21:50:52 +0200 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC Andreas Buening wrote: > Knut St. Osmundsen wrote: > >> Andreas Buening wrote: > >>> 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. > > > Sigh. So this is the billionth trial to reinvent the wheel and the > thousandth trial to create a state of the art libc for OS/2 basically > from scratch? Sorry, if I can't effort more enthusiasm. ;-) "But it's different this time! Different colors!" ;-) Can I just point out that this isn't a _trial_ nor is it from _scratch_. We've already met the initial goal - making a LIBC which is suitable for GCC and Mozilla. > So you mean EM is also not willing to put his code under the term of > the _L_GPL? I haven't done the talkings with EM, but do you think we would've taken this approach elsewise? > 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. Kind Regards, knut **= Email 15 ==========================** Date: Sat, 20 Sep 2003 22:04:12 +0200 From: "Knut St. Osmundsen" Subject: Re: Re: [Ux2bs] Innotek LIBC 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 Not with 'no debugging'. With link386 we must drop back to an earlier level of debug info, HLL v3, which in some cases makes the debugger give up displaying sources (and all the rest) for some object files. >> 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. There is a question of ilink, not VACPP. And the answer is hopefully given by the mozilla team before long. >> >> > Does this fix it? > > SET EMXOMFLD_TYPE=link386 You must set this too: SET EMXOMFLD_LINKER=link386 > > Running MakeOmfLibs produces a whole lot of messages and warnings. > Should I just ignore these? It's only warnings related to debuginfo. Neither should the messages be there nor should the debug info. There is a 'bug' in this release that we're shipping debug info in some of the libs. > In the os2tools.zip, ilinkwrap.exe what does that do? Is it > required for gcc of vaccp? ilinkwrap.exe isn't used by gcc 3.2.2 when building mozilla. Forget about it. Instead ask the mozilla guys for a working ilink if you're into building mozilla with GCC 3.2.2. (The thrunk now builds very nicely.) Kind Regards, knut