From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 5 Feb 2002 04:14:25 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 126 ************************************************** Monday 04 February 2002 Number 126 ************************************************** Subjects for today 1 Re: Perl equivalent of 'sh -x' : Henry Sobotka 2 Re: Tar : Dave Saville" 3 Re: Tar : John Poltorak 4 Re: Perl equivalent of 'sh -x' : John Poltorak 5 Re: Perl equivalent of 'sh -x' : csaba.raduly at sophos.com 6 Re: Tar : Dave Saville" 7 Re: Perl equivalent of 'sh -x' : Henry Sobotka 8 Re: Perl equivalent of 'sh -x' : John Poltorak 9 Re: Perl equivalent of 'sh -x' : csaba.raduly at sophos.com 10 Perl debugging : John Poltorak 11 Re: GLIBC : Charles R. Hunter" 12 Re: GLIBC : John Poltorak 13 Re: GLIBC : John Poltorak 14 Re: GLIBC : John Drabik" 15 Re: GLIBC : John Merryweather Cooper 16 Re: GLIBC : Holger Veit 17 Re: installpkg bin.zip ? : frank schmittroth" **= Email 1 ==========================** Date: Tue, 05 Feb 2002 08:07:38 -0500 From: Henry Sobotka Subject: Re: Perl equivalent of 'sh -x' csaba.raduly at sophos.com wrote: > > Autom4te needs to be investigated. > It should be able to handle /dev/null > Try doing the "#!perl -w -d" trick on autom4te, and see > what it does with the argument to --melt (/dev/null) --melt means don't use frozen files. My reading of the code is that the /dev/null is not an arg to --melt, but serves to keep the piped-back output offscreen. I also thought that /dev/null is a handle opened and closed by the system, not the user. h~ **= Email 2 ==========================** Date: Tue, 05 Feb 2002 08:38:02 +0000 (GMT) From: "Dave Saville" Subject: Re: Tar On Mon, 4 Feb 2002 19:26:14 +0000, John Poltorak wrote: >On Mon, Feb 04, 2002 at 01:06:28PM -0500, Henry Sobotka wrote: >> John Poltorak wrote: >> > >> > > >> port.h:172: os2eattr.h: No such file or directory >> > > >> port.h:173: acl32.h: No such file or directory >> > >> > Could these files be part of LAN Server or HPFS386? >> >> Here I have both those headers in tar/lib. > >Yes, you're right. I guess it's a problem with INCLUDE in makefile.os2. > Found it - the include says -I ../libx - the dir is lib :-) However fixing that throws all sorts of nasties. Will try and plough through them and see how far I can get. -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 3 ==========================** Date: Tue, 5 Feb 2002 09:17:48 +0000 From: John Poltorak Subject: Re: Tar On Tue, Feb 05, 2002 at 08:38:02AM +0000, Dave Saville wrote: > On Mon, 4 Feb 2002 19:26:14 +0000, John Poltorak wrote: > > >On Mon, Feb 04, 2002 at 01:06:28PM -0500, Henry Sobotka wrote: > >> John Poltorak wrote: > >> > > >> > > >> port.h:172: os2eattr.h: No such file or directory > >> > > >> port.h:173: acl32.h: No such file or directory > >> > > >> > Could these files be part of LAN Server or HPFS386? > >> > >> Here I have both those headers in tar/lib. > > > >Yes, you're right. I guess it's a problem with INCLUDE in makefile.os2. > > > > Found it - the include says -I ../libx - the dir is lib :-) > > However fixing that throws all sorts of nasties. Will try and plough > through them and see how far I can get. I don't expect that will be too far as things stand at the moment. It appears that a number files from the ../tape directory are required but that doesn't appear in any version of GTAR I've seen. Wonder if anyone has any contact details for AK... > -- > Regards > > Dave Saville > Please note new email address dave.saville at ntlworld.com > -- John **= Email 4 ==========================** Date: Tue, 5 Feb 2002 10:04:48 +0000 From: John Poltorak Subject: Re: Perl equivalent of 'sh -x' On Mon, Feb 04, 2002 at 05:18:33PM -0500, Henry Sobotka wrote: > Autom4te::XFile "provides dying version of the methods open, new, and > close" so that the usual error handling (e.g. || die "Can't open > $filename: $!") is built-in. > > The call to new: > > my $macros = new Autom4te::XFile ("$autoconf" > . " --trace AU_DEFUN:'AU:\$f:\$1'" > . " --trace define:'AC:\$f:\$1'" > . " --melt /dev/null |"); > > also automatically opens the file. Since what gets opened is $autoconf, > and the "/dev/null |" trailer just pipes the output into a blackhole, I > really don't understand why it's trying to close the latter. But then > Fox Muldaur and Stephen Hawking know far more about XFiles and > blackholes than I do. OK, I'll cc: them and see what they come up with :-)... BTW when invoking the Perl debugger and single stepping through the code I managed to get this trace before the error:- DB<2> File::Glob::csh_glob(c:/usr/lib/perl/lib/5.6.0/os2/File/Glob.pm:164): 164: delete $entries{$cxix}; DB<2> File::Glob::csh_glob(c:/usr/lib/perl/lib/5.6.0/os2/File/Glob.pm:165): 165: return undef; DB<2> Autom4te::General::CODE(0x26e548)(c:/usr/local/share/autoconf/Autom4te/General.pm:110): 110: rmdir $tmp 111: or carp ("$me: cannot remove $tmp: $!\n"), _exit (1); DB<2> Autom4te::General::CODE(0x26e548)(c:/usr/local/share/autoconf/Autom4te/General.pm:116): 116: close STDOUT 117: or (carp "$me: closing standard output: $!\n"), _exit (1); DB<2> Autom4te::General::CODE(0x26e548)(c:/usr/local/share/autoconf/Autom4te/General.pm:119): 119: _exit ($exit_status); DB<2> autoupdate.: cannot close autom4te --language=autoconf --include=c:/usr/local/share/autoconf --trace AU_DEFUN:'AU:$f:$1' --trace define:'AC:$f:$1' --melt /dev/null |: at c:/usr/local/bin/autoupdate. line 185 Can't say it means anything to me. > As a quick-and-dirty workaround, you might try changing line 185 to > > close($macros); I'll give that a try. > or even commenting it out and taking up the matter with the autoconf > maintainers. It has been reported, although it may turn out to be a Perl OS/2 porting issue. I've tried both 5.6.0 and 5.6.1 and results are consistant. If anyone has Linux installed, could you try running autoupdate from Autoconf v2.52g on Flex 2.5.4a and see if configure.in gets updated? Flex is available here:- ftp://ftp.mirror.ac.uk/sites/ftp.gnu.org/pub/gnu/non-gnu/flex/flex-2.5.4a.tar.gz > h~ -- John **= Email 5 ==========================** Date: Tue, 5 Feb 2002 10:14:08 +0000 From: csaba.raduly at sophos.com Subject: Re: Perl equivalent of 'sh -x' On 04/02/2002 22:18:33 Henry Sobotka wrote: >Autom4te::XFile "provides dying version of the methods open, new, and >close" so that the usual error handling (e.g. || die "Can't open >$filename: $!") is built-in. > >The call to new: > >my $macros = new Autom4te::XFile ("$autoconf" > . " --trace AU_DEFUN:'AU:\$f:\$1'" > . " --trace define:'AC:\$f:\$1'" > . " --melt /dev/null |"); > >also automatically opens the file. Since what gets opened is $autoconf, >and the "/dev/null |" trailer just pipes the output into a blackhole, Not a black hole. It's using the "magical" Perl open function. open( HANDLE, "ls -l |") opens a pipe to the output of ls. You can read from the pipe as from a normal filehandle; in this case while ($_ = $macros->getline) { # ... } >I really don't understand why it's trying to close the latter. Since there was a handle opened, it stands to reason that it needs to be closed. In the documentation for close (perldoc -f close) : If the file handle came from a piped open close will additionally return false if one of the other system calls involved fails or if the program exits with non-zero status. (If the only problem was that the program exited non-zero $! will be set to 0.) Closing a pipe also waits for the process executing on the pipe to complete, in case you want to look at the output of the pipe afterwards, and implicitly puts the exit status value of that command into $?. The "cannot close automake ...." error message means that something went wrong with the subprocess. This includes a non-zero return value from the subprocess (quite likely, as there was an error message from autom4te). This error code is only returned when the pipe is close()-d. See the documentation for close and "perldoc perlipc" (On OS/2: view perl perlipc). > >As a quick-and-dirty workaround, you might try changing line 185 to > >close($macros); > That's unlikely to work as expected. Apparently Autom4te::XFile doesn't implement handle semantics, so close on $macros is likely not to work. You need to call the close method on $macros, a.k.a. $macros->close. (there are objects which *do* implement handle semantics, see e.g. the IO::File package. If you create an IO::File object you can then pass this object to any function that expects a handle, including close. See: 'perldoc IO::File' My conclusion: Autom4te returns an error because of /dev/null. Autoupdate notices that, and treats it as fatal (it's got little choice; autom4te didn't run successfully). That's correct behaviour from autoupdate. Autom4te needs to be investigated. It should be able to handle /dev/null Try doing the "#!perl -w -d" trick on autom4te, and see what it does with the argument to --melt (/dev/null) HTH, -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 6 ==========================** Date: Tue, 05 Feb 2002 10:50:23 +0000 (GMT) From: "Dave Saville" Subject: Re: Tar On Tue, 5 Feb 2002 09:17:48 +0000, John Poltorak wrote: >On Tue, Feb 05, 2002 at 08:38:02AM +0000, Dave Saville wrote: >> On Mon, 4 Feb 2002 19:26:14 +0000, John Poltorak wrote: >> >> >On Mon, Feb 04, 2002 at 01:06:28PM -0500, Henry Sobotka wrote: >> >> John Poltorak wrote: >> >> > >> >> > > >> port.h:172: os2eattr.h: No such file or directory >> >> > > >> port.h:173: acl32.h: No such file or directory >> >> > >> >> > Could these files be part of LAN Server or HPFS386? >> >> >> >> Here I have both those headers in tar/lib. >> > >> >Yes, you're right. I guess it's a problem with INCLUDE in makefile.os2. >> > >> >> Found it - the include says -I ../libx - the dir is lib :-) >> >> However fixing that throws all sorts of nasties. Will try and plough >> through them and see how far I can get. > >I don't expect that will be too far as things stand at the moment. It >appears that a number files from the ../tape directory are required but >that doesn't appear in any version of GTAR I've seen. > >Wonder if anyone has any contact details for AK... There is another set of initials in the src - edvkai ?? Fix 1) change the include in makefile os/2 to use lib not libx 2) Added following before last #endif in lib acl32.h } #if defined (__cplusplus) } #endif (Was complaining about too many open { ) This gets it as far as whingeing about EMX\INCLUDE\sys/ead.h Going by comments in the code ak supplied a lot of his own code as he had grief with the emx versions - but it does not appear to be supplied. Moving swiftly on :-) I tried a make in the lib dir dmake -f makefile all CC="gcc -Zmts -O2" gcc -Zmts -O2 -I. -DOS2=2 -c os2ea_ld.c -o os2ea_ld.obj In file included from D:\APPS\EMX\INCLUDE\os2.h:18, from os2ea_ld.c:88: D:\APPS\EMX\INCLUDE\os2tk.h:8: os2def.h: No such file or directory D:\APPS\EMX\INCLUDE\os2tk.h:117: bse.h: No such file or directory D:\APPS\EMX\INCLUDE\os2tk.h:140: pm.h: No such file or directory dmake: Error code 1, while making 'os2ea_ld.obj' dmake: Error code 255, while making 'release' Adding a -I for the tookit h files I get even more errors make -f makefile all CC="gcc -Zmts -O2" make[1]: Entering directory `/home/DB/Programming/C/tar/TAR/lib' gcc -Zmts -O2 -I. -DOS2=2 -I e:\toolkit\os2tk45\h -c os2ea_ld.c -o os2ea_ld.obj In file included from e:\toolkit\os2tk45\h\os2.h:33, from os2ea_ld.c:88: e:\toolkit\os2tk45\h\os2def.h:99: parse error before `PUCHAR16' e:\toolkit\os2tk45\h\os2def.h:99: warning: data definition has no type or storag e class e:\toolkit\os2tk45\h\os2def.h:100: parse error before `PCHAR16' e:\toolkit\os2tk45\h\os2def.h:100: warning: data definition has no type or stora ge class e:\toolkit\os2tk45\h\os2def.h:111: parse error before `_PFN' e:\toolkit\os2tk45\h\os2def.h:112: parse error before `*' e:\toolkit\os2tk45\h\os2def.h:112: warning: data definition has no type or stora ge class e:\toolkit\os2tk45\h\os2def.h:113: parse error before `_NPFN' e:\toolkit\os2tk45\h\os2def.h:114: parse error before `*' e:\toolkit\os2tk45\h\os2def.h:114: warning: data definition has no type or stora ge class e:\toolkit\os2tk45\h\os2def.h:138: parse error before `PVOID16' e:\toolkit\os2tk45\h\os2def.h:138: warning: data definition has no type or stora ???? -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 7 ==========================** Date: Tue, 05 Feb 2002 11:06:19 -0500 From: Henry Sobotka Subject: Re: Perl equivalent of 'sh -x' csaba.raduly at sophos.com wrote: > > I suspect /dev/null doesn't relate to screen output in this case. > When a pipe is opened, everything written to stdout ends up in the pipe I'm interpreting "/dev/null |" as a syntactic variant of "-|". Since the latter is a problem on OS/2 because it involves a fork() call, perhaps the same is true of the former. In that case, running the aout instead of OMF version of Perl might be the solution. h~ **= Email 8 ==========================** Date: Tue, 5 Feb 2002 11:17:12 +0000 From: John Poltorak Subject: Re: Perl equivalent of 'sh -x' On Tue, Feb 05, 2002 at 10:14:08AM +0000, csaba.raduly at sophos.com wrote: > Autom4te needs to be investigated. > It should be able to handle /dev/null > Try doing the "#!perl -w -d" trick on autom4te, and see > what it does with the argument to --melt (/dev/null) How do I do that then? I'm at the very early stages of using the Perl debugger and have only attempted very basic commands like b, c, n, s. > HTH, > > -- > Csaba Ráduly, Software Engineer Sophos Anti-Virus > email: csaba.raduly at sophos.com http://www.sophos.com > US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 > -- John **= Email 9 ==========================** Date: Tue, 5 Feb 2002 15:13:34 +0000 From: csaba.raduly at sophos.com Subject: Re: Perl equivalent of 'sh -x' On 05/02/2002 13:07 Henry Sobotka wrote: >csaba.raduly at sophos.com wrote: >> >> Autom4te needs to be investigated. >> It should be able to handle /dev/null >> Try doing the "#!perl -w -d" trick on autom4te, and see >> what it does with the argument to --melt (/dev/null) > >--melt means don't use frozen files. My reading of the code is that the >/dev/null is not an arg to --melt, but serves to keep the piped-back >output offscreen. > Ah, so --melt does one thing and /dev/null is another (non-option) argument! Well, duh. It makes much more sense this way, now that I think about it. In that case, the interesting bit is what happens to ARGV after the switches have been processed. I suspect /dev/null doesn't relate to screen output in this case. When a pipe is opened, everything written to stdout ends up in the pipe **= Email 10 ==========================** Date: Tue, 5 Feb 2002 16:42:43 +0000 From: John Poltorak Subject: Perl debugging Does anyone know how to set a breakpoint in a Perl module other than the current one? I know I can set:- b 97 to stop at line 97 of the current module, but I want to set the breakpoint in a different module - share/autconf/Autom4te/General.pm to be exact. I'd like to single step through the subroutine END. -- John **= Email 11 ==========================** Date: Tue, 5 Feb 2002 19:42:27 -0500 From: "Charles R. Hunter" Subject: Re: GLIBC On Wed, Feb 06, 2002 at 12:14:57AM +0100, Stefan Neis (neis at cdc.informatik.tu-darmstadt.de) wrote: > On Tue, 5 Feb 2002, John Poltorak wrote: > > > I guess the long term aim is to use GLIBC > > Please don't. It is essentially unusable in commercial context. > BSD's libc is a better choice than GNU's libc, if we aim at unifying > all the effort. GLIBC would be a good way of splitting OS/2 community > into even smaller parts... Hear hear. This is one reason why I have objected to using linux as our source code base. I don't want always be a spoil-sport, I just think we are barking up the wrong tree. Charles > > > and I would suspect that through > > the work done on Posix/2 there must be some elements which are > > already usable, > > Nope, that's based on BSD codei (due to its reasonable copyright and > cleaner code), no part of GLIBC is in there. > > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- Charles R. Hunter Director, Physics Computer Network Purdue University crh at physics.purdue.edu **= Email 12 ==========================** Date: Tue, 5 Feb 2002 20:08:51 +0000 From: John Poltorak Subject: Re: GLIBC On Sun, Feb 03, 2002 at 04:42:32PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > Actually I was only suggesting GLIBC as the name of the package which > > would contain the headers and libraries for GCC. > > But that could mislead people into thinking it was a port of glibc, and > to have a package named "glibc" with a note saying "This is not glibc" > would only make matters worse. Preferably name it after what it really > contains. I guess the long term aim is to use GLIBC and I would suspect that through the work done on Posix/2 there must be some elements which are already usable, so why not use them? > h~ -- John **= Email 13 ==========================** Date: Tue, 5 Feb 2002 20:19:07 +0000 From: John Poltorak Subject: Re: GLIBC On Mon, Feb 04, 2002 at 12:01:22AM +0100, Holger Veit wrote: > On Sun, Feb 03, 2002 at 08:33:09PM +0000, John Poltorak wrote: > > On Sun, Feb 03, 2002 at 08:13:47PM +0100, Holger Veit wrote: > > Actually I was only suggesting GLIBC as the name of the package which > > would contain the headers and libraries for GCC. I'm sure the porting of > > GLIBC would be a massive task. I'm trying to make UnixOS/2 packages > > roughly equivalent to those in SlackWare rather than inventing new > > packages and I don't see where such headers and libraries would fit in > > otherwise. > > Call it "development kit" or "unixos2-dev" or alike, but don't call > a package glibc, if there is no glibc in it. Slackware was intended > as a guideline, not as a dogma[sp?]. What precisely is GLIBC see anyway? Doesn't it include a number of standard headers which already exist in EMX? What should go in this 'development kit' ? I'm thinking of all the headers and libraries from EMX 0.9d + FIX04 , basically everything which goes into C_INCLUDE_PATH and LIBRARY_PATH. Maybe some other files would naturally fit in as well... BTW is there any issue with re-packaging part of EM's work? > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 14 ==========================** Date: Tue, 05 Feb 2002 21:19:30 -0700 (MST) From: "John Drabik" Subject: Re: GLIBC On Tue, 5 Feb 2002 19:42:27 -0500, Charles R. Hunter wrote: >On Wed, Feb 06, 2002 at 12:14:57AM +0100, Stefan Neis (neis at cdc.informatik.tu-darmstadt.de) >> > I guess the long term aim is to use GLIBC >> >> Please don't. It is essentially unusable in commercial context. HUH? Utter HOGWASH! It is being used commercially every day. Now I'm not wild about GLIBC (it's not well organized, and is very bloated if you ask me). But to say it is unusable in a commercial context is just plain lame. And just what "commercial context" is really left for OS/2 right now anyway? I love it. I use it. But it's being relegated to history. Fortunately, it's so well done that I figure I have another 3-5 years at least before I have to shut down my last OS/2 box, and maybe much more. >> BSD's libc is a better choice than GNU's libc, if we aim at unifying >> all the effort. GLIBC would be a good way of splitting OS/2 community >> into even smaller parts... I totally disagree. First, there is no requirement to hand back code under BSD - a painful lesson learned all too well when M$ took the Kerberos code, gorked it good, refused to give it back to others, and filled it with bugs, back doors, and "extensions". That's called "forking" folks - and if you want to see the community split into smaller parts, that's the way to do it. BSD is not the way to go here. >I don't want always be a spoil-sport, I just think we are >barking up the wrong tree. Why? >> Nope, that's based on BSD codei (due to its reasonable copyright and >> cleaner code), no part of GLIBC is in there. I guess it depends on your point of view. Here we are, saying we want to ride the coattails of free software (in one form or another), and adhere to standards, but we seem willing to use BSD which won't ensure a free and stable future, nor adherence to standards. With the purchase of BSD and the subsequent destruction of the code base well underway, along with a much smaller development community to start with, I don't see why we're even talking about this. As for "cleaner code", may I suggest that you try another argument - it just won't hold water. Now libc may be cleaner than glibc, I'll grant you. But to extend that to all BSD vs. Linux code is just plain crazy. Just my $0.02. John **= Email 15 ==========================** Date: Tue, 5 Feb 2002 21:27:24 -0800 From: John Merryweather Cooper Subject: Re: GLIBC On 2002.02.05 20:19 John Drabik wrote: > On Tue, 5 Feb 2002 19:42:27 -0500, Charles R. Hunter wrote: > > >On Wed, Feb 06, 2002 at 12:14:57AM +0100, Stefan Neis > (neis at cdc.informatik.tu-darmstadt.de) > >> > I guess the long term aim is to use GLIBC > >> > >> Please don't. It is essentially unusable in commercial context. > > HUH? Utter HOGWASH! It is being used commercially every day. Now > I'm not wild about GLIBC (it's not well organized, and is very > bloated if you ask me). But to say it is unusable in a commercial > context is just plain lame. And just what "commercial context" is > really left for OS/2 right now anyway? I love it. I use it. But > it's being relegated to history. Fortunately, it's so well done that > I figure I have another 3-5 years at least before I have to shut down > my last OS/2 box, and maybe much more. > Not hogwash. The bottom line with any GPL (as opposed to BSD) license software is: 1) anything linked to it becomes GPL; 2) anything GPL'ed cannot be sold or closed source; 3) anything GPL'ed cannot be included in whole or in part in any closed-source product; 4) anything with GPL'ed goop linked to it must be open sourced. The BSD license has none of these restrictions. The LGPL has fewer of them. Some of us make money (or would like to) off software development. GPL products make that possible only in terms of "support" services. By the number of business failures in that area, it's not a good business. :) This is besides the point though, the base library should be decided on its technical merits, and here, GLIBC has every strike against it. But the GPL is not the best (or even most important) reason to avoid GLIBC. The BSD libc has better standards conformance, better documentation, yada yada, yada yada. Plus, GLIBC is full of Linux-isms--bad programming practices that notoriously only work (or only work well) on Linux. > >> BSD's libc is a better choice than GNU's libc, if we aim at > unifying > >> all the effort. GLIBC would be a good way of splitting OS/2 > community > >> into even smaller parts... > > I totally disagree. First, there is no requirement to hand back code > under BSD - a painful lesson learned all too well when M$ took the > Kerberos code, gorked it good, refused to give it back to others, and > filled it with bugs, back doors, and "extensions". > I think this takes a naive view of what firms like M$ are willing to do to acquire software (observed the litigation re Digital Research, Borland, Apple, etc.). If BG wants it, he'll take it. I see no moral, ethical, or legal barrier BG would not sweep aside if it suited his interests. > That's called "forking" folks - and if you want to see the community > split into smaller parts, that's the way to do it. BSD is not the > way to go here. > > >I don't want always be a spoil-sport, I just think we are > >barking up the wrong tree. > > Why? > > >> Nope, that's based on BSD codei (due to its reasonable copyright > and > >> cleaner code), no part of GLIBC is in there. > > I guess it depends on your point of view. Here we are, saying we > want to ride the coattails of free software (in one form or another), > and adhere to standards, but we seem willing to use BSD which won't > ensure a free and stable future, nor adherence to standards. With > the purchase of BSD and the subsequent destruction of the code base > well underway, along with a much smaller development community to > start with, I don't see why we're even talking about this. > Pure garbage. BSD isn't being "purchased" by anyone. Anyone is free to take the code and, so long as they preserve the original BSD copyrights modify it and resell it. But that doesn't make the "closed" versions the better product. Which IPv6 stack do you think actually works? WinDoze 2000, OS/2 Warp, or FreeBSD (all three use BSD code)? They can mangle it, but that doesn't mean they actually know what they're doing. :) > As for "cleaner code", may I suggest that you try another argument - > it just won't hold water. Now libc may be cleaner than glibc, I'll > grant you. But to extend that to all BSD vs. Linux code is just > plain crazy. > We're broadening the argument here. Some Linux code is written very well, and some is written very poorly. GLIBC falls squarely in the latter camp. > Just my $0.02. > > John > > > -- _ | |V| / ' || MacroHard -- \ \_| | | \_, || the perfection of form over | ----------------------------------|| substance, marketing over | Web: http://www.borgsdemons.com || performance, and greed over | AIM: johnmcooper || design . . . | =====================================================================/ Public Key: http://www.borgsdemons.com/Personal/pgpkey.asc | =====================================================================\ **= Email 16 ==========================** Date: Tue, 5 Feb 2002 21:43:09 +0100 From: Holger Veit Subject: Re: GLIBC On Tue, Feb 05, 2002 at 08:19:07PM +0000, John Poltorak wrote: > On Mon, Feb 04, 2002 at 12:01:22AM +0100, Holger Veit wrote: [...] > > Call it "development kit" or "unixos2-dev" or alike, but don't call > > a package glibc, if there is no glibc in it. Slackware was intended > > as a guideline, not as a dogma[sp?]. > > What precisely is GLIBC see anyway? GLIBC is a software package (actually, header files, libraries and documentation) which claims to provide everything to write programs that comply with certain Unix standards, ANSI, POSIX, C98, whatever. While it is internally an ugly hack (partly due to conflicting standards, partly due to bad programming style, and partly due to GNU's attempt to provide universal Swiss knives), it fullfills this purpose more or less. EMX in contrast doesn't offer all the features; it is a similar environment, admittedly, but incomplete. It is not GLIBC. So don't call it GLIBC. The package does not contain what its name claims to offer. > Doesn't it include a number of standard headers which already exist in > EMX? > > What should go in this 'development kit' ? > > I'm thinking of all the headers and libraries from EMX 0.9d + FIX04 , > basically everything which goes into C_INCLUDE_PATH and LIBRARY_PATH. This is the development kit, right. All the libraries, headers and doc files, except the compilers. > Maybe some other files would naturally fit in as well... > > BTW is there any issue with re-packaging part of EM's work? You may not call this EMXRT/EMXDEV etc. any longer, IIRC. But as long as it contains the original, unmodified libraries, you may still name the DLLs EMX.DLL/EMXLIBCM/S.DLL... I don't see other problems with repackaging - you can still add some README file pointing to the original distribution, if someone wants to compare them. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 17 ==========================** Date: Tue, 05 Feb 2002 21:55:04 -0800 (PST) From: "frank schmittroth" Subject: Re: installpkg bin.zip ? On Mon, 4 Feb 2002 18:37:21 +0100, Michael Zolk wrote: >On Thu, Jan 31, 2002 at 04:14:50PM -0800, frank schmittroth wrote: >> It looked to me as if the rexx script, installpkg.cmd, had a missing "end" >> statement for a corresponding "do". I added another "end" at line 286, and >> the installation apparently created directories and unzipped various programs. > >The -s option means that no files should be copied to disc and no directories >are created. I understand. I received the same error for the simulated and the real executions. >What is the outut of lspkg? Is there a file $UNIXROOT/var/log/packages/bin ? > >Michael lspkg just lists ux2_base which is the only file in the $UNIXROOT/var/log/packages directory. I spent some time understanding your script a little bit better while I was away from my computer. Looks like it should be easy to find out why a bin file is not written in in the .../packages directory. I'll look at that tomorrow. Maybe I just got a corrupted installpkg.cmd file? Frank. ----------------------- Frank Schmittroth franks at owt.com