From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 18 Feb 2002 04:15:40 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 139 ************************************************** Sunday 17 February 2002 Number 139 ************************************************** Subjects for today 1 Re: Newbie Q re gcc 3.0.2 : Anders Jarnberg" 2 Re: Newbie Q re gcc 3.0.2 : John Poltorak 3 Re: ** Apache module and 'inet_aton' error : csaba.raduly at sophos.com 4 total.cmd : John Poltorak 5 emx\lib\*.obj ? : John Poltorak 6 Re: BZIP2 v1.0.2 : Mentore Siesto 7 Re: LIBEMX suggestion : Henry Sobotka 8 Re: make 3.79.1 : John Poltorak 9 Re: emx\lib\*.obj ? : Holger Veit 10 Re: ** Apache module and 'inet_aton' error : Lyn St George" 11 Re: ** Apache module and 'inet_aton' error : csaba.raduly at sophos.com 12 Re: LIBEMX suggestion : Henry Sobotka 13 LIBEMX suggestion : John Poltorak 14 Re: ** Apache module and 'inet_aton' error : Lyn St George" 15 Re: LIBEMX suggestion : Lyn St George" 16 Re: BZIP2 v1.0.2 : Jeff Robinson 17 Re: ** Apache module and 'inet_aton' error : csaba.raduly at sophos.com 18 Re: LIBEMX suggestion : John Poltorak 19 LESS v370 : John Poltorak 20 Re: LIBEMX suggestion : Henry Sobotka 21 Re: LIBEMX suggestion : John Poltorak 22 Re: LIBEMX suggestion : Tobias Ernst 23 Re: LIBEMX suggestion : John Poltorak 24 Sleepycat Software licence : John Poltorak 25 gcc v3.0.3 ? : John Poltorak 26 Re: LIBEMX suggestion : Lyn St George" 27 Re: gcc v3.0.3 ? : Adrian Gschwend" 28 OSFree... : Adrian Gschwend" **= Email 1 ==========================** Date: Mon, 18 Feb 2002 08:13:25 +0100 (CET) From: "Anders Jarnberg" Subject: Re: Newbie Q re gcc 3.0.2 On Sun, 17 Feb 2002 14:55:47 +0000, John Poltorak wrote: >> Abnormal program termination >> core dumped >It works OK here. >Have you tried something compiling something like 'hello, world' ? Yep, still dumps core. >Sounds like something wrong in the environment. Probably, but I'm having trouble finding it. Did I mention I'm running on eCS 1.0 ? -- Anders Jarnberg in Stockholm, Sweden running eComStation & Mandrake **= Email 2 ==========================** Date: Mon, 18 Feb 2002 09:06:03 +0000 From: John Poltorak Subject: Re: Newbie Q re gcc 3.0.2 On Mon, Feb 18, 2002 at 08:13:25AM +0100, Anders Jarnberg wrote: > On Sun, 17 Feb 2002 14:55:47 +0000, John Poltorak wrote: > >> Abnormal program termination > >> core dumped > >It works OK here. > >Have you tried something compiling something like 'hello, world' ? > > Yep, still dumps core. Does v2.8.1 work OK? > >Sounds like something wrong in the environment. > > Probably, but I'm having trouble finding it. Did I mention I'm > running on eCS 1.0 ? I can't see how this would be a factor. > -- > Anders Jarnberg > in Stockholm, Sweden > running eComStation & Mandrake -- John **= Email 3 ==========================** Date: Mon, 18 Feb 2002 09:53:31 +0000 From: csaba.raduly at sophos.com Subject: Re: ** Apache module and 'inet_aton' error On 17/02/2002 11:47:30 owner-os2-unix wrote: >Hi all - I wonder if I could beg for a little help on this problem. > >I'm trying to build mod_interchange into Apache 1.3.22 (this allows the >Interchange >perl daemon to connect directly to Apache without a cgi). I've fixed the first >couple of errors - but this _inet_aton error has got me stumped. > >I've added: Not that inet_aton is not a preprocessor definition (macro), so defined(inet_aton) will _ALWAYS_ be false. There's no good way to >#if !defined(inet_aton) >typedef int(inet_aton(const char *cp, struct in_addr * addr)); >#endif You don't want a typedef. inet_aton is a function. Change the typedef line to this one: int inet_aton(const char *cp, struct in_addr * addr); The more correct way is to find the EMX header which declares inet_aton, and #include it. Alas, I seem to remember that EMX doesn't supply inet_aton, only inet_addr. (inet_aton is a newer function, designed to remove some limitations of inet_addr.) [snip] >Inet_aton shows up in only 2 places: >------X---- >inet_sock = >(struct sockaddr_in *)ap_pcalloc( p, sizeof (struct sockaddr_in)); >inet_sock->sin_family = AF_INET; >inet_aton( IC_DEFAULT_ADDR, &inet_sock->sin_addr ); Replace the preceding line (comment out the original!) with: inet_sock->sin_addr = inet_addr( IC_DEFAULT_ADDR ); >inet_sock->sin_port = htons( IC_DEFAULT_PORT ); >-------X-------- > >and: > >--------X----- >if ( ! inet_aton( hostname, &inet_sock->sin_addr ) ) Replace the preceding line (comment out the original!) with: if( (inet_sock->sin_addr = inet_aton( hostname ))==INADDR_NONE ) >{ >/* Address must be a host */ >struct hostent * host; >host = ap_pgethostbyname( parms->temp_pool, hostname ); >if ( ! host ) >return "invalid host specification"; > >memcpy(&inet_sock->sin_addr, host->h_addr, >sizeof(inet_sock->sin_addr) ); >} >-------------X----------- Or you could try putting this at the top of the source file: int inet_aton(const char *cp, struct in_addr * addr) { return (*addr = inet_addr(cp)) != INADDR_NONE; } 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 4 ==========================** Date: Mon, 18 Feb 2002 10:55:48 +0000 From: John Poltorak Subject: total.cmd I've written this simple AWK script called total.cmd which totals up the values in a file:- --------------------------------- extproc awk -f END { print sum } { sum += $1 } --------------------------------- It works, but also prints out each line, so for the file values, \>cat values 4.00 4.00 4.20 16.00 4.99 16.00 8.50 4.99 10.50 0.01 3.20 0.01 I get:- \>cat values | total 4.00 4.00 4.20 16.00 4.99 16.00 8.50 4.99 10.50 0.01 3.20 0.01 76.4 I don't see why every line is getting printed. How do I surpress it? -- John **= Email 5 ==========================** Date: Mon, 18 Feb 2002 12:09:54 +0000 From: John Poltorak Subject: emx\lib\*.obj ? Why do we have .o and .obj files such as crt0.obj in emx\lib ? -- John **= Email 6 ==========================** Date: Mon, 18 Feb 2002 12:29:15 +0100 (CET) From: Mentore Siesto Subject: Re: BZIP2 v1.0.2 On Sat, 16 Feb 2002, Steve Wendt wrote: SW >On Sat, 16 Feb 2002 16:12:09 +0000, John Poltorak wrote: SW > SW >>It is a fairly new compression program and format which is more efficient SW >>than GZIP. Many Unix programs are becoming bundled as tar.bz2 archives. SW > SW >Used by WarpIn as well, if I remember correctly. IIRC, WarpIN uses a ZIP modified format, with other data. -- Mentore Siesto Team OS/2 Italia (http://www.teamos2.it) Home page: http://www.geocities.com/mentoruccio/ **= Email 7 ==========================** Date: Mon, 18 Feb 2002 13:23:40 -0500 From: Henry Sobotka Subject: Re: LIBEMX suggestion John Poltorak wrote: > > Can anyone think of any reason for not using your version? (eg backward > compatibility, etc...) Assuming it's the Sleepycat version, it has its own license that should be checked first. Also, IIRC its backward compatibility is a build option, so make sure it's enabled. h~ **= Email 8 ==========================** Date: Mon, 18 Feb 2002 13:28:41 +0000 From: John Poltorak Subject: Re: make 3.79.1 On Sat, Feb 16, 2002 at 11:00:11PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Sat, Feb 16, 2002 at 09:00:31PM +0100, Andreas Buening wrote: > > [make] > > > sh: too many files open in shell > > make[2]: *** [install-binSCRIPTS] Error 1 > > > > Maybe this is an EMX file handles problem. I'll reset EMXOPT and try > > again, but I haven't had this problem before with other builds. > > Hmm, I'm using -h256 in EMXOPT. This is definitely enough, but > I wonder why sh reports that error. Someone suggested using:- SET SHELLHANDLESINC=40 I don't know if this is documented anywhere... > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Redmond where the Shadows lie. -- John **= Email 9 ==========================** Date: Mon, 18 Feb 2002 13:30:35 +0100 From: Holger Veit Subject: Re: emx\lib\*.obj ? On Mon, Feb 18, 2002 at 12:09:54PM +0000, John Poltorak wrote: > > Why do we have .o and .obj files such as crt0.obj in emx\lib ? We need them. crt0.* is the startup code for a program which does some initialization, and then calls main(). This code must be outside a library, so that it gets linked into the executable in the first place. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 10 ==========================** Date: Mon, 18 Feb 2002 13:34:22 +0000 From: "Lyn St George" Subject: Re: ** Apache module and 'inet_aton' error On Mon, 18 Feb 2002 09:53:31 +0000, csaba.raduly at sophos.com wrote: > >On 17/02/2002 11:47:30 owner-os2-unix wrote: > >>Hi all - I wonder if I could beg for a little help on this problem. >> >>I'm trying to build mod_interchange into Apache 1.3.22 (this allows the >>Interchange >>perl daemon to connect directly to Apache without a cgi). I've fixed the >first >>couple of errors - but this _inet_aton error has got me stumped. >> >>I've added: > >Not that inet_aton is not a preprocessor definition (macro), >so defined(inet_aton) will _ALWAYS_ be false. There's no good way >to > >>#if !defined(inet_aton) >>typedef int(inet_aton(const char *cp, struct in_addr * addr)); >>#endif > >You don't want a typedef. inet_aton is a function. >Change the typedef line to this one: yes. You'll notice that I don't put programmer after my name - even programmer's toerag would be excessive hype:/ I used this code (from PostgreSQL), which cured the _SUN_LEN error: #if defined(SUN_LEN) #define UNIXSOCK_LEN(sun) \ (SUN_LEN(&(sun))) #else #define UNIXSOCK_LEN(sun) \ (strlen((sun).sun_path) + offsetof(struct sockaddr_un, sun_path)) #endif and when not finding anything similar for inet_aton tried to write something - that 'typedef' was the last attempt of many at that. >int inet_aton(const char *cp, struct in_addr * addr); > >The more correct way is to find the EMX header which declares inet_aton, >and #include it. Alas, I seem to remember that EMX doesn't supply >inet_aton, only inet_addr. (inet_aton is a newer function, designed >to remove some limitations of inet_addr.) > > >[snip] >>Inet_aton shows up in only 2 places: >>------X---- >>inet_sock = >>(struct sockaddr_in *)ap_pcalloc( p, sizeof (struct sockaddr_in)); >>inet_sock->sin_family = AF_INET; >>inet_aton( IC_DEFAULT_ADDR, &inet_sock->sin_addr ); > >Replace the preceding line (comment out the original!) with: > >inet_sock->sin_addr = inet_addr( IC_DEFAULT_ADDR ); > >>inet_sock->sin_port = htons( IC_DEFAULT_PORT ); >>-------X-------- >> >>and: >> >>--------X----- >>if ( ! inet_aton( hostname, &inet_sock->sin_addr ) ) > > >Replace the preceding line (comment out the original!) with: > >if( (inet_sock->sin_addr = inet_aton( hostname ))==INADDR_NONE ) > >>{ >>/* Address must be a host */ >>struct hostent * host; >>host = ap_pgethostbyname( parms->temp_pool, hostname ); >>if ( ! host ) >>return "invalid host specification"; >> >>memcpy(&inet_sock->sin_addr, host->h_addr, >>sizeof(inet_sock->sin_addr) ); >>} >>-------------X----------- > > >Or you could try putting this at the top of the source file: > > >int inet_aton(const char *cp, struct in_addr * addr) >{ > return (*addr = inet_addr(cp)) != INADDR_NONE; >} I've spent half the day tinkering with variations on this, and the stuff that Stefan Neis posted. The best result I can get is by using int inet_aton(const char *cp, struct in_addr * addr) { return (*addr = inet_addr(cp)) != INADDR_NONE; } and the original inet_aton code lines. This gives just: mod_interchange.c: In function `inet_aton': mod_interchange.c:62: incompatible types in assignment which is the 'return (*add....' line above. Changing the 2 lines in the 2 functions as suggested gives similar errors in those lines. Using only:- int inet_aton(const char *cp, struct in_addr * addr); in place of that typedef line gives heaps of 'undeclared' and 'parse' errors. Using that line in conjuction with the other 2 lines replaced in the 2 functions gives the same long list of errros as without the 2 lines replaced. I've tried to tinker with the 'incompatible types' in that line: return (*addr = inet_addr(cp)) != INADDR_NONE; but to no avail so far. I've also tried #including the POSIX/2 arpa/inet.h and the same from BSD, but without success. Sorry to be such a pain, but can you see any way out of this? >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 > > Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 11 ==========================** Date: Mon, 18 Feb 2002 14:40:49 +0000 From: csaba.raduly at sophos.com Subject: Re: ** Apache module and 'inet_aton' error On 18/02/2002 13:34:22 owner-os2-unix (rather, Lyn St George) wrote: >On Mon, 18 Feb 2002 09:53:31 +0000, csaba.raduly at sophos.com wrote: > [snip trying to compile program with inet_aton] >> >>int inet_aton(const char *cp, struct in_addr * addr) >>{ >> return (*addr = inet_addr(cp)) != INADDR_NONE; >>} > >I've spent half the day tinkering with variations on this, and the >stuff that Stefan Neis posted. > >The best result I can get is by using >int inet_aton(const char *cp, struct in_addr * addr) >{ > return (*addr = inet_addr(cp)) != INADDR_NONE; >} >and the original inet_aton code lines. This gives just: >mod_interchange.c: In function `inet_aton': >mod_interchange.c:62: incompatible types in assignment >which is the 'return (*add....' line above. Surgeon general's WARNING: Using incompatible types in assignment can be dangerous to your data :-) Change the offending line to: return (addr->s_addr = inet_addr(cp)) != INADDR_NONE; > >Changing the 2 lines in the 2 functions as suggested gives similar >errors in those lines. > >Using only:- >int inet_aton(const char *cp, struct in_addr * addr); >in place of that typedef line That would've worked only if EMX had inet_aton() implemented (in which case inet_aton would've been mentioned in one of the headers) **= Email 12 ==========================** Date: Mon, 18 Feb 2002 15:25:43 -0500 From: Henry Sobotka Subject: Re: LIBEMX suggestion John Poltorak wrote: > > It is Copyright Sleepycat Software, but I've never heard of this outfit. Keith Bostic's firm. He's one of the original authors of BDB. > One thing I noticed in the archive is the presence of both db.(a,lib) and > libdb.(a,lib). We only should have one, and my preference would be libdb.*. > > Anyone (dis)agree? Problem is that'll break every makefile containing -ldb for anyone using a version of gcc that doesn't prepend 'lib'. h~ **= Email 13 ==========================** Date: Mon, 18 Feb 2002 15:34:06 +0000 From: John Poltorak Subject: LIBEMX suggestion I'm hoping to put together a LIBEMX package based on the contents of the INCLUDE and LIB directories of EMX/GCC with a few minor changes, which consist of:- * conversion to long filenames using long.cmd * creation of .lib files via omflibs * inclusion of IZ's version of db.a (for building Perl) * removal of the following files:- include/longshrt.ls* include/bsd/* include/curses.h include/termcap.h include/*.sed include/*.cmd lib/bsd.* lib/btermcap.* lib/termcap.* lib/omflibs.cmd Does this sound OK? Are there any other files which should be {in|ex}cluded? -- John **= Email 14 ==========================** Date: Mon, 18 Feb 2002 16:44:16 +0000 From: "Lyn St George" Subject: Re: ** Apache module and 'inet_aton' error On Mon, 18 Feb 2002 14:40:49 +0000, csaba.raduly at sophos.com wrote: > >On 18/02/2002 13:34:22 owner-os2-unix (rather, Lyn St George) wrote: > >>On Mon, 18 Feb 2002 09:53:31 +0000, csaba.raduly at sophos.com wrote: >> >[snip trying to compile program with inet_aton] >>> >>>int inet_aton(const char *cp, struct in_addr * addr) >>>{ >>> return (*addr = inet_addr(cp)) != INADDR_NONE; >>>} >> >>I've spent half the day tinkering with variations on this, and the >>stuff that Stefan Neis posted. >> >>The best result I can get is by using >>int inet_aton(const char *cp, struct in_addr * addr) >>{ >> return (*addr = inet_addr(cp)) != INADDR_NONE; >>} >>and the original inet_aton code lines. This gives just: >>mod_interchange.c: In function `inet_aton': >>mod_interchange.c:62: incompatible types in assignment >>which is the 'return (*add....' line above. > >Surgeon general's WARNING: >Using incompatible types in assignment can be dangerous >to your data :-) > >Change the offending line to: > return (addr->s_addr = inet_addr(cp)) != INADDR_NONE; Csaba, you're a hero !! That does the trick very nicely indeed. This mod now builds into Apache, doing 'httpd -l' shows it to be there, and running Interchange with this mod instead of the 'foo.exe' cgi now works a treat. Again, thank you :-) >>Changing the 2 lines in the 2 functions as suggested gives similar >>errors in those lines. >> >>Using only:- >>int inet_aton(const char *cp, struct in_addr * addr); >>in place of that typedef line > >That would've worked only if EMX had inet_aton() implemented >(in which case inet_aton would've been mentioned in one of the headers) > Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 15 ==========================** Date: Mon, 18 Feb 2002 16:46:30 +0000 From: "Lyn St George" Subject: Re: LIBEMX suggestion On Mon, 18 Feb 2002 15:34:06 +0000, John Poltorak wrote: >I'm hoping to put together a LIBEMX package based on the contents of >the INCLUDE and LIB directories of EMX/GCC with a few minor changes, which >consist of:- > >* conversion to long filenames using long.cmd >* creation of .lib files via omflibs >* inclusion of IZ's version of db.a (for building Perl) If you would prefer, there is v4.0.14 of Berkeley DB instead of this v1, on ftp.zolotek.net/os2. Perl builds fine with it. >* removal of the following files:- > >include/longshrt.ls* >include/bsd/* >include/curses.h >include/termcap.h >include/*.sed >include/*.cmd >lib/bsd.* >lib/btermcap.* >lib/termcap.* >lib/omflibs.cmd Omflibs.cmd is quite useful, even if this new distro shouldn't need it. > >Does this sound OK? > >Are there any other files which should be {in|ex}cluded? > > >-- >John > > Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 16 ==========================** Date: Mon, 18 Feb 2002 16:49:28 -0600 From: Jeff Robinson Subject: Re: BZIP2 v1.0.2 Mentore Siesto wrote: > > On Sat, 16 Feb 2002, Steve Wendt wrote: > > SW >On Sat, 16 Feb 2002 16:12:09 +0000, John Poltorak wrote: > SW > > SW >>It is a fairly new compression program and format which is more efficient > SW >>than GZIP. Many Unix programs are becoming bundled as tar.bz2 archives. > SW > > SW >Used by WarpIn as well, if I remember correctly. > > IIRC, WarpIN uses a ZIP modified format, with other data. > Internally, WarpIN uses bzip2 for compression though it is basically it's own format when you include the "non-archive" parts, as it were. http://www.xworkplace.org/proj_warpin.html gives a description of it. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 17 ==========================** Date: Mon, 18 Feb 2002 17:20:53 +0000 From: csaba.raduly at sophos.com Subject: Re: ** Apache module and 'inet_aton' error On 18/02/2002 16:44:16 owner-os2-unix (in fact, Lyn St George) wrote: >On Mon, 18 Feb 2002 14:40:49 +0000, csaba.raduly at sophos.com wrote: > [snip] >>> return (*addr = inet_addr(cp)) != INADDR_NONE; [snip] >> >>Surgeon general's WARNING: >>Using incompatible types in assignment can be dangerous >>to your data :-) You would've been able to get away with it, I think. inet_addr() returns an in_addr_t (which is a 32bit unsigned type) inet_aton's second parameter is a "struct in_addr*", which is defined as: struct in_addr{ in_addr_t s_addr; } So, the pointer that points at the in_addr structure also _happens_ to point at an in_addr_t (because of the way structures are laid out in memory). Depending on the memory layout is dangerous at best. >> >>Change the offending line to: >> return (addr->s_addr = inet_addr(cp)) != INADDR_NONE; > > >Csaba, you're a hero !! That does the trick very nicely indeed. Had I read the manpages (and the headers) more carefully, I would've given the correct version first time 'round :-( -- 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 18 ==========================** Date: Mon, 18 Feb 2002 17:34:17 +0000 From: John Poltorak Subject: Re: LIBEMX suggestion On Mon, Feb 18, 2002 at 04:46:30PM +0000, Lyn St George wrote: > On Mon, 18 Feb 2002 15:34:06 +0000, John Poltorak wrote: > > >I'm hoping to put together a LIBEMX package based on the contents of > >the INCLUDE and LIB directories of EMX/GCC with a few minor changes, which > >consist of:- > > > >* conversion to long filenames using long.cmd > >* creation of .lib files via omflibs > >* inclusion of IZ's version of db.a (for building Perl) > > If you would prefer, there is v4.0.14 of Berkeley DB instead > of this v1, on ftp.zolotek.net/os2. Can anyone think of any reason for not using your version? (eg backward compatibility, etc...) Should there also be an updated db.h or any other files to go with it? > Perl builds fine with it. > > >* removal of the following files:- > > > >lib/omflibs.cmd > > Omflibs.cmd is quite useful, even if this new distro > shouldn't need it. omflibs only seems to be a wrapper for emxomf and looks to be specific to the .a libs supplied with EMX/GCC. I was thinking of running omflibs as part of the installation routine instead of including .lib files, but I'll probably leave that until another time. > > Cheers > Lyn St George > +--------------------------------------------------------------------------------- > + http://www.zolotek.net .. eCommerce hosting, consulting > + http://www.os2docs.org .. some 'How To' stuff ... > +---------------------------------------------------------------------------------- -- John **= Email 19 ==========================** Date: Mon, 18 Feb 2002 17:40:11 +0000 From: John Poltorak Subject: LESS v370 There is an OS/2 port of LESS v370 on Hobbes which is maintained by Kyosuke Tokoro . Do any of our Japanese friends know of him? I'd like to try and get his patches and rebuild LESS if possible, but have been unable to get any reply from him. -- John **= Email 20 ==========================** Date: Mon, 18 Feb 2002 18:07:03 -0500 From: Henry Sobotka Subject: Re: LIBEMX suggestion Lyn St George wrote: > > Build DB 1.85 compatibility API > which I did not enable. If you think it should be enabled, then I'll > build a new one and test it, but it will take a couple of days or so. That's it. And at the top of the README in emx/bsd/db you'll see "This is version 1.85 of the Berkeley DB code." It's been around for a long time, and I recall seeing stuff that still uses it rather than newer versions. h~ **= Email 21 ==========================** Date: Mon, 18 Feb 2002 19:08:43 +0000 From: John Poltorak Subject: Re: LIBEMX suggestion On Mon, Feb 18, 2002 at 07:22:10PM +0100, Tobias Ernst wrote: > On Mon, Feb 18, 2002 at 03:34:06PM +0000, John Poltorak wrote: > > > include/bsd/* > > lib/bsd.* > > Why remove these? There are some useful things inside, like e.g. strsep(). include/bsd/* only contains headers that can be superceeded by ncurses, but I'm probably mistaken about deleting bsd.a. > Regards, > Tobias. -- John **= Email 22 ==========================** Date: Mon, 18 Feb 2002 19:22:10 +0100 From: Tobias Ernst Subject: Re: LIBEMX suggestion On Mon, Feb 18, 2002 at 03:34:06PM +0000, John Poltorak wrote: > include/bsd/* > lib/bsd.* Why remove these? There are some useful things inside, like e.g. strsep(). Regards, Tobias. **= Email 23 ==========================** Date: Mon, 18 Feb 2002 19:25:43 +0000 From: John Poltorak Subject: Re: LIBEMX suggestion On Mon, Feb 18, 2002 at 01:23:40PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > Can anyone think of any reason for not using your version? (eg backward > > compatibility, etc...) > > Assuming it's the Sleepycat version, it has its own license that should > be checked first. It is Copyright Sleepycat Software, but I've never heard of this outfit. Where do I find any license information? > Also, IIRC its backward compatibility is a build > option, so make sure it's enabled. One thing I noticed in the archive is the presence of both db.(a,lib) and libdb.(a,lib). We only should have one, and my preference would be libdb.*. Anyone (dis)agree? > h~ -- John **= Email 24 ==========================** Date: Mon, 18 Feb 2002 19:38:10 +0000 From: John Poltorak Subject: Sleepycat Software licence Can we live with this? :- The following is the license that applies to this copy of the Berkeley DB software. For a license to use the Berkeley DB software under conditions other than those described here, or to purchase support for this software, please contact Sleepycat Software at one of the following addresses: Sleepycat Software info at sleepycat.com 118 Tower Road +1 (617) 876-0858 Lincoln, MA 01773 877-SLEEPYCAT (toll-free, USA only) USA =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= /* * Copyright (c) 1990-2002 * Sleepycat Software. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Redistributions in any form must be accompanied by information on * how to obtain complete source code for the DB software and any * accompanying software that uses the DB software. The source code * must either be included in the distribution or be available for no * more than the cost of distribution plus a nominal fee, and must be * freely redistributable under reasonable conditions. For an * executable file, complete source code means the source code for all * modules it contains. It does not include source code for modules or * files that typically accompany the major components of the operating * system on which the executable file runs. * * THIS SOFTWARE IS PROVIDED BY SLEEPYCAT SOFTWARE ``AS IS'' AND ANY EXPRESS * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR * NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL SLEEPYCAT SOFTWARE * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF * THE POSSIBILITY OF SUCH DAMAGE. */ /* * Copyright (c) 1990, 1993, 1994, 1995 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ /* * Copyright (c) 1995, 1996 * The President and Fellows of Harvard University. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY HARVARD AND ITS CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL HARVARD OR ITS CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -- John **= Email 25 ==========================** Date: Mon, 18 Feb 2002 21:47:23 +0000 From: John Poltorak Subject: gcc v3.0.3 ? Did I see some reference to gcc v3.0.3 being available soon? -- John **= Email 26 ==========================** Date: Mon, 18 Feb 2002 22:25:10 +0000 From: "Lyn St George" Subject: Re: LIBEMX suggestion On Mon, 18 Feb 2002 15:25:43 -0500, Henry Sobotka wrote: >John Poltorak wrote: >> >> It is Copyright Sleepycat Software, but I've never heard of this outfit. > >Keith Bostic's firm. He's one of the original authors of BDB. > >> One thing I noticed in the archive is the presence of both db.(a,lib) and >> libdb.(a,lib). We only should have one, and my preference would be libdb.*. >> >> Anyone (dis)agree? > >Problem is that'll break every makefile containing -ldb for anyone using >a version of gcc that doesn't prepend 'lib'. That's the reason I did that - Perl tests for the BerkeleyDB version, starting with the header. V1 contains no version info, but later ones do and Perl tests that info against the info in libdb.a - if you only have db.a then the perl build fails. I'm using gcc 2.95-2. Backward compatibility - just looked for that and the only thing I can see is in configure: Build DB 1.85 compatibility API which I did not enable. If you think it should be enabled, then I'll build a new one and test it, but it will take a couple of days or so. >h~ > Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 27 ==========================** Date: Mon, 18 Feb 2002 22:59:39 +0100 (CET) From: "Adrian Gschwend" Subject: Re: gcc v3.0.3 ? On Mon, 18 Feb 2002 21:47:23 +0000, John Poltorak wrote: >Did I see some reference to gcc v3.0.3 being available soon? Yep, ftp.netlabs.org/pub/gcc cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 28 ==========================** Date: Mon, 18 Feb 2002 23:27:09 +0100 (CET) From: "Adrian Gschwend" Subject: OSFree... Something interesting poped up: http://hobbes.nmsu.edu/pub/incoming/osf_en.zip Noncommercial OS/2-compatible operating system Long Description: osFree, a noncommercial OS/2-compatible system, sees the light of day. Englishand Russian versions are available at Hobbes. The project invites new participants... It contains some DSK-files which looks like OS/2 boot floppy disk images. One guy I know installed it in VPC and it boots up with a command prompt. There is a readme in it which describes how you can replace the "original" OS/2 Kernel by that stuff. Source is not included and there is not much info on the mailinglist yet but they talk about setting up a CVS. I guess this thingy is based on some "leaked" sources from IBM. And I don't think IBM will like this... I wonder how much of it is compiled and how much is just taken from existing OS/2 (I don't have to say that I like the idea itself I think :-) Content: DISK0.DSK - Boot disk #0 DISK1.DSK - Boot disk #1 DISK2.DSK - Boot disk #2: CMD.EXE, FDISK, FORMAT DISK3.DSK - Additional tested packages, CHKDSK, UHPFS.DLL DISK4.DSK - Untested packages SYM1.DSK - Kernel debugger base, half-strict kernel, dump formatter, TRACE SYM2.DSK - All-strict kernel, debug executables, symbol files --snipp-- This README file contains the information on osFree v 4.00 (hereinafter called osFree). This product is compatible with IBM** OS/2 Warp 4** operating system, build level 9.023. [...] ---snip--- cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org