From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 4 Jan 2003 04:47:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 3 ************************************************** Friday 03 January 2003 Number 3 ************************************************** Subjects for today 1 Re: IMDB ApplyDiff 2.5 : Stefan Neis 2 Re: IMDB ApplyDiff 2.5 : Stefan Neis 3 Re: headers : Stefan Neis 4 Re: headers : Stefan Neis 5 Re: shadow-4.0.3 passwords : Stefan Neis 6 Re: shadow-4.0.3 passwords : Stefan Neis 7 Re: shadow-4.0.3 passwords : Stefan Neis 8 Re: shadow-4.0.3 passwords : Stefan Neis 9 Drive letters : Henry Sobotka 10 Drive letters : Henry Sobotka 11 Re: IMDB ApplyDiff 2.5 : John Poltorak 12 Re: IMDB ApplyDiff 2.5 : John Poltorak 13 Can anyone explain this? : John Poltorak 14 Can anyone explain this? : John Poltorak 15 Re: shadow-4.0.3 passwords : John Poltorak 16 Re: shadow-4.0.3 passwords : John Poltorak 17 Re: headers : John Poltorak 18 Re: headers : John Poltorak 19 Re: INETD & BOOTPD : John Poltorak 20 Re: INETD & BOOTPD : John Poltorak 21 Re: shadow-4.0.3 passwords : Adrian Gschwend" 22 Re: shadow-4.0.3 passwords : Adrian Gschwend" 23 Re: headers : Ted Sikora 24 Re: headers : Ted Sikora 25 Re: Can anyone explain this? : John Poltorak 26 Re: Can anyone explain this? : John Poltorak 27 Re: Can anyone explain this? : Stefan Neis 28 Re: Can anyone explain this? : Stefan Neis 29 gcc and Mozilla : Jeff Robinson 30 gcc and Mozilla : Jeff Robinson 31 Re: shadow-4.0.3 passwords : Thomas Hoffmann 32 Re: shadow-4.0.3 passwords : Thomas Hoffmann 33 Re: headers : John Poltorak 34 Re: headers : John Poltorak 35 Re: headers : Stefan Neis 36 Re: headers : Stefan Neis 37 Re: Can anyone explain this? : Stefan Neis 38 Re: Can anyone explain this? : Stefan Neis 39 Re: gcc and Mozilla : Jeff Robinson 40 Re: gcc and Mozilla : Jeff Robinson 41 Re: gcc and Mozilla : Jeff Robinson 42 Re: gcc and Mozilla : Jeff Robinson 43 Re: gcc and Mozilla : Ted Sikora 44 Re: gcc and Mozilla : Ted Sikora 45 Re: gcc and Mozilla : Ted Sikora 46 Re: gcc and Mozilla : Ted Sikora 47 Re: Drive letters : Steve Wendt" 48 Re: Drive letters : Steve Wendt" 49 Re: gcc and Mozilla : Steve Wendt" 50 Re: gcc and Mozilla : Steve Wendt" 51 Re: gcc and Mozilla : John Poltorak 52 Re: gcc and Mozilla : John Poltorak 53 header problems? : Ted Sikora 54 header problems? : Ted Sikora 55 Re: INETD & BOOTPD : Nicholas Sheppard 56 Re: INETD & BOOTPD : Nicholas Sheppard 57 Re: Can anyone explain this? : Steven Levine" 58 Re: Can anyone explain this? : Steven Levine" **= Email 1 ==========================** Date: Sat, 4 Jan 2003 01:10:34 +0100 (CET) From: Stefan Neis Subject: Re: IMDB ApplyDiff 2.5 On Fri, 3 Jan 2003, Christian Hennecke wrote: > -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\ > "" That's a `"`, an escape `"`, /usr/bin/gzip.exe, an escaped line break and two of `"`. Doesn't seem to match, that should probably have been -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\"" (unless, of course, it's the mailer which added the line break ...). Regards, Stefan **= Email 2 ==========================** Date: Sat, 4 Jan 2003 01:10:34 +0100 (CET) From: Stefan Neis Subject: Re: IMDB ApplyDiff 2.5 On Fri, 3 Jan 2003, Christian Hennecke wrote: > -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\ > "" That's a `"`, an escape `"`, /usr/bin/gzip.exe, an escaped line break and two of `"`. Doesn't seem to match, that should probably have been -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\"" (unless, of course, it's the mailer which added the line break ...). Regards, Stefan **= Email 3 ==========================** Date: Sat, 4 Jan 2003 01:21:25 +0100 (CET) From: Stefan Neis Subject: Re: headers On Fri, 3 Jan 2003, Ted Sikora wrote: > > I would suggest copying the posix/2 headers to /usr/include and leaving > > the emx headers in /emx/include and then setting:- > > > > C_INCLUDE_PATH=/usr/include;/emx/include > > > > Good idea. I'll see if it makes a difference. And don't forget to link with -lcExt or -lposix2 or whatever the name of the library in that outdated version on hobbes. Otherwise you are likely to get some linking errors (but of course you might try to get away without it, nevertheless, just be warned ...) BTW, any suggestions where I should upload a more up to date version of Posix/2 includes and library? Source code being available from sourceforge, I don't think there's much point in uploading it, too. Regards, Stefan **= Email 4 ==========================** Date: Sat, 4 Jan 2003 01:21:25 +0100 (CET) From: Stefan Neis Subject: Re: headers On Fri, 3 Jan 2003, Ted Sikora wrote: > > I would suggest copying the posix/2 headers to /usr/include and leaving > > the emx headers in /emx/include and then setting:- > > > > C_INCLUDE_PATH=/usr/include;/emx/include > > > > Good idea. I'll see if it makes a difference. And don't forget to link with -lcExt or -lposix2 or whatever the name of the library in that outdated version on hobbes. Otherwise you are likely to get some linking errors (but of course you might try to get away without it, nevertheless, just be warned ...) BTW, any suggestions where I should upload a more up to date version of Posix/2 includes and library? Source code being available from sourceforge, I don't think there's much point in uploading it, too. Regards, Stefan **= Email 5 ==========================** Date: Sat, 4 Jan 2003 01:26:35 +0100 (CET) From: Stefan Neis Subject: Re: shadow-4.0.3 passwords On Thu, 2 Jan 2003, Thomas Hoffmann wrote: > If you want to include posix/2 stuff into a standard build environment, > then you should provide the headers AND the lib(s). And this interferes > with the mythical EMU project ... Not really, AFAIK. Posix/2 currently compiles a static lib only, so all the problems created by using DLLs don't exist (but OTOH, we don't get the DLL's benefits either, but currently, I still hope this can wait for EMU). Regards, Stefan **= Email 6 ==========================** Date: Sat, 4 Jan 2003 01:26:35 +0100 (CET) From: Stefan Neis Subject: Re: shadow-4.0.3 passwords On Thu, 2 Jan 2003, Thomas Hoffmann wrote: > If you want to include posix/2 stuff into a standard build environment, > then you should provide the headers AND the lib(s). And this interferes > with the mythical EMU project ... Not really, AFAIK. Posix/2 currently compiles a static lib only, so all the problems created by using DLLs don't exist (but OTOH, we don't get the DLL's benefits either, but currently, I still hope this can wait for EMU). Regards, Stefan **= Email 7 ==========================** Date: Sat, 4 Jan 2003 01:37:46 +0100 (CET) From: Stefan Neis Subject: Re: shadow-4.0.3 passwords On Fri, 3 Jan 2003, John Poltorak wrote: > Is there a simple way to build the libs? Obtain them from CVS (at sourceforge) and call make. The problem is that if compilation breaks (e.g. because it doesn't like your GNUmake version), it's not really easy to get it to continue compilation (over here, it's always: "Fix Makefile or Make version", "make clean", make, wait for next problem...) > I'm not really sure what libs Posix/2 provides. Is there a list anywhere? cExt.a, an "extended" C library (compared to EMX's emxlibc?.dll). > Yes, there is a danger of fragmentation because Posix/2, libemu and > libunixos2 all seem to have a large degree of overlap. Yes, that's also why I'm reluctant to put any work into Posix/2 apart from making available what I currently have and which seems to work quite well for me (But then, it doesn't get _that_ much testing over here, there might well be a couple of funtions which I never used so far ...) Regards, Stefan P.S.: Actually, that's now "Dr. Stefan Neis" (still looks quite funny to me), which means I now have only one full job left, which _might_ give me some more time for wxWindows and/or Posix/2 - at least on weekends... :-) **= Email 8 ==========================** Date: Sat, 4 Jan 2003 01:37:46 +0100 (CET) From: Stefan Neis Subject: Re: shadow-4.0.3 passwords On Fri, 3 Jan 2003, John Poltorak wrote: > Is there a simple way to build the libs? Obtain them from CVS (at sourceforge) and call make. The problem is that if compilation breaks (e.g. because it doesn't like your GNUmake version), it's not really easy to get it to continue compilation (over here, it's always: "Fix Makefile or Make version", "make clean", make, wait for next problem...) > I'm not really sure what libs Posix/2 provides. Is there a list anywhere? cExt.a, an "extended" C library (compared to EMX's emxlibc?.dll). > Yes, there is a danger of fragmentation because Posix/2, libemu and > libunixos2 all seem to have a large degree of overlap. Yes, that's also why I'm reluctant to put any work into Posix/2 apart from making available what I currently have and which seems to work quite well for me (But then, it doesn't get _that_ much testing over here, there might well be a couple of funtions which I never used so far ...) Regards, Stefan P.S.: Actually, that's now "Dr. Stefan Neis" (still looks quite funny to me), which means I now have only one full job left, which _might_ give me some more time for wxWindows and/or Posix/2 - at least on weekends... :-) **= Email 9 ==========================** Date: Sat, 04 Jan 2003 04:32:27 -0500 From: Henry Sobotka Subject: Drive letters The one point that strikes me as missing in this entire discussion is the fact that c:/usr/bin is not the equivalent of /[c_drive|unixroot|whatever]/usr/bin, but rather of /dev/[da0s1|hda1|whatever]/usr/bin (assuming c: is the first primary on disk 1). In other words, the difference between DOSlike and UNIXlike file systems is the fact that the former exposes the hard disk location, whereas the latter hides it from the user via mount points. What this suggests is that the UNIX-OS2 FS be explicitly creatable instead of derived from a SET UNIXROOT statement or some mechanism that hides that variable from the user. Meaning how about an FS that, like TVFS, the user has to define such that anything undefined is invisible to it, with "mount c:/usr /usr" == "mount /dev/[da0s1|hda1|whatever]/usr /usr"? There's a lot to be said for partitioning. It's like dividing submarines into airtight compartments or projects into tasks, or having separate file cabinets for correspondence, finance, operations etc. instead of one humungous drawer. It's easier and faster to type "cd k:\mozilla" than "cd /home/henry/projects/mozilla" and disk access is likely quicker. With partitions you can also take advantage of HD speed differences, e.g. by putting heavily read material such as source code in the fastest area (usually the outside tracks), systems and applications near the center, and static stuff (docs and images) where it's slowest. Not to mention that, the bigger the partition, the greater the potential loss. One can even argue against single-tree filesystems on the grounds of the simplicity of "deltree /" versus "deltree [c...z]:\". Or against a standard FS because it's a known entity rather than a black box. Nonetheless, I think a UNIX-OS/2 system that maps drive letters to their UNIX-world /dev/ equivalent would be the way to go as opposed to arbitrary or user-defined naming. Drive letters represent real locations on hardware that UNIX-OS/2 can and should respect For instance, if John builds Perl with prefix=/usr/bin, '/' should mean "c:/" or "k:/" or "z:/" or wherever he mounted '/' for him, and ditto for the user who downloads his distribution. Just as it's really an abbreviaion for some "/dev/*/" mount point in the UNIX world. h~ **= Email 10 ==========================** Date: Sat, 04 Jan 2003 04:32:27 -0500 From: Henry Sobotka Subject: Drive letters The one point that strikes me as missing in this entire discussion is the fact that c:/usr/bin is not the equivalent of /[c_drive|unixroot|whatever]/usr/bin, but rather of /dev/[da0s1|hda1|whatever]/usr/bin (assuming c: is the first primary on disk 1). In other words, the difference between DOSlike and UNIXlike file systems is the fact that the former exposes the hard disk location, whereas the latter hides it from the user via mount points. What this suggests is that the UNIX-OS2 FS be explicitly creatable instead of derived from a SET UNIXROOT statement or some mechanism that hides that variable from the user. Meaning how about an FS that, like TVFS, the user has to define such that anything undefined is invisible to it, with "mount c:/usr /usr" == "mount /dev/[da0s1|hda1|whatever]/usr /usr"? There's a lot to be said for partitioning. It's like dividing submarines into airtight compartments or projects into tasks, or having separate file cabinets for correspondence, finance, operations etc. instead of one humungous drawer. It's easier and faster to type "cd k:\mozilla" than "cd /home/henry/projects/mozilla" and disk access is likely quicker. With partitions you can also take advantage of HD speed differences, e.g. by putting heavily read material such as source code in the fastest area (usually the outside tracks), systems and applications near the center, and static stuff (docs and images) where it's slowest. Not to mention that, the bigger the partition, the greater the potential loss. One can even argue against single-tree filesystems on the grounds of the simplicity of "deltree /" versus "deltree [c...z]:\". Or against a standard FS because it's a known entity rather than a black box. Nonetheless, I think a UNIX-OS/2 system that maps drive letters to their UNIX-world /dev/ equivalent would be the way to go as opposed to arbitrary or user-defined naming. Drive letters represent real locations on hardware that UNIX-OS/2 can and should respect For instance, if John builds Perl with prefix=/usr/bin, '/' should mean "c:/" or "k:/" or "z:/" or wherever he mounted '/' for him, and ditto for the user who downloads his distribution. Just as it's really an abbreviaion for some "/dev/*/" mount point in the UNIX world. h~ **= Email 11 ==========================** Date: Sat, 4 Jan 2003 09:24:27 +0000 From: John Poltorak Subject: Re: IMDB ApplyDiff 2.5 On Sat, Jan 04, 2003 at 01:10:34AM +0100, Stefan Neis wrote: > On Fri, 3 Jan 2003, Christian Hennecke wrote: > > > -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\ > > "" > > That's a `"`, an escape `"`, /usr/bin/gzip.exe, an escaped line break and > two of `"`. > Doesn't seem to match, that should probably have been > -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\"" > (unless, of course, it's the mailer which added the line break ...). My guess is that it's a Make problem. I wonder if it would disappear with Make 3.79.1 > Regards, > Stefan > -- John **= Email 12 ==========================** Date: Sat, 4 Jan 2003 09:24:27 +0000 From: John Poltorak Subject: Re: IMDB ApplyDiff 2.5 On Sat, Jan 04, 2003 at 01:10:34AM +0100, Stefan Neis wrote: > On Fri, 3 Jan 2003, Christian Hennecke wrote: > > > -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\ > > "" > > That's a `"`, an escape `"`, /usr/bin/gzip.exe, an escaped line break and > two of `"`. > Doesn't seem to match, that should probably have been > -DIMDBV_FILE_PACKER_NAME="\"/usr/bin/gzip.exe\"" > (unless, of course, it's the mailer which added the line break ...). My guess is that it's a Make problem. I wonder if it would disappear with Make 3.79.1 > Regards, > Stefan > -- John **= Email 13 ==========================** Date: Sat, 4 Jan 2003 09:35:02 +0000 From: John Poltorak Subject: Can anyone explain this? Can anyone explain why this patch in bootp is necessary:- ? diff -cb orig/bootptest.c new/bootptest.c *** orig/bootptest.c Mon Sep 04 00:09:58 1995 --- new/bootptest.c Mon Sep 04 01:06:42 1995 *************** *** 244,250 **** /* * Get server's listening port number */ ! sep = getservbyname("bootps", "udp"); if (sep) { bootps_port = ntohs((u_short) sep->s_port); } else { --- 244,250 ---- /* * Get server's listening port number */ ! sep = getservbyname("sbootp", "udp"); if (sep) { bootps_port = ntohs((u_short) sep->s_port); } else { Is it simply due to the use of different headers? Where does getservbyname() get defined? -- John **= Email 14 ==========================** Date: Sat, 4 Jan 2003 09:35:02 +0000 From: John Poltorak Subject: Can anyone explain this? Can anyone explain why this patch in bootp is necessary:- ? diff -cb orig/bootptest.c new/bootptest.c *** orig/bootptest.c Mon Sep 04 00:09:58 1995 --- new/bootptest.c Mon Sep 04 01:06:42 1995 *************** *** 244,250 **** /* * Get server's listening port number */ ! sep = getservbyname("bootps", "udp"); if (sep) { bootps_port = ntohs((u_short) sep->s_port); } else { --- 244,250 ---- /* * Get server's listening port number */ ! sep = getservbyname("sbootp", "udp"); if (sep) { bootps_port = ntohs((u_short) sep->s_port); } else { Is it simply due to the use of different headers? Where does getservbyname() get defined? -- John **= Email 15 ==========================** Date: Sat, 4 Jan 2003 10:47:33 +0000 From: John Poltorak Subject: Re: shadow-4.0.3 passwords On Sat, Jan 04, 2003 at 01:37:46AM +0100, Dr. Stefan Neis wrote: > On Fri, 3 Jan 2003, John Poltorak wrote: > > > Is there a simple way to build the libs? > > Obtain them from CVS (at sourceforge) and call make. > The problem is that if compilation breaks (e.g. because it doesn't > like your GNUmake version), it's not really easy to get it to > continue compilation (over here, it's always: "Fix Makefile or Make > version", "make clean", make, wait for next problem...) If you are putting together a new archive, it might as well be the definitive source... > > I'm not really sure what libs Posix/2 provides. Is there a list anywhere? > > cExt.a, an "extended" C library (compared to EMX's emxlibc?.dll). > > > Yes, there is a danger of fragmentation because Posix/2, libemu and > > libunixos2 all seem to have a large degree of overlap. > > Yes, that's also why I'm reluctant to put any work into Posix/2 apart > from making available what I currently have and which seems to work > quite well for me (But then, it doesn't get _that_ much testing over > here, there might well be a couple of funtions which I never used so > far ...) I doubt whether Posix/2 has been widely exposed, although I think it will prove very useful. I'll be interested to see what, if any difference it makes to my Perl build. > Regards, > Stefan > > P.S.: Actually, that's now "Dr. Stefan Neis" Congratulations! -- John **= Email 16 ==========================** Date: Sat, 4 Jan 2003 10:47:33 +0000 From: John Poltorak Subject: Re: shadow-4.0.3 passwords On Sat, Jan 04, 2003 at 01:37:46AM +0100, Dr. Stefan Neis wrote: > On Fri, 3 Jan 2003, John Poltorak wrote: > > > Is there a simple way to build the libs? > > Obtain them from CVS (at sourceforge) and call make. > The problem is that if compilation breaks (e.g. because it doesn't > like your GNUmake version), it's not really easy to get it to > continue compilation (over here, it's always: "Fix Makefile or Make > version", "make clean", make, wait for next problem...) If you are putting together a new archive, it might as well be the definitive source... > > I'm not really sure what libs Posix/2 provides. Is there a list anywhere? > > cExt.a, an "extended" C library (compared to EMX's emxlibc?.dll). > > > Yes, there is a danger of fragmentation because Posix/2, libemu and > > libunixos2 all seem to have a large degree of overlap. > > Yes, that's also why I'm reluctant to put any work into Posix/2 apart > from making available what I currently have and which seems to work > quite well for me (But then, it doesn't get _that_ much testing over > here, there might well be a couple of funtions which I never used so > far ...) I doubt whether Posix/2 has been widely exposed, although I think it will prove very useful. I'll be interested to see what, if any difference it makes to my Perl build. > Regards, > Stefan > > P.S.: Actually, that's now "Dr. Stefan Neis" Congratulations! -- John **= Email 17 ==========================** Date: Sat, 4 Jan 2003 11:05:19 +0000 From: John Poltorak Subject: Re: headers On Sat, Jan 04, 2003 at 01:21:25AM +0100, Stefan Neis wrote: > BTW, any suggestions where I should upload a more up to date version of > Posix/2 includes and library? How about ftp.os2ports.com/incoming ? > Regards, > Stefan > -- John **= Email 18 ==========================** Date: Sat, 4 Jan 2003 11:05:19 +0000 From: John Poltorak Subject: Re: headers On Sat, Jan 04, 2003 at 01:21:25AM +0100, Stefan Neis wrote: > BTW, any suggestions where I should upload a more up to date version of > Posix/2 includes and library? How about ftp.os2ports.com/incoming ? > Regards, > Stefan > -- John **= Email 19 ==========================** Date: Sat, 4 Jan 2003 11:58:57 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Sat, Jan 04, 2003 at 10:10:57PM +1100, Nicholas Sheppard wrote: > On Thu, 2 Jan 2003, John Poltorak wrote: > > > Ifanyone is familiar with how INETD launches other servers could you check > > BOOTPD for OS/2:- ? > > > > http://hobbes.nmsu.edu/pub/os2/util/network/tcpip/bootpd.zip > > > > This is described as a 'quick and dirty' port and no mention is made about > > its ability to run from INETD, and if it can, how it can pick up a socket. > > It can't be run from inetd. The `standalone' variable is set to TRUE at > line 266 of bootpd.c and all the code that would change it to anything > else is #ifdef'd out for EMX. If `standalone' is true, it creates its own > socket after the test on line 466. Yes, I now see the INETD handling has been commented out for EMX, I just wondered if it would be possible to cater for being launched from INETD in the same way as you made IPOP3D run from INETD on OS/2... One thing I didn't understand about the port was why this sort of patch was necessary:- ! sep = getservbyname("bootps", "udp"); ! sep = getservbyname("sbootp", "udp"); > Nicholas S. > > |\ Location: Wollongong, Australia | The optimist thinks this is the best of > |\ E-mail: nps at zeta.org.au | all possible worlds, and the pessimist > | WWW: http://www.zeta.org.au/~nps | knows it is. > | ---> Cynicism & Negativity | > - Robert Oppenheimer -- John **= Email 20 ==========================** Date: Sat, 4 Jan 2003 11:58:57 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Sat, Jan 04, 2003 at 10:10:57PM +1100, Nicholas Sheppard wrote: > On Thu, 2 Jan 2003, John Poltorak wrote: > > > Ifanyone is familiar with how INETD launches other servers could you check > > BOOTPD for OS/2:- ? > > > > http://hobbes.nmsu.edu/pub/os2/util/network/tcpip/bootpd.zip > > > > This is described as a 'quick and dirty' port and no mention is made about > > its ability to run from INETD, and if it can, how it can pick up a socket. > > It can't be run from inetd. The `standalone' variable is set to TRUE at > line 266 of bootpd.c and all the code that would change it to anything > else is #ifdef'd out for EMX. If `standalone' is true, it creates its own > socket after the test on line 466. Yes, I now see the INETD handling has been commented out for EMX, I just wondered if it would be possible to cater for being launched from INETD in the same way as you made IPOP3D run from INETD on OS/2... One thing I didn't understand about the port was why this sort of patch was necessary:- ! sep = getservbyname("bootps", "udp"); ! sep = getservbyname("sbootp", "udp"); > Nicholas S. > > |\ Location: Wollongong, Australia | The optimist thinks this is the best of > |\ E-mail: nps at zeta.org.au | all possible worlds, and the pessimist > | WWW: http://www.zeta.org.au/~nps | knows it is. > | ---> Cynicism & Negativity | > - Robert Oppenheimer -- John **= Email 21 ==========================** Date: Sat, 04 Jan 2003 13:26:19 +0100 (CET) From: "Adrian Gschwend" Subject: Re: shadow-4.0.3 passwords On Sat, 4 Jan 2003 01:37:46 +0100 (CET), Stefan Neis wrote: >P.S.: Actually, that's now "Dr. Stefan Neis" (still looks quite funny > to me), which means I now have only one full job left, which > _might_ give me some more time for wxWindows and/or Posix/2 - at > least on weekends... :-) hehe cool congratulations! Looking forward to it :-) cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 22 ==========================** Date: Sat, 04 Jan 2003 13:26:19 +0100 (CET) From: "Adrian Gschwend" Subject: Re: shadow-4.0.3 passwords On Sat, 4 Jan 2003 01:37:46 +0100 (CET), Stefan Neis wrote: >P.S.: Actually, that's now "Dr. Stefan Neis" (still looks quite funny > to me), which means I now have only one full job left, which > _might_ give me some more time for wxWindows and/or Posix/2 - at > least on weekends... :-) hehe cool congratulations! Looking forward to it :-) cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 23 ==========================** Date: Sat, 04 Jan 2003 13:46:35 -0500 From: Ted Sikora Subject: Re: headers John Poltorak wrote: > On Sat, Jan 04, 2003 at 04:27:03PM +0100, Stefan Neis wrote: > >>On Sat, 4 Jan 2003, John Poltorak wrote: >> >> >>>>BTW, any suggestions where I should upload a more up to date version of >>>>Posix/2 includes and library? >>> >>>How about ftp.os2ports.com/incoming ? >> >>OK, done. ;-) > > > Excellent! > > I hope Ted let's us know where he moves this to eventually. How about /pub/os2/unix/devtools/headers ?? -- Ted Sikora tsikora at ntplx.net **= Email 24 ==========================** Date: Sat, 04 Jan 2003 13:46:35 -0500 From: Ted Sikora Subject: Re: headers John Poltorak wrote: > On Sat, Jan 04, 2003 at 04:27:03PM +0100, Stefan Neis wrote: > >>On Sat, 4 Jan 2003, John Poltorak wrote: >> >> >>>>BTW, any suggestions where I should upload a more up to date version of >>>>Posix/2 includes and library? >>> >>>How about ftp.os2ports.com/incoming ? >> >>OK, done. ;-) > > > Excellent! > > I hope Ted let's us know where he moves this to eventually. How about /pub/os2/unix/devtools/headers ?? -- Ted Sikora tsikora at ntplx.net **= Email 25 ==========================** Date: Sat, 4 Jan 2003 14:17:53 +0000 From: John Poltorak Subject: Re: Can anyone explain this? On Sat, Jan 04, 2003 at 02:55:34PM +0100, Stefan Neis wrote: > On Sat, 4 Jan 2003, John Poltorak wrote: > > > ! sep = getservbyname("bootps", "udp"); > vs. > > ! sep = getservbyname("sbootp", "udp"); > > > Is it simply due to the use of different headers? > > Actually, getservbyname is a very simple functions which looks up > which port should be used for "bootps" or "sbootp" in > /etc/servives (aka %ETC%/services). > My file contains > > bootps 67/tcp sbootp #Bootstrap Protocol Server > > bootps 67/udp dhcps sbootp #Bootstrap Protocol Server > which I supposedly is telling me that I should be able to use both > names, but maybe getservbyname can only handle the first one and not > several aliases or something similar. Or things are handled differently > on other systems. > So in short that's thing is telling you that somebody aparently prefers > the name "sbootp" over "bootps" - maybe a "recent" change in standards > or something similar. Does it sound as though this patch is no longer required? There are quite a few patches like this in the BOOTPD port. I guess the following can be treated the same:-.. ! servp = getservbyname("bootpc", "udp"); vs. ! servp = getservbyname("cbootp", "udp"); > Regards, > Stefan > -- John **= Email 26 ==========================** Date: Sat, 4 Jan 2003 14:17:53 +0000 From: John Poltorak Subject: Re: Can anyone explain this? On Sat, Jan 04, 2003 at 02:55:34PM +0100, Stefan Neis wrote: > On Sat, 4 Jan 2003, John Poltorak wrote: > > > ! sep = getservbyname("bootps", "udp"); > vs. > > ! sep = getservbyname("sbootp", "udp"); > > > Is it simply due to the use of different headers? > > Actually, getservbyname is a very simple functions which looks up > which port should be used for "bootps" or "sbootp" in > /etc/servives (aka %ETC%/services). > My file contains > > bootps 67/tcp sbootp #Bootstrap Protocol Server > > bootps 67/udp dhcps sbootp #Bootstrap Protocol Server > which I supposedly is telling me that I should be able to use both > names, but maybe getservbyname can only handle the first one and not > several aliases or something similar. Or things are handled differently > on other systems. > So in short that's thing is telling you that somebody aparently prefers > the name "sbootp" over "bootps" - maybe a "recent" change in standards > or something similar. Does it sound as though this patch is no longer required? There are quite a few patches like this in the BOOTPD port. I guess the following can be treated the same:-.. ! servp = getservbyname("bootpc", "udp"); vs. ! servp = getservbyname("cbootp", "udp"); > Regards, > Stefan > -- John **= Email 27 ==========================** Date: Sat, 4 Jan 2003 14:55:34 +0100 (CET) From: Stefan Neis Subject: Re: Can anyone explain this? On Sat, 4 Jan 2003, John Poltorak wrote: > ! sep = getservbyname("bootps", "udp"); vs. > ! sep = getservbyname("sbootp", "udp"); > Is it simply due to the use of different headers? Actually, getservbyname is a very simple functions which looks up which port should be used for "bootps" or "sbootp" in /etc/servives (aka %ETC%/services). My file contains > bootps 67/tcp sbootp #Bootstrap Protocol Server > bootps 67/udp dhcps sbootp #Bootstrap Protocol Server which I supposedly is telling me that I should be able to use both names, but maybe getservbyname can only handle the first one and not several aliases or something similar. Or things are handled differently on other systems. So in short that's thing is telling you that somebody aparently prefers the name "sbootp" over "bootps" - maybe a "recent" change in standards or something similar. Regards, Stefan **= Email 28 ==========================** Date: Sat, 4 Jan 2003 14:55:34 +0100 (CET) From: Stefan Neis Subject: Re: Can anyone explain this? On Sat, 4 Jan 2003, John Poltorak wrote: > ! sep = getservbyname("bootps", "udp"); vs. > ! sep = getservbyname("sbootp", "udp"); > Is it simply due to the use of different headers? Actually, getservbyname is a very simple functions which looks up which port should be used for "bootps" or "sbootp" in /etc/servives (aka %ETC%/services). My file contains > bootps 67/tcp sbootp #Bootstrap Protocol Server > bootps 67/udp dhcps sbootp #Bootstrap Protocol Server which I supposedly is telling me that I should be able to use both names, but maybe getservbyname can only handle the first one and not several aliases or something similar. Or things are handled differently on other systems. So in short that's thing is telling you that somebody aparently prefers the name "sbootp" over "bootps" - maybe a "recent" change in standards or something similar. Regards, Stefan **= Email 29 ==========================** Date: Sat, 04 Jan 2003 15:01:12 -0600 From: Jeff Robinson Subject: gcc and Mozilla I'm not certain if many folks here follow the traffic on the netscape.public.mozilla.os2 newsgroup at all, but it looks like a subject has come up about a gcc-based build of Mozilla. In the past Henry Sobotka was successful in creating a few gcc-based builds of Mozilla, but from what he has told me previously (and from my own experience), it is definitely no walk in the park to get the critter compiled. There were particular versions of the tools that had to be used, as not all worked equally well(there was a discussion about the MozTools.wpi on Hobbes previously in this group). Recently in the newsgroups Mike Kaply, head OS/2 IBM Mozilla wrangler, has basically laid out the status of the OS/2 build. IBM is finding it increasingly difficult to maintain the OS/2 build using Visual Age C++ (compiler limitations, etc.), but are having a lot of difficulty getting a gcc build out the door. A quote from Mike Kaply: >"[Disabling debug during the build] defeats the purpose of using GCC. We >want to produce a build with GCC that is comparable to the VACPP build. > >If we have to turn off various options to get GCC working, then we are >wasting our time. > >If the OS/2 version of GCC isn't up to the task of building Mozilla, >then the 1.3 release will be the last OS/2 version of Mozilla. " Basically everyone is trying to figure out why gcc builds fail on OS/2 where they are common-place on other platforms. Which of course quickly brings to mind the work this group is doing to not only standardise tools, but to have the most up-to-date ones available (and working). Does anyone consider this a suitable "real-world" goal to help prioritise what tools the UnixOS2 project works on next? Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 30 ==========================** Date: Sat, 04 Jan 2003 15:01:12 -0600 From: Jeff Robinson Subject: gcc and Mozilla I'm not certain if many folks here follow the traffic on the netscape.public.mozilla.os2 newsgroup at all, but it looks like a subject has come up about a gcc-based build of Mozilla. In the past Henry Sobotka was successful in creating a few gcc-based builds of Mozilla, but from what he has told me previously (and from my own experience), it is definitely no walk in the park to get the critter compiled. There were particular versions of the tools that had to be used, as not all worked equally well(there was a discussion about the MozTools.wpi on Hobbes previously in this group). Recently in the newsgroups Mike Kaply, head OS/2 IBM Mozilla wrangler, has basically laid out the status of the OS/2 build. IBM is finding it increasingly difficult to maintain the OS/2 build using Visual Age C++ (compiler limitations, etc.), but are having a lot of difficulty getting a gcc build out the door. A quote from Mike Kaply: >"[Disabling debug during the build] defeats the purpose of using GCC. We >want to produce a build with GCC that is comparable to the VACPP build. > >If we have to turn off various options to get GCC working, then we are >wasting our time. > >If the OS/2 version of GCC isn't up to the task of building Mozilla, >then the 1.3 release will be the last OS/2 version of Mozilla. " Basically everyone is trying to figure out why gcc builds fail on OS/2 where they are common-place on other platforms. Which of course quickly brings to mind the work this group is doing to not only standardise tools, but to have the most up-to-date ones available (and working). Does anyone consider this a suitable "real-world" goal to help prioritise what tools the UnixOS2 project works on next? Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 31 ==========================** Date: Sat, 04 Jan 2003 15:27:30 +0100 From: Thomas Hoffmann Subject: Re: shadow-4.0.3 passwords Oh, I meant "intereferes CONCEPTUALLY", physically it can not interfere with stuff that is not there (yet) ;-) Thomas Stefan Neis wrote: > On Thu, 2 Jan 2003, Thomas Hoffmann wrote: > > >>If you want to include posix/2 stuff into a standard build environment, >>then you should provide the headers AND the lib(s). And this interferes >>with the mythical EMU project ... > > > Not really, AFAIK. Posix/2 currently compiles a static lib only, so all > the problems created by using DLLs don't exist (but OTOH, we don't get > the DLL's benefits either, but currently, I still hope this can wait for > EMU). > > Regards, > Stefan > > > **= Email 32 ==========================** Date: Sat, 04 Jan 2003 15:27:30 +0100 From: Thomas Hoffmann Subject: Re: shadow-4.0.3 passwords Oh, I meant "intereferes CONCEPTUALLY", physically it can not interfere with stuff that is not there (yet) ;-) Thomas Stefan Neis wrote: > On Thu, 2 Jan 2003, Thomas Hoffmann wrote: > > >>If you want to include posix/2 stuff into a standard build environment, >>then you should provide the headers AND the lib(s). And this interferes >>with the mythical EMU project ... > > > Not really, AFAIK. Posix/2 currently compiles a static lib only, so all > the problems created by using DLLs don't exist (but OTOH, we don't get > the DLL's benefits either, but currently, I still hope this can wait for > EMU). > > Regards, > Stefan > > > **= Email 33 ==========================** Date: Sat, 4 Jan 2003 15:55:54 +0000 From: John Poltorak Subject: Re: headers On Sat, Jan 04, 2003 at 04:27:03PM +0100, Stefan Neis wrote: > On Sat, 4 Jan 2003, John Poltorak wrote: > > > > BTW, any suggestions where I should upload a more up to date version of > > > Posix/2 includes and library? > > > > How about ftp.os2ports.com/incoming ? > > OK, done. ;-) Excellent! I hope Ted let's us know where he moves this to eventually. I propose that we try and use this set of headers in preference to those supplied in EMX, possibly using those from EMX as an alternative set in another location, but I don't know if this would be necessary... I guess by adopting the Posix/2 headers we can say goodbye to the:- -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp hoops that we have had to use until now. Are there any other kludges that could also be removed? Should we take it that you are the maintainer of these headers? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. -- John **= Email 34 ==========================** Date: Sat, 4 Jan 2003 15:55:54 +0000 From: John Poltorak Subject: Re: headers On Sat, Jan 04, 2003 at 04:27:03PM +0100, Stefan Neis wrote: > On Sat, 4 Jan 2003, John Poltorak wrote: > > > > BTW, any suggestions where I should upload a more up to date version of > > > Posix/2 includes and library? > > > > How about ftp.os2ports.com/incoming ? > > OK, done. ;-) Excellent! I hope Ted let's us know where he moves this to eventually. I propose that we try and use this set of headers in preference to those supplied in EMX, possibly using those from EMX as an alternative set in another location, but I don't know if this would be necessary... I guess by adopting the Posix/2 headers we can say goodbye to the:- -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp hoops that we have had to use until now. Are there any other kludges that could also be removed? Should we take it that you are the maintainer of these headers? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. -- John **= Email 35 ==========================** Date: Sat, 4 Jan 2003 16:27:03 +0100 (CET) From: Stefan Neis Subject: Re: headers On Sat, 4 Jan 2003, John Poltorak wrote: > > BTW, any suggestions where I should upload a more up to date version of > > Posix/2 includes and library? > > How about ftp.os2ports.com/incoming ? OK, done. ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 36 ==========================** Date: Sat, 4 Jan 2003 16:27:03 +0100 (CET) From: Stefan Neis Subject: Re: headers On Sat, 4 Jan 2003, John Poltorak wrote: > > BTW, any suggestions where I should upload a more up to date version of > > Posix/2 includes and library? > > How about ftp.os2ports.com/incoming ? OK, done. ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 37 ==========================** Date: Sat, 4 Jan 2003 16:35:20 +0100 (CET) From: Stefan Neis Subject: Re: Can anyone explain this? On Sat, 4 Jan 2003, John Poltorak wrote: > Does it sound as though this patch is no longer required? Yes, it does. Even if some older TCP/IP packages don't understand bootps and/or bootpc, it's easy enough to update %ETC%/services (plain text file). The oldest I have is a Warp4 with the latest(?) MPTS fix pack (86something?) applied and the service file looks like getservbyname should understand bootps and bootpc. > I guess the following can be treated the same:-.. > ! servp = getservbyname("bootpc", "udp"); > vs. > ! servp = getservbyname("cbootp", "udp"); Yes. Regards, Stefan **= Email 38 ==========================** Date: Sat, 4 Jan 2003 16:35:20 +0100 (CET) From: Stefan Neis Subject: Re: Can anyone explain this? On Sat, 4 Jan 2003, John Poltorak wrote: > Does it sound as though this patch is no longer required? Yes, it does. Even if some older TCP/IP packages don't understand bootps and/or bootpc, it's easy enough to update %ETC%/services (plain text file). The oldest I have is a Warp4 with the latest(?) MPTS fix pack (86something?) applied and the service file looks like getservbyname should understand bootps and bootpc. > I guess the following can be treated the same:-.. > ! servp = getservbyname("bootpc", "udp"); > vs. > ! servp = getservbyname("cbootp", "udp"); Yes. Regards, Stefan **= Email 39 ==========================** Date: Sat, 04 Jan 2003 19:04:44 -0600 From: Jeff Robinson Subject: Re: gcc and Mozilla John Poltorak wrote: > On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > > >>Basically everyone is trying to figure out why gcc builds fail on OS/2 >>where they are common-place on other platforms. Which of course quickly >>brings to mind the work this group is doing to not only standardise >>tools, but to have the most up-to-date ones available (and working). > > > Do have a list of the pre-requisite list of tools (including versions) > required for building Mozilla? > There is a list of required software at http://www.mozilla.org/ports/os2/setup.html This was originally setup for the VACPP build, I believe. From experience I learned that thing were very dependent on the proper version and archive of each tool, each seeming to have it's own special foible. (Like one version of pwd return a path name including drive letter, and another version only the path... obviously the latter isn't that OS/2 workable). This had originally lead me to compile the MozTools WarpIN archive just because it was so tedious to get everything together in the first place. I'm willing to try and make a new "MozTools" archive out of the latest UnixOS2 packages if our tools can do everything that the build-system needs. (Obviously folks that want the entire UnixOS2 environment wouldn't need such a thing). Needless to say the build is non-trivial; it takes about 4 hours on my 800Mhz Athlon with 512megs of RAM. > We've come a long way in the last year thanks to some excellent work by a > number of people. We've also managed to pinpoint a number of commonly > occuring problem areas, which I would suggest are generally due to the > shell, Make or headers. > I remember one of the earlier versions of gmake was also a problem for Mozilla as it would run out of file handles. I believe Henry Sobotka compiled a special vesion specifically to get around this problem. > In quite a number of arears, we are up to date. Autoconf, Automake, Perl, > PDKSH are all on par with Unix versions. sed/grep/awk are close, as is Make. > The GNU utils are a little out of date, but I'm not sure how much that > really matters. > Javier Pedemont has opened a meta-bug on Bugzilla to do with the building of Mozilla with EMX ( http://bugzilla.mozilla.org/show_bug.cgi?id=177789 ) where he details using some newer tools, though not at the same level as what UnixOS2 has been able to produce... things like Perl 5.6 are on the list. One of his attachments details the new list. > The most likely problem is likely to be gcc. What is the earliest version > we can get away with using? > Javier had mentioned on the newsgroups that he had been using gcc 3.0.3, but because of "problems" he had backleveled to pgcc 2.95.3 (I believe)... though of course this has its own problems because it exhausts the virtual memory due to the size of some of the files (and their includes) that it is trying to compile. The is where the suggestion had come in to disable the 'debugs' that Mike Kaply's comment refers to. > >>Does anyone consider this a suitable "real-world" goal to help >>prioritise what tools the UnixOS2 project works on next? > > > I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is > like herding cats :-)... > Point well taken! I just wanted to pretend to be a manager and say prioritise, at the same time leveraging my paradigm. Now I feel all dirty. > Having said, no one is saying what the specific problems are in building > Mozilla, and you can't prioritise building tools without identifying the > shortcomings in the current toolset. > I've dropped an e-mail message to Javier to see if he can supply us with some more detailed information. I'll keep folks updated when I receive a reply. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 40 ==========================** Date: Sat, 04 Jan 2003 19:04:44 -0600 From: Jeff Robinson Subject: Re: gcc and Mozilla John Poltorak wrote: > On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > > >>Basically everyone is trying to figure out why gcc builds fail on OS/2 >>where they are common-place on other platforms. Which of course quickly >>brings to mind the work this group is doing to not only standardise >>tools, but to have the most up-to-date ones available (and working). > > > Do have a list of the pre-requisite list of tools (including versions) > required for building Mozilla? > There is a list of required software at http://www.mozilla.org/ports/os2/setup.html This was originally setup for the VACPP build, I believe. From experience I learned that thing were very dependent on the proper version and archive of each tool, each seeming to have it's own special foible. (Like one version of pwd return a path name including drive letter, and another version only the path... obviously the latter isn't that OS/2 workable). This had originally lead me to compile the MozTools WarpIN archive just because it was so tedious to get everything together in the first place. I'm willing to try and make a new "MozTools" archive out of the latest UnixOS2 packages if our tools can do everything that the build-system needs. (Obviously folks that want the entire UnixOS2 environment wouldn't need such a thing). Needless to say the build is non-trivial; it takes about 4 hours on my 800Mhz Athlon with 512megs of RAM. > We've come a long way in the last year thanks to some excellent work by a > number of people. We've also managed to pinpoint a number of commonly > occuring problem areas, which I would suggest are generally due to the > shell, Make or headers. > I remember one of the earlier versions of gmake was also a problem for Mozilla as it would run out of file handles. I believe Henry Sobotka compiled a special vesion specifically to get around this problem. > In quite a number of arears, we are up to date. Autoconf, Automake, Perl, > PDKSH are all on par with Unix versions. sed/grep/awk are close, as is Make. > The GNU utils are a little out of date, but I'm not sure how much that > really matters. > Javier Pedemont has opened a meta-bug on Bugzilla to do with the building of Mozilla with EMX ( http://bugzilla.mozilla.org/show_bug.cgi?id=177789 ) where he details using some newer tools, though not at the same level as what UnixOS2 has been able to produce... things like Perl 5.6 are on the list. One of his attachments details the new list. > The most likely problem is likely to be gcc. What is the earliest version > we can get away with using? > Javier had mentioned on the newsgroups that he had been using gcc 3.0.3, but because of "problems" he had backleveled to pgcc 2.95.3 (I believe)... though of course this has its own problems because it exhausts the virtual memory due to the size of some of the files (and their includes) that it is trying to compile. The is where the suggestion had come in to disable the 'debugs' that Mike Kaply's comment refers to. > >>Does anyone consider this a suitable "real-world" goal to help >>prioritise what tools the UnixOS2 project works on next? > > > I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is > like herding cats :-)... > Point well taken! I just wanted to pretend to be a manager and say prioritise, at the same time leveraging my paradigm. Now I feel all dirty. > Having said, no one is saying what the specific problems are in building > Mozilla, and you can't prioritise building tools without identifying the > shortcomings in the current toolset. > I've dropped an e-mail message to Javier to see if he can supply us with some more detailed information. I'll keep folks updated when I receive a reply. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 41 ==========================** Date: Sat, 04 Jan 2003 19:11:18 -0600 From: Jeff Robinson Subject: Re: gcc and Mozilla Ted Sikora wrote: > John Poltorak wrote: > >> On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: >> >> >>> Basically everyone is trying to figure out why gcc builds fail on >>> OS/2 where they are common-place on other platforms. Which of course >>> quickly brings to mind the work this group is doing to not only >>> standardise tools, but to have the most up-to-date ones available >>> (and working). >> >> >> >> Do have a list of the pre-requisite list of tools (including versions) >> required for building Mozilla? > > > Jeff can you do this? Maybe a link to Moztools.wpi > > Can you give us a rundown on how to build Mozilla and what you use. > We need to update gcc ourselves so this might be the perfect time to > get it debugged. > > Do you set this in newgcc.cmd for each project? > SET GCC_WEAKSYMS=f:/programming/mozilla/weaksyms.omf > > or can this be a permanant env variable. > > -- > Ted Sikora > tsikora at ntplx.net > > What I'm going to work on doing is assembling a new set of tools based on the list, but from the latest packages we have available from UnixOS2. This should be significantly easier with UnixOS2's common DLLs and such. The original WarpIN archive is at http://hobbes.nmsu.edu/pub/os2/dev/util/moztools-2002-01-04.wpi but I would check it against the Mozilla page to make certain that the utilities don't need to be updated. Though at this point I think we're better off to try and get UnixOS2-only tools working instead. One thing I have not fully been able to discern is whether the weaksyms setting is particular to each project or not. What I've read seems to indicate that it is, but I'm not 100% on that. I seem to recall previously that there were some folks working on getting the latest and greatest version of gcc compiled to OS/2, as well... does anyone know if that came to fruition or not? Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 42 ==========================** Date: Sat, 04 Jan 2003 19:11:18 -0600 From: Jeff Robinson Subject: Re: gcc and Mozilla Ted Sikora wrote: > John Poltorak wrote: > >> On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: >> >> >>> Basically everyone is trying to figure out why gcc builds fail on >>> OS/2 where they are common-place on other platforms. Which of course >>> quickly brings to mind the work this group is doing to not only >>> standardise tools, but to have the most up-to-date ones available >>> (and working). >> >> >> >> Do have a list of the pre-requisite list of tools (including versions) >> required for building Mozilla? > > > Jeff can you do this? Maybe a link to Moztools.wpi > > Can you give us a rundown on how to build Mozilla and what you use. > We need to update gcc ourselves so this might be the perfect time to > get it debugged. > > Do you set this in newgcc.cmd for each project? > SET GCC_WEAKSYMS=f:/programming/mozilla/weaksyms.omf > > or can this be a permanant env variable. > > -- > Ted Sikora > tsikora at ntplx.net > > What I'm going to work on doing is assembling a new set of tools based on the list, but from the latest packages we have available from UnixOS2. This should be significantly easier with UnixOS2's common DLLs and such. The original WarpIN archive is at http://hobbes.nmsu.edu/pub/os2/dev/util/moztools-2002-01-04.wpi but I would check it against the Mozilla page to make certain that the utilities don't need to be updated. Though at this point I think we're better off to try and get UnixOS2-only tools working instead. One thing I have not fully been able to discern is whether the weaksyms setting is particular to each project or not. What I've read seems to indicate that it is, but I'm not 100% on that. I seem to recall previously that there were some folks working on getting the latest and greatest version of gcc compiled to OS/2, as well... does anyone know if that came to fruition or not? Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 43 ==========================** Date: Sat, 04 Jan 2003 19:45:01 -0500 From: Ted Sikora Subject: Re: gcc and Mozilla John Poltorak wrote: > On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > > >>Basically everyone is trying to figure out why gcc builds fail on OS/2 >>where they are common-place on other platforms. Which of course quickly >>brings to mind the work this group is doing to not only standardise >>tools, but to have the most up-to-date ones available (and working). > > > Do have a list of the pre-requisite list of tools (including versions) > required for building Mozilla? Jeff can you do this? Maybe a link to Moztools.wpi Can you give us a rundown on how to build Mozilla and what you use. We need to update gcc ourselves so this might be the perfect time to get it debugged. Do you set this in newgcc.cmd for each project? SET GCC_WEAKSYMS=f:/programming/mozilla/weaksyms.omf or can this be a permanant env variable. -- Ted Sikora tsikora at ntplx.net **= Email 44 ==========================** Date: Sat, 04 Jan 2003 19:45:01 -0500 From: Ted Sikora Subject: Re: gcc and Mozilla John Poltorak wrote: > On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > > >>Basically everyone is trying to figure out why gcc builds fail on OS/2 >>where they are common-place on other platforms. Which of course quickly >>brings to mind the work this group is doing to not only standardise >>tools, but to have the most up-to-date ones available (and working). > > > Do have a list of the pre-requisite list of tools (including versions) > required for building Mozilla? Jeff can you do this? Maybe a link to Moztools.wpi Can you give us a rundown on how to build Mozilla and what you use. We need to update gcc ourselves so this might be the perfect time to get it debugged. Do you set this in newgcc.cmd for each project? SET GCC_WEAKSYMS=f:/programming/mozilla/weaksyms.omf or can this be a permanant env variable. -- Ted Sikora tsikora at ntplx.net **= Email 45 ==========================** Date: Sat, 04 Jan 2003 20:09:50 -0500 From: Ted Sikora Subject: Re: gcc and Mozilla Ted Sikora wrote: > John Poltorak wrote: > >> On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: >> >> >>> Basically everyone is trying to figure out why gcc builds fail on >>> OS/2 where they are common-place on other platforms. Which of course >>> quickly brings to mind the work this group is doing to not only >>> standardise tools, but to have the most up-to-date ones available >>> (and working). >> >> >> >> Do have a list of the pre-requisite list of tools (including versions) >> required for building Mozilla? > > > Jeff can you do this? Maybe a link to Moztools.wpi > > Can you give us a rundown on how to build Mozilla and what you use. > We need to update gcc ourselves so this might be the perfect time to > get it debugged. > > Do you set this in newgcc.cmd for each project? > SET GCC_WEAKSYMS=f:/programming/mozilla/weaksyms.omf > > or can this be a permanant env variable. > The -Zomf flag issue .. besides makiking the libs are there any specific env variables that should be set for gcc 3.0.3 above and beyond 2.8.1? Any removed for compatibility sake? Somebody said remove Set C_Include_Path= Does this seem right? -- Ted Sikora tsikora at ntplx.net **= Email 46 ==========================** Date: Sat, 04 Jan 2003 20:09:50 -0500 From: Ted Sikora Subject: Re: gcc and Mozilla Ted Sikora wrote: > John Poltorak wrote: > >> On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: >> >> >>> Basically everyone is trying to figure out why gcc builds fail on >>> OS/2 where they are common-place on other platforms. Which of course >>> quickly brings to mind the work this group is doing to not only >>> standardise tools, but to have the most up-to-date ones available >>> (and working). >> >> >> >> Do have a list of the pre-requisite list of tools (including versions) >> required for building Mozilla? > > > Jeff can you do this? Maybe a link to Moztools.wpi > > Can you give us a rundown on how to build Mozilla and what you use. > We need to update gcc ourselves so this might be the perfect time to > get it debugged. > > Do you set this in newgcc.cmd for each project? > SET GCC_WEAKSYMS=f:/programming/mozilla/weaksyms.omf > > or can this be a permanant env variable. > The -Zomf flag issue .. besides makiking the libs are there any specific env variables that should be set for gcc 3.0.3 above and beyond 2.8.1? Any removed for compatibility sake? Somebody said remove Set C_Include_Path= Does this seem right? -- Ted Sikora tsikora at ntplx.net **= Email 47 ==========================** Date: Sat, 04 Jan 2003 20:19:54 -0800 (PST) From: "Steve Wendt" Subject: Re: Drive letters On Sat, 04 Jan 2003 04:32:27 -0500, Henry Sobotka wrote: >Nonetheless, I think a UNIX-OS/2 system that maps drive letters to their >UNIX-world /dev/ equivalent would be the way to go as opposed to >arbitrary or user-defined naming. Drive letters represent real locations >on hardware that UNIX-OS/2 can and should respect For instance, if John I agree with everything you said, although I wonder what is involved. If there were some device driver that maps drive letters to /dev/* equivalents, how far is TVFS from being what is needed? A port of the standard mount utilities would seem to be sufficient with such a mapping. If the mounted / then corresponds to some pseudo drive letter (which I think is how TVFS works), then I don't think you would even need a shell that understands this, especially if file access is automatically translated to this pseudo drive letter (which I think is part of the approach Holger has discussed here previously). Users then just have to be aware that anything they want accessible to UnixOS2 just needs to be mounted... perhaps there could even be some install script that spits out a "best-guess" fstab file, as is usually done in Linux installs. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 48 ==========================** Date: Sat, 04 Jan 2003 20:19:54 -0800 (PST) From: "Steve Wendt" Subject: Re: Drive letters On Sat, 04 Jan 2003 04:32:27 -0500, Henry Sobotka wrote: >Nonetheless, I think a UNIX-OS/2 system that maps drive letters to their >UNIX-world /dev/ equivalent would be the way to go as opposed to >arbitrary or user-defined naming. Drive letters represent real locations >on hardware that UNIX-OS/2 can and should respect For instance, if John I agree with everything you said, although I wonder what is involved. If there were some device driver that maps drive letters to /dev/* equivalents, how far is TVFS from being what is needed? A port of the standard mount utilities would seem to be sufficient with such a mapping. If the mounted / then corresponds to some pseudo drive letter (which I think is how TVFS works), then I don't think you would even need a shell that understands this, especially if file access is automatically translated to this pseudo drive letter (which I think is part of the approach Holger has discussed here previously). Users then just have to be aware that anything they want accessible to UnixOS2 just needs to be mounted... perhaps there could even be some install script that spits out a "best-guess" fstab file, as is usually done in Linux installs. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 49 ==========================** Date: Sat, 04 Jan 2003 20:30:57 -0800 (PST) From: "Steve Wendt" Subject: Re: gcc and Mozilla On Sat, 4 Jan 2003 21:34:28 +0000, John Poltorak wrote: >Do have a list of the pre-requisite list of tools (including versions) >required for building Mozilla? There was a list on the Mozilla OS/2 page, although it may not be current now: http://www.mozilla.org/ports/os2/ Javier Pedemonte is the IBM'er that has been working on this, and he has a bug in Bugzilla for it, which I think may have had an updated list. If you can't find it, I can search for it again. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 50 ==========================** Date: Sat, 04 Jan 2003 20:30:57 -0800 (PST) From: "Steve Wendt" Subject: Re: gcc and Mozilla On Sat, 4 Jan 2003 21:34:28 +0000, John Poltorak wrote: >Do have a list of the pre-requisite list of tools (including versions) >required for building Mozilla? There was a list on the Mozilla OS/2 page, although it may not be current now: http://www.mozilla.org/ports/os2/ Javier Pedemonte is the IBM'er that has been working on this, and he has a bug in Bugzilla for it, which I think may have had an updated list. If you can't find it, I can search for it again. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 51 ==========================** Date: Sat, 4 Jan 2003 21:34:28 +0000 From: John Poltorak Subject: Re: gcc and Mozilla On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > Basically everyone is trying to figure out why gcc builds fail on OS/2 > where they are common-place on other platforms. Which of course quickly > brings to mind the work this group is doing to not only standardise > tools, but to have the most up-to-date ones available (and working). Do have a list of the pre-requisite list of tools (including versions) required for building Mozilla? We've come a long way in the last year thanks to some excellent work by a number of people. We've also managed to pinpoint a number of commonly occuring problem areas, which I would suggest are generally due to the shell, Make or headers. Since using the latest release of PDKSH most shell errors have disappeared AFAICT. Make v3.79.1 is pretty good too. I'd like to see what difference the adoption of the Posix/2 headers makes... In quite a number of arears, we are up to date. Autoconf, Automake, Perl, PDKSH are all on par with Unix versions. sed/grep/awk are close, as is Make. The GNU utils are a little out of date, but I'm not sure how much that really matters. The most likely problem is likely to be gcc. What is the earliest version we can get away with using? > Does anyone consider this a suitable "real-world" goal to help > prioritise what tools the UnixOS2 project works on next? I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is like herding cats :-)... Having said, no one is saying what the specific problems are in building Mozilla, and you can't prioritise building tools without identifying the shortcomings in the current toolset. > > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- -- John **= Email 52 ==========================** Date: Sat, 4 Jan 2003 21:34:28 +0000 From: John Poltorak Subject: Re: gcc and Mozilla On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > Basically everyone is trying to figure out why gcc builds fail on OS/2 > where they are common-place on other platforms. Which of course quickly > brings to mind the work this group is doing to not only standardise > tools, but to have the most up-to-date ones available (and working). Do have a list of the pre-requisite list of tools (including versions) required for building Mozilla? We've come a long way in the last year thanks to some excellent work by a number of people. We've also managed to pinpoint a number of commonly occuring problem areas, which I would suggest are generally due to the shell, Make or headers. Since using the latest release of PDKSH most shell errors have disappeared AFAICT. Make v3.79.1 is pretty good too. I'd like to see what difference the adoption of the Posix/2 headers makes... In quite a number of arears, we are up to date. Autoconf, Automake, Perl, PDKSH are all on par with Unix versions. sed/grep/awk are close, as is Make. The GNU utils are a little out of date, but I'm not sure how much that really matters. The most likely problem is likely to be gcc. What is the earliest version we can get away with using? > Does anyone consider this a suitable "real-world" goal to help > prioritise what tools the UnixOS2 project works on next? I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is like herding cats :-)... Having said, no one is saying what the specific problems are in building Mozilla, and you can't prioritise building tools without identifying the shortcomings in the current toolset. > > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- -- John **= Email 53 ==========================** Date: Sat, 04 Jan 2003 22:02:13 -0500 From: Ted Sikora Subject: header problems? Tried building Zope with GCC 3.0.3 with the posix2 includes. Failed miserably on the first module with: error L2029 : unresolved external ---------------------------------- With the posix2 headers removed it builds them all except the last one with: writing build/temp.os2emx-2.2/initgrou.def d:/emx/bin.new/gcc.exe -Zomf -Zmt -Zcrtdll -Zdll -s build/temp.os2emx-2.2/initgr oups.obj build/temp.os2emx-2.2/initgrou.def -LD:/APPS/python222/Config -lpython2 2 -lgcc -o initgrou.pyd build\temp.os2emx-2.2\initgroups.obj(initgroups.obj) : error L2029: 'initgroups' : unresolved external ------------------------------------------------- There was 1 error detected command 'gcc' failed with exit status 1 error: command 'gcc' failed with exit status 1 Traceback (most recent call last): File "wo_pcgi.py", line 45, in ? if __name__=='__main__': main(sys.argv[0]) File "wo_pcgi.py", line 33, in main import build_extensions File "D:/apps/zope/inst/build_extensions.py", line 24, in ? do('%s setup.py build_ext -i' % sys.executable) File "D:/apps/zope/inst/do.py", line 32, in do if i and picky: raise SystemError, i SystemError: 1 This leads me to believe we have header problems with gcc The headers 'initgroups' calls are: #include #include #include I had the same problem building shadow-4.0.3. When the missing headers were added it stopped only at a section with a grp issue. Zope builds perfectly with emx 2.8.1 -- Ted Sikora tsikora at ntplx.net **= Email 54 ==========================** Date: Sat, 04 Jan 2003 22:02:13 -0500 From: Ted Sikora Subject: header problems? Tried building Zope with GCC 3.0.3 with the posix2 includes. Failed miserably on the first module with: error L2029 : unresolved external ---------------------------------- With the posix2 headers removed it builds them all except the last one with: writing build/temp.os2emx-2.2/initgrou.def d:/emx/bin.new/gcc.exe -Zomf -Zmt -Zcrtdll -Zdll -s build/temp.os2emx-2.2/initgr oups.obj build/temp.os2emx-2.2/initgrou.def -LD:/APPS/python222/Config -lpython2 2 -lgcc -o initgrou.pyd build\temp.os2emx-2.2\initgroups.obj(initgroups.obj) : error L2029: 'initgroups' : unresolved external ------------------------------------------------- There was 1 error detected command 'gcc' failed with exit status 1 error: command 'gcc' failed with exit status 1 Traceback (most recent call last): File "wo_pcgi.py", line 45, in ? if __name__=='__main__': main(sys.argv[0]) File "wo_pcgi.py", line 33, in main import build_extensions File "D:/apps/zope/inst/build_extensions.py", line 24, in ? do('%s setup.py build_ext -i' % sys.executable) File "D:/apps/zope/inst/do.py", line 32, in do if i and picky: raise SystemError, i SystemError: 1 This leads me to believe we have header problems with gcc The headers 'initgroups' calls are: #include #include #include I had the same problem building shadow-4.0.3. When the missing headers were added it stopped only at a section with a grp issue. Zope builds perfectly with emx 2.8.1 -- Ted Sikora tsikora at ntplx.net **= Email 55 ==========================** Date: Sat, 4 Jan 2003 22:10:57 +1100 (AED) From: Nicholas Sheppard Subject: Re: INETD & BOOTPD On Thu, 2 Jan 2003, John Poltorak wrote: > Ifanyone is familiar with how INETD launches other servers could you check > BOOTPD for OS/2:- ? > > http://hobbes.nmsu.edu/pub/os2/util/network/tcpip/bootpd.zip > > This is described as a 'quick and dirty' port and no mention is made about > its ability to run from INETD, and if it can, how it can pick up a socket. It can't be run from inetd. The `standalone' variable is set to TRUE at line 266 of bootpd.c and all the code that would change it to anything else is #ifdef'd out for EMX. If `standalone' is true, it creates its own socket after the test on line 466. Nicholas S. |\ Location: Wollongong, Australia | The optimist thinks this is the best of |\ E-mail: nps at zeta.org.au | all possible worlds, and the pessimist | WWW: http://www.zeta.org.au/~nps | knows it is. | ---> Cynicism & Negativity | - Robert Oppenheimer **= Email 56 ==========================** Date: Sat, 4 Jan 2003 22:10:57 +1100 (AED) From: Nicholas Sheppard Subject: Re: INETD & BOOTPD On Thu, 2 Jan 2003, John Poltorak wrote: > Ifanyone is familiar with how INETD launches other servers could you check > BOOTPD for OS/2:- ? > > http://hobbes.nmsu.edu/pub/os2/util/network/tcpip/bootpd.zip > > This is described as a 'quick and dirty' port and no mention is made about > its ability to run from INETD, and if it can, how it can pick up a socket. It can't be run from inetd. The `standalone' variable is set to TRUE at line 266 of bootpd.c and all the code that would change it to anything else is #ifdef'd out for EMX. If `standalone' is true, it creates its own socket after the test on line 466. Nicholas S. |\ Location: Wollongong, Australia | The optimist thinks this is the best of |\ E-mail: nps at zeta.org.au | all possible worlds, and the pessimist | WWW: http://www.zeta.org.au/~nps | knows it is. | ---> Cynicism & Negativity | - Robert Oppenheimer **= Email 57 ==========================** Date: Sat, 04 Jan 2003 22:36:22 -0800 From: "Steven Levine" Subject: Re: Can anyone explain this? In , on 01/04/03 at 02:55 PM, Stefan Neis said: >> bootps 67/tcp sbootp #Bootstrap Protocol Server >> bootps 67/udp dhcps sbootp #Bootstrap Protocol Server >which I supposedly is telling me that I should be able to use both names, >but maybe getservbyname can only handle the first one and not several >aliases or something similar. Or things are handled differently on other >systems. The application has to handle this. IIRC, after the getservbyname() call the app must use getservent() to step through remaining /etc/services entries and locate the alternate services. Steven -- --------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.35 #10183 Warp4/FP15/14.085_W4 www.scoug.com irc.webbnet.org #scoug (Wed 7pm PST) --------------------------------------------------------------------- **= Email 58 ==========================** Date: Sat, 04 Jan 2003 22:36:22 -0800 From: "Steven Levine" Subject: Re: Can anyone explain this? In , on 01/04/03 at 02:55 PM, Stefan Neis said: >> bootps 67/tcp sbootp #Bootstrap Protocol Server >> bootps 67/udp dhcps sbootp #Bootstrap Protocol Server >which I supposedly is telling me that I should be able to use both names, >but maybe getservbyname can only handle the first one and not several >aliases or something similar. Or things are handled differently on other >systems. The application has to handle this. IIRC, after the getservbyname() call the app must use getservent() to step through remaining /etc/services entries and locate the alternate services. Steven -- --------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.35 #10183 Warp4/FP15/14.085_W4 www.scoug.com irc.webbnet.org #scoug (Wed 7pm PST) ---------------------------------------------------------------------