From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 6 Feb 2002 04:14:34 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 127 ************************************************** Tuesday 05 February 2002 Number 127 ************************************************** Subjects for today 1 Re: GLIBC : Stefan Neis 2 Re: GLIBC : Lyn St George" 3 Re: GLIBC : John Drabik" 4 Re: GLIBC : John Drabik" 5 Re: GLIBC : John Poltorak 6 Re: GLIBC : Thomas E. Dickey" 7 Re: GLIBC : Thomas E. Dickey" 8 Re: GLIBC : Holger Veit 9 Re: GLIBC : John Poltorak 10 LUA40 : John Poltorak 11 Re: Perl test script failures : Henry Sobotka 12 Re: LUA40 : csaba.raduly at sophos.com 13 Re: Perl test script failures : Henry Sobotka 14 Re: GLIBC : csaba.raduly at sophos.com 15 Perl test script failures : John Poltorak 16 Re: installpkg bin.zip ? : frank schmittroth" 17 New CDRTools : John Poltorak 18 Re: Perl test script failures : Henry Sobotka 19 Re: installpkg bin.zip ? : frank schmittroth" 20 Re: GLIBC : Holger Veit 21 Re: GLIBC : Thomas Dickey 22 Re: GLIBC : Holger Veit 23 Re: GLIBC : Holger Veit 24 Re: GLIBC : John Poltorak 25 Re: Perl test script failures : Lyn St George" 26 Scilab : John Poltorak 27 Re: GLIBC : Stefan Neis 28 Re: Perl test script failures : John Poltorak 29 Re: LUA40 : Sebastian Wittmeier (ShadoW)" 30 Re: Perl test script failures : csaba.raduly at sophos.com 31 Re: Perl test script failures : Henry Sobotka 32 Re: Perl test script failures : John Poltorak 33 Re: Perl test script failures : John Poltorak 34 Re: Perl test script failures : Lyn St George" 35 Long filenmes : John Poltorak 36 Somewhat OT: C#, Mono and GNOME : Adrian Gschwend" 37 Re: Long filenmes : Dave Saville" 38 Re: installpkg bin.zip ? : Michael Zolk 39 Re: Somewhat OT: C#, Mono and GNOME : Achim Hasenmueller" 40 Re: Long filenmes : Holger Veit 41 *Two* Linux standards Platforms : John Poltorak 42 Re: GLIBC : Stefan Neis 43 Re: Perl test script failures : John Poltorak 44 Re: GLIBC : Holger Veit 45 Re: installpkg bin.zip ? : John Poltorak 46 Re: GLIBC : Stefan Neis 47 Re: *Two* Linux standards Platforms : Jeff Robinson 48 Re: GLIBC : Holger Veit **= Email 1 ==========================** Date: Wed, 6 Feb 2002 00:14:57 +0100 (CET) From: Stefan Neis Subject: Re: GLIBC 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... > 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'. **= Email 2 ==========================** Date: Wed, 06 Feb 2002 06:26:49 +0000 From: "Lyn St George" Subject: Re: GLIBC I'm becoming a little confused here - nobody in this thread has mentioned LIBEMU, and yet I am under the impression that this will be the functional equivalent of GLIBC. In other words, if GLIBC contains all the base libs and functions needed to "make Linux work", then LIBEMU contains all the base libs and functions to "make UnixOS/2 work". In which case, the discussion should not be about porting a reputedly buggy library, but in assisting the current effort to port the BSD libs, etc, etc, so as to build LIBEMU. Or have I got this completey wrong?? Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 3 ==========================** Date: Wed, 06 Feb 2002 07:39:12 -0700 (MST) From: "John Drabik" Subject: Re: GLIBC On Wed, 6 Feb 2002 15:04:34 +0100 (CET), Stefan Neis wrote: >P.S.: Great, I finally managed to start a Linux/GNU vs. BSD war. :-( > Sorry. :-( Don't be sorry at all. Your points (and mine) were a discussion, not a war. I appreciate your comments and feedback. I still disagree with some of them, but I see your point on a few others, so, what's wrong with that? John **= Email 4 ==========================** Date: Wed, 06 Feb 2002 08:00:58 -0700 (MST) From: "John Drabik" Subject: Re: GLIBC On Tue, 5 Feb 2002 21:27:24 -0800, John Merryweather Cooper wrote: >Pure garbage. BSD isn't being "purchased" by anyone. Check your back copies of your favorite trade rag, last Fall, and see what happened. Then, examine it against the current situation at the main BSD site. > 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. :) Thank you for proving my point, which was, taking BSD code and modifying it (and not returning the results to the community), will result in mangled, incompatible systems. Have you spent much time trying to get a heterogeneous Doze/OS2/BSD network to "play together"? It is a real mess. >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. Exactly. John **= Email 5 ==========================** Date: Wed, 6 Feb 2002 08:18:35 +0000 From: John Poltorak Subject: Re: GLIBC On Tue, Feb 05, 2002 at 07:42:27PM -0500, Charles R. Hunter wrote: > 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. We are _not_ using Linux as a source code base. SlackWare is being used simply as a distro model for creating a framework for packages and an installer. The individual packages themselves are derived from any existing ports. It's up to the porter where the original source comes from but I doubt whether Perl, Python, Apache, MySQL, XFree86 or any other package in SlackWare has any reliance on Linux. > I don't want always be a spoil-sport, I just think we are > barking up the wrong tree. I guess you misunderstand how UnixOS/2 is being put together. The use of SlackWare as a model is mainly for expediancy in terms of putting together something like a usable distro. Linux itself is not being used as a shining light to be followed without question. > Charles > > -- > Charles R. Hunter > Director, Physics Computer Network > Purdue University crh at physics.purdue.edu -- John **= Email 6 ==========================** Date: Wed, 6 Feb 2002 08:24:04 -0500 (EST) From: "Thomas E. Dickey" Subject: Re: GLIBC On Wed, 6 Feb 2002, Holger Veit wrote: > GLIBC tries to satisfy all those standards and in addition tries to > be portable to almost any platform. In reality, it is tailored and > best working with Linux, only, letting everyone who wants to port it > to anything not Linux jump through numerous hoops first, and then failing > due to some conceptual oddity in the code :-( glibc works well enough if you simply ignore the nonstandard stuff. (the BSD libraries also contain a similar proportion of nonstandard functions, which I ignore also ;-) -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 7 ==========================** Date: Wed, 6 Feb 2002 08:50:42 -0500 (EST) From: "Thomas E. Dickey" Subject: Re: GLIBC On Wed, 6 Feb 2002, Holger Veit wrote: > On Wed, Feb 06, 2002 at 08:24:04AM -0500, Thomas E. Dickey wrote: > > glibc works well enough if you simply ignore the nonstandard stuff. > > > > (the BSD libraries also contain a similar proportion of nonstandard > > functions, which I ignore also ;-) > > ;-) "Standard" vs. "Non-Standard" is in the eye of the beholder. perhaps. I use the same rule for each - is the code in common use on other platforms than the one I'm looking at, and if so, does it behave the same. ( If not, then it's a local custom which one may have to use if the standard operations have been broken ;-) -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 8 ==========================** Date: Wed, 6 Feb 2002 09:11:25 +0100 From: Holger Veit Subject: Re: GLIBC On Wed, Feb 06, 2002 at 06:26:49AM +0000, Lyn St George wrote: > I'm becoming a little confused here - nobody in this thread > has mentioned LIBEMU, and yet I am under the impression > that this will be the functional equivalent of GLIBC. In other I have more than once mentioned that LIBEMU will adopt parts of POSIX/2 which means mainly the BSD libc subtree. > words, if GLIBC contains all the base libs and functions > needed to "make Linux work", then LIBEMU contains all > the base libs and functions to "make UnixOS/2 work". The misinterpretation IMHO comes from the talk and work on Slackware-type packages. This does not have to do anything with Linux, but with packaging. You can get the same software (GNU and non-GNU) from numerous other places in the web as well as from FreeBSD or RedHat distributions. The purpose Slackware serves is purely a sufficiently simple model of packaging a system - it does not mean, and was never mentioned this way - that we are going to emulate Linux. We are going to build a framework to run Unix applications under OS/2. Unix != Linux even if the younger generation does no longer understand the difference. The point of "functional equivalent" is also misleading. LIBEMU will provide "the Unix API" which is by itself a moving target - there are several interpretations about what belongs to this API. BSD is one interpretation, and GLIBC is another. But this does not mean they are the same. Portable Unix software will typically understand both flavours. Therefore my opinion is to take the code that is easier to understand and maintain. > In which case, the discussion should not be about porting > a reputedly buggy library, but in assisting the current effort > to port the BSD libs, etc, etc, so as to build LIBEMU. > > Or have I got this completey wrong?? -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 9 ==========================** Date: Wed, 6 Feb 2002 09:13:28 +0000 From: John Poltorak Subject: Re: GLIBC On Wed, Feb 06, 2002 at 12:14:57AM +0100, Stefan Neis 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. There's some misunderstanding here. I guess I'm using the term GLIBC when I ought to be using LIBC... Not being familar with these things I didn't realise I would stoke up such feelings of animosity by refering to GNU LIBC instead of BSD LIBC. To mind it's just a name which decribes a package which provides some useful functionality. > 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... > > > 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. I'm confused as to whether LIBC means BSD LIBC or whether it is a generic name. SlackWare's description of their GLIBC package further muddies the water:- This package contains the GNU C libraries and header files. The GNU C library was written originally by Roland McGrath, and is currently maintained by Ulrich Drepper. Some parts of the library were contributed or worked on by other people. The BSD database libraries, no longer officially part of glibc, have been added back by Slackware. Don't we need GNU C libraries and header files to be able to use GCC? Where do I find some more info LIBC? Presumably GNU and BSD versions both aim to provide the same functionality... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 10 ==========================** Date: Wed, 6 Feb 2002 09:39:08 +0000 From: John Poltorak Subject: LUA40 LUA40 is a new package which arrived at Hobbes recently. This is an OS/2 port of the LUA interpreter and provides yet another scripting language. I've never heard of LUA previously, and whilst it's good to see an OS/2 version, I can't help but wonder why we need a new scripting lanaguage... What does this have which REXX, Bash, Perl, Python, Snobol, Ruby etc etc don't have? -- John **= Email 11 ==========================** Date: Wed, 06 Feb 2002 09:44:08 -0500 From: Henry Sobotka Subject: Re: Perl test script failures The DB_File failures may be due not using the threadsafe version of db.lib from Ilya's site. h~ **= Email 12 ==========================** Date: Wed, 6 Feb 2002 10:09:30 +0000 From: csaba.raduly at sophos.com Subject: Re: LUA40 On 06/02/2002 09:39:08 owner-os2-unix wrote: >LUA40 is a new package which arrived at Hobbes recently. This is an OS/2 >port of the LUA interpreter and provides yet another scripting language. > >I've never heard of LUA previously, and whilst it's good to see an OS/2 >version, I can't help but wonder why we need a new scripting language... >What does this have which REXX, Bash, Perl, Python, Snobol, Ruby etc etc >don't have? > Let natural selection have its way... My favourite browser ( Links, http://links.sourceforge.net/ ) has a fork called links-lua, which incorporates LUA hooks into the browser. -- 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 13 ==========================** Date: Wed, 06 Feb 2002 10:17:42 -0500 From: Henry Sobotka Subject: Re: Perl test script failures John Poltorak wrote: > > Do you mean this:- > > http://www.math.ohio-state.edu/~ilya/software/os2/db_mt.zip Precisely, > Is it recommended? BTW this only contains db.a, I don't see db.lib. Not just recommended but essential for DB_File. Just run: emxomf -o db.lib db.a h~ **= Email 14 ==========================** Date: Wed, 6 Feb 2002 10:22:56 +0000 From: csaba.raduly at sophos.com Subject: Re: GLIBC On 06/02/2002 05:27:24 jmcooper wrote: >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 [snip] > >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 ^^^^^^^^^^^^^^ Bzzzzzt ! Wrong: GPL'd code not only can, but *is* sold commercially. Example: the GNU ADA translator (GNAT). >or closed source; 3) anything GPL'ed cannot be included >in whole or in part in any closed-source product; That's not true either. You can package closed-source programs which link to e.g. DLLs produced from GPL'd sources. See the 'mere aggregation' part in the GPL. [snip] I blame John Poltorak for mentioning the G-word ( GLIBC ) here, which obviously acted as a red scarf for some people. But those who objected to calling EMX-TNG (the next generation :-) GLIBC were right: it would be a clear violation of the Trade Descriptions Act :-) Also, somebody was wandering whether we need GLIBC to use GCC. The answer is clearly `NO'. FreeBSD at comes with cc == gcc as standard, but has its own libc. Csaba -- 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 15 ==========================** Date: Wed, 6 Feb 2002 10:25:47 +0000 From: John Poltorak Subject: Perl test script failures When building Perl 5.6.1 a few days ago, the following test scripts did not succeed:- op/64bitint..........skipping test on this platform op/grent.............skipping test on this platform op/groups............skipping test on this platform op/lfs...............skipping test on this platform op/magic............. Process terminated by SIGINT op/pwent.............skipping test on this platform lib/bigfltpm......... Process terminated by SIGPIPE FAILED at test 165 lib/db-btree.........Can't load '../lib/auto/DB_File/DB_FilZD.dll' for module DB_File: SYS0192: The operating system cannot run %1, possible problematic module: 'C:\TMP\PERL\PERL-5.6.1\LIB\AUTO\DB_FILE\DB_FILZD.DLL' at ../lib/XSLoader.pm line 80. at ../lib/DB_File.pm line 239 Compilation failed in require at lib/db-btree.t line 14. BEGIN failed--compilation aborted at lib/db-btree.t line 14. FAILED at test 0 lib/db-hash..........Can't load '../lib/auto/DB_File/DB_FilZD.dll' for module DB_File: SYS0192: The operating system cannot run %1, possible problematic module: 'C:\TMP\PERL\PERL-5.6.1\LIB\AUTO\DB_FILE\DB_FILZD.DLL' at ../lib/XSLoader.pm line 80. at ../lib/DB_File.pm line 239 Compilation failed in require at lib/db-hash.t line 14. BEGIN failed--compilation aborted at lib/db-hash.t line 14. FAILED at test 0 lib/db-recno.........Can't load '../lib/auto/DB_File/DB_FilZD.dll' for module DB_File: SYS0192: The operating system cannot run %1, possible problematic module: 'C:\TMP\PERL\PERL-5.6.1\LIB\AUTO\DB_FILE\DB_FILZD.DLL' at ../lib/XSLoader.pm line 80. at ../lib/DB_File.pm line 239 Compilation failed in require at lib/db-recno.t line 12. BEGIN failed--compilation aborted at lib/db-recno.t line 12. FAILED at test 0 lib/gdbm.............skipping test on this platform lib/ipc_sysv.........skipping test on this platform lib/ndbm.............skipping test on this platform lib/odbm.............skipping test on this platform lib/rx_cmprt......... 1 +++ Call myfunc ? say 'ok 'myfunc1(1)myfunc2(2); REX0013: Error 13 running StartPerl, line 1: Invalid character in program REXX compartment returned non-zero status -13 at lib/rx_cmprt.t line 48. FAILED at test 16 lib/rx_dllld.........skipping test on this platform lib/rx_objcall.......skipping test on this platform lib/rx_tievar........skipping test on this platform lib/rx_tieydb........skipping test on this platform lib/rx_vrexx.........skipping test on this platform lib/syslfs...........skipping test on this platform lib/syslog...........skipping test on this platform lib/thr5005..........skipping test on this platform Failed 5 test scripts out of 258, 98.06% okay. Is there anything I can do to improve this build? -- John **= Email 16 ==========================** Date: Wed, 06 Feb 2002 11:55:53 -0800 (PST) From: "frank schmittroth" Subject: Re: installpkg bin.zip ? On Wed, 6 Feb 2002 18:38:44 +0100, Michael Zolk wrote: >Hmmm. I can't reproduce the error here. The bin package is installed >successfully, without any error messages. Maybe you have got an older version? > >I plan to upload a newer version of ux2_base with a few minor updates soon >(maybe tonight? :-) anyway. Maybe you can try this version. After this email, I snooped a bit further in unixos2.com and discovered another directory with installpkg: /pub/unixos2/development/install. So I downloaded it; my previous attempt was using the default installpkg that was installed with ux2_base. However I see, that the ux2_base version (0.5) is newer so I'll wait for your update. That does raise a question in my mind however. Is there some way to distinguish the recommended vs. archival versions of various packages/ programs in the unixos2.com directory tree? If one is not careful, there will just be another hodgepodge of versions. I don't think that enforced version control is necessary, but some simple guidelines for both users and contributors might help. Frank. ----------------------- Frank Schmittroth franks at owt.com **= Email 17 ==========================** Date: Wed, 6 Feb 2002 12:46:24 +0000 From: John Poltorak Subject: New CDRTools There's a new release of CDRTools at Hobbes:- http://hobbes.nmsu.edu/pub/new/cdrtools2-1.11a13.zip I don't know what new features this release contains. It's an amalgam of a few CD utils which sometimes appear individually and includes CDRECORD and CDDA2WAV. In the past I have come across a number of handy REXX scripts such as CDCOPY and COPY2CD which take the pain out of learning about all the available flags. I guess these scripts would still be applicable, and I think they ought to be included in any UnixOS/2 CDRTOOLS package.... One thing which has always puzzled me is why there are two packages, CDRTOOLS and CDRDAO for reading and writing CDs. I've always wondered if CDRECORD was capable of doing the things CDRDAO does. There seem to be so many options that it's difficult to know for sure. -- John **= Email 18 ==========================** Date: Wed, 06 Feb 2002 13:35:36 -0500 From: Henry Sobotka Subject: Re: Perl test script failures Dug up my testlog from 5.6.1 and the first two results differ: op/magic............ok, 4/35 skipped: no caseless %ENV support The skipping comes from the else block to "if ($Is_MSWin32)" so I haven't lost sleep over it. lib/bigfltpm........ok With lib/rx_cmprt.t I got exactly the same result as you do. h~ **= Email 19 ==========================** Date: Wed, 06 Feb 2002 13:47:56 -0800 (PST) From: "frank schmittroth" Subject: Re: installpkg bin.zip ? On Wed, 6 Feb 2002 20:06:51 +0000, John Poltorak wrote: >UnixOS/2 packages should be under:- > >ftp://unixos2.com/pub/unixos2/unixos2-current/unixos2 > >There is no versioning or archival at present. Perhaps "archival" was a bad choice of words on my part. However there are older versions of installpkg in: ftp://unixos2.com/pub/unixos2/development/install/ And I couldn't tell that they were older until I downloaded and unzipped them. Does it say anywhere what goes into the "development" branch as compared to the "unixos2-current" branch? Frank. ----------------------- Frank Schmittroth franks at owt.com **= Email 20 ==========================** Date: Wed, 6 Feb 2002 13:59:14 +0100 From: Holger Veit Subject: Re: GLIBC On Wed, Feb 06, 2002 at 09:13:28AM +0000, John Poltorak wrote: > On Wed, Feb 06, 2002 at 12:14:57AM +0100, Stefan Neis 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. > > > There's some misunderstanding here. I guess I'm using the term GLIBC > when I ought to be using LIBC... Not being familar with these things I > didn't realise I would stoke up such feelings of animosity by refering to > GNU LIBC instead of BSD LIBC. To mind it's just a name which decribes a > package which provides some useful functionality. GLIBC refers to GNU libc. > > Nope, that's based on BSD codei (due to its reasonable copyright and > > cleaner code), no part of GLIBC is in there. > > I'm confused as to whether LIBC means BSD LIBC or whether it is a generic > name. SlackWare's description of their GLIBC package further muddies the LIBC is a generic name, it means the library that provides the Unix API to C programs. > water:- > > This package contains the GNU C libraries and header files. The GNU > C library was written originally by Roland McGrath, and is currently > maintained by Ulrich Drepper. Some parts of the library were > contributed or worked on by other people. The BSD database libraries, > no longer officially part of glibc, have been added back by Slackware. > > > Don't we need GNU C libraries and header files to be able to use GCC? No. gcc can compile code with any kind of header files. See its option -nostdinc, for instance. I use the (almost :-)) normal EMX/gcc-2.8.1 to compile test programs which include the BSD header files. The header files and the C library must must match (type conventions, available functions, etc.). > Where do I find some more info LIBC? Presumably GNU and BSD versions both > aim to provide the same functionality... Yes/No. Historically, two main flavours have evolved: SVR4 and BSD, both being incompatible successors of AT&T's System V. POSIX attempted to unify and standardize both styles, including numerous other dialects like AIX, Solaris, SCO, Ultrix, etc. that extended or mixed one or the other flavour of these, trying to also address issues of internationalization (I18N). This has led to quite a complex API which is difficult to handle and implement correctly, particularly, since other unrelated standards like ANSI C or ISO C98/C99 also apply. GLIBC tries to satisfy all those standards and in addition tries to be portable to almost any platform. In reality, it is tailored and best working with Linux, only, letting everyone who wants to port it to anything not Linux jump through numerous hoops first, and then failing due to some conceptual oddity in the code :-( Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 21 ==========================** Date: Wed, 6 Feb 2002 14:12:22 -0500 From: Thomas Dickey Subject: Re: GLIBC On Wed, Feb 06, 2002 at 07:50:50PM +0100, Stefan Neis wrote: > But then, I wouldn't call code that has been written to be portable > across various platforms "Linux code" just because that happens to > be the platform where the programmer's editor is running most of the > time. you wouldn't, but some people do (oddly, most of them seem to be posting usenet articles in comp.unix.bsd.freebsd.misc ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 22 ==========================** Date: Wed, 6 Feb 2002 14:34:32 +0100 From: Holger Veit Subject: Re: GLIBC On Wed, Feb 06, 2002 at 10:22:56AM +0000, csaba.raduly at sophos.com wrote: > > On 06/02/2002 05:27:24 jmcooper wrote: > > >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 > [snip] > > > >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 > ^^^^^^^^^^^^^^ > > Bzzzzzt ! Wrong: GPL'd code not only can, but *is* sold commercially. > Example: the GNU ADA translator (GNAT). > > >or closed source; 3) anything GPL'ed cannot be included > >in whole or in part in any closed-source product; > > That's not true either. You can package closed-source programs > which link to e.g. DLLs produced from GPL'd sources. > See the 'mere aggregation' part in the GPL. No, the above is quite right, the essential wording is GPL. That you are allowed to link commercial apps, like Oracle or SAP on Linux, to the "GPL'd" Linux system libraries is simply, because typically libraries, as well as compiler and linker to produce them and the application are not "GPL" but actually "LGPL" (Library GPL or also "lesser GPL"). This variation has been, after heavy flamewars with Richard Stallman, written and invented in order not to pollute third party applications by just linking against a GNU open source library. The point is here that GLIBC is distributed under LGPL, so you may link a commercial application against it. It is more uncomfortable, in the sense of the license, though, that the vendor also has to distribute the source code of that library as well (despite that GNU code is usually downloadable from everywhere already), although it barely happens at all that some customer will actually recompile it - and he doesn't have the source code of the actual application anyway. > I blame John Poltorak for mentioning the G-word ( GLIBC ) here, > which obviously acted as a red scarf for some people. > > But those who objected to calling EMX-TNG (the next generation :-) > GLIBC were right: it would be a clear violation of the > Trade Descriptions Act :-) :-) > Also, somebody was wandering whether we need GLIBC to use GCC. > The answer is clearly `NO'. FreeBSD at comes with cc == gcc > as standard, but has its own libc. Almost any Unix nowadays comes with a gcc, or gcc can be installed on such a system. Under Solaris, it works quite well with the stock /usr/include and /usr/lib files. And EMX/gcc is itself an example: the header files EM provided are from anywhere, some also from BSD, and the runtime system is definitely GPL/LGPL, but not GNU (and God save us: it is not GLIBC!). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 23 ==========================** Date: Wed, 6 Feb 2002 14:36:06 +0100 From: Holger Veit Subject: Re: GLIBC On Wed, Feb 06, 2002 at 08:24:04AM -0500, Thomas E. Dickey wrote: > On Wed, 6 Feb 2002, Holger Veit wrote: > > > GLIBC tries to satisfy all those standards and in addition tries to > > be portable to almost any platform. In reality, it is tailored and > > best working with Linux, only, letting everyone who wants to port it > > to anything not Linux jump through numerous hoops first, and then failing > > due to some conceptual oddity in the code :-( > > glibc works well enough if you simply ignore the nonstandard stuff. > > (the BSD libraries also contain a similar proportion of nonstandard > functions, which I ignore also ;-) ;-) "Standard" vs. "Non-Standard" is in the eye of the beholder. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 24 ==========================** Date: Wed, 6 Feb 2002 14:36:24 +0000 From: John Poltorak Subject: Re: GLIBC On Wed, Feb 06, 2002 at 03:04:34PM +0100, Stefan Neis wrote: > On Tue, 5 Feb 2002, John Drabik wrote: > > > >I don't want always be a spoil-sport, I just think we are > > >barking up the wrong tree. > > > > Why? > > AFAIK, we did choose Linux for a packaging model, but nor for source > code, so I don't see that either. There was some debate about which *nix distro would be most suitable and I don't think it was confined to Linux. FreeBSD was also mentioned, but the consensus was that SlackWare was the most stable and mature, and its package management was more easily portable to OS/2 than anything else suggested. > > 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. > > Well, maybe. However, I'm under the impression there's plenty of Linux > code which compiles under Linux _only_ (not even any real Unix not to > mention way different systems like OS/2), whereas I never personally > encountered any such piece of BSD code. Could be just plain luck, > though... I thought Autoconf+friends were developed to simplify cross platform developed so that code written on Linux could be rebuild on FreeBSD, Solaris or anything else which had the relevant libraries. > Regards, > Stefan > > P.S.: Great, I finally managed to start a Linux/GNU vs. BSD war. :-( That's no problem. I'm an extreme neutral in this war and find it interesting to hear both side of the argument. It should help to clarify the format of the Unix-like environment we want on OS/2. > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 25 ==========================** Date: Wed, 06 Feb 2002 14:56:42 +0000 From: "Lyn St George" Subject: Re: Perl test script failures On Wed, 6 Feb 2002 10:25:47 +0000, John Poltorak wrote: > >When building Perl 5.6.1 a few days ago, the following test scripts did >not succeed:- > >op/64bitint..........skipping test on this platform >op/grent.............skipping test on this platform >op/groups............skipping test on this platform >op/lfs...............skipping test on this platform >op/magic............. >Process terminated by SIGINT >op/pwent.............skipping test on this platform >lib/bigfltpm......... >Process terminated by SIGPIPE >FAILED at test 165 >lib/db-btree.........Can't load '../lib/auto/DB_File/DB_FilZD.dll' for module DB_File: SYS0192: The operating system cannot run %1, possible problematic module: 'C:\TMP\PERL\PERL-5.6.1\LIB\AUTO\DB_FILE\DB_FILZD.DLL' at ../lib/XSLoader.pm line 80. > at ../lib/DB_File.pm line 239 >Compilation failed in require at lib/db-btree.t line 14. >BEGIN failed--compilation aborted at lib/db-btree.t line 14. >FAILED at test 0 >lib/db-hash..........Can't load '../lib/auto/DB_File/DB_FilZD.dll' for module DB_File: SYS0192: The operating system cannot run %1, possible problematic module: 'C:\TMP\PERL\PERL-5.6.1\LIB\AUTO\DB_FILE\DB_FILZD.DLL' at ../lib/XSLoader.pm line 80. > at ../lib/DB_File.pm line 239 >Compilation failed in require at lib/db-hash.t line 14. >BEGIN failed--compilation aborted at lib/db-hash.t line 14. >FAILED at test 0 >lib/db-recno.........Can't load '../lib/auto/DB_File/DB_FilZD.dll' for module DB_File: SYS0192: The operating system cannot run %1, possible problematic module: 'C:\TMP\PERL\PERL-5.6.1\LIB\AUTO\DB_FILE\DB_FILZD.DLL' at ../lib/XSLoader.pm line 80. > at ../lib/DB_File.pm line 239 >Compilation failed in require at lib/db-recno.t line 12. >BEGIN failed--compilation aborted at lib/db-recno.t line 12. >FAILED at test 0 >lib/gdbm.............skipping test on this platform >lib/ipc_sysv.........skipping test on this platform >lib/ndbm.............skipping test on this platform >lib/odbm.............skipping test on this platform >lib/rx_cmprt......... 1 +++ Call myfunc ? say 'ok 'myfunc1(1)myfunc2(2); >REX0013: Error 13 running StartPerl, line 1: Invalid character in program >REXX compartment returned non-zero status -13 at lib/rx_cmprt.t line 48. >FAILED at test 16 >lib/rx_dllld.........skipping test on this platform >lib/rx_objcall.......skipping test on this platform >lib/rx_tievar........skipping test on this platform >lib/rx_tieydb........skipping test on this platform >lib/rx_vrexx.........skipping test on this platform >lib/syslfs...........skipping test on this platform >lib/syslog...........skipping test on this platform >lib/thr5005..........skipping test on this platform >Failed 5 test scripts out of 258, 98.06% okay. > > >Is there anything I can do to improve this build? You need to get a working "multi-thread safe" db.lib. There is one at http://www.ilyaz.org/software/os2/. Otherwise most of the other tests either fail or are skipped for me too. >-- >John > > Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 26 ==========================** Date: Wed, 6 Feb 2002 14:59:10 +0000 From: John Poltorak Subject: Scilab Has anyone heard of Scilab? Scilab is a scientific software package for numerical computations in a user-friendly environment. It features: Elaborate data structures (polynomial, rational and string matrices, lists, multivariable linear systems,...). Sophisticated interpreter and programming language with Matlab-like syntax. Hundreds of built-in math functions (new primitives can easily be added). Stunning graphics (2d, 3d, animation). Open structure (easy interfacing with Fortran and C via online dynamic link). Many built-in libraries: Linear Algebra (including sparse matrices, Kronecker form, ordered Schur,...). Control (Classical, LQG, H-infinity,...). Package for LMI (Linear Matrix Inequalities) optimization. Signal processing. Simulation (various ode's, dassl,...). Optimization (differentiable and non-differentiable, LQ solver). Scicos, an interactive environment for modeling and simulation of dynamical systems. Metanet (network analysis and optimization). Symbolic capabilities through Maple interface. Parallel Scilab. For further details see:- http://www-rocq.inria.fr/scilab/ Don't suppose anyone has ever tried building it on OS/2... -- John **= Email 27 ==========================** Date: Wed, 6 Feb 2002 15:04:34 +0100 (CET) From: Stefan Neis Subject: Re: GLIBC On Tue, 5 Feb 2002, John Drabik wrote: > HUH? Utter HOGWASH! It is being used commercially every day. Yes. And you end up with two applications dynamically linked against two different glibc versions which causes all kinds of troubles. And it would cause even more problems on a platform without proper versioning support for DLLs. I don't think I'm still using OS/2 to get that same kind of nightmare. > 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. Well it's not that much pain to support one more platform, some products where I'm personally involved have OS/2 support included, but not being allowed to link statically would be a serious problem. > 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. Well, IBM is commited to support it till 2005 or 2007 (don't remember which one), I don't think you get a similarly long perspective for _any_ other OS, so I just relax and wait for whatever is comming. Maybe there's even a usable alternative in a couple of years. > 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". What's the problem with that? I see it, don't like it and don't use it. > 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 totally disagree (see above). With GNU type licence (especially if its for a central piece of software like libc), I feel forced to either come up with an alternative solution or drop it altogether, BSD is fine. > >I don't want always be a spoil-sport, I just think we are > >barking up the wrong tree. > > Why? AFAIK, we did choose Linux for a packaging model, but nor for source code, so I don't see that either. > 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. Contrary to Linux and glibc, it will at least ensure a _stable_ future. That's IMHO the most important part of it. I don't see, how it would suddenly become non-free either. > 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. Well, maybe. However, I'm under the impression there's plenty of Linux code which compiles under Linux _only_ (not even any real Unix not to mention way different systems like OS/2), whereas I never personally encountered any such piece of BSD code. Could be just plain luck, though... Regards, Stefan P.S.: Great, I finally managed to start a Linux/GNU vs. BSD war. :-( Sorry. :-( -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 28 ==========================** Date: Wed, 6 Feb 2002 15:05:33 +0000 From: John Poltorak Subject: Re: Perl test script failures On Wed, Feb 06, 2002 at 09:44:08AM -0500, Henry Sobotka wrote: > The DB_File failures may be due not using the threadsafe version of > db.lib from Ilya's site. Do you mean this:- http://www.math.ohio-state.edu/~ilya/software/os2/db_mt.zip Is it recommended? BTW this only contains db.a, I don't see db.lib. > h~ -- John **= Email 29 ==========================** Date: Wed, 06 Feb 2002 15:12:53 +0100 (MEZ) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: LUA40 On Wed, 6 Feb 2002 09:39:08 +0000, John Poltorak wrote: >I've never heard of LUA previously, and whilst it's good to see an OS/2 >version, I can't help but wonder why we need a new scripting lanaguage... >What does this have which REXX, Bash, Perl, Python, Snobol, Ruby etc etc >don't have? At a first glance LUA soonest looks like REXX with a bit more accessibility to lower-level structures. Sebastian **= Email 30 ==========================** Date: Wed, 6 Feb 2002 15:25:01 +0000 From: csaba.raduly at sophos.com Subject: Re: Perl test script failures On 06/02/2002 15:05:33 John Poltorak wrote: >On Wed, Feb 06, 2002 at 09:44:08AM -0500, Henry Sobotka wrote: >> The DB_File failures may be due not using the threadsafe version of >> db.lib from Ilya's site. > >Do you mean this:- > >http://www.math.ohio-state.edu/~ilya/software/os2/db_mt.zip > >Is it recommended? BTW this only contains db.a, I don't see db.lib. > Look into \emx\lib\omflibs.cmd It calls an emx utility (emxomf ?) to create .lib from .a for each of the EMX libs You can use that to produce a db_mt.lib -- 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 31 ==========================** Date: Wed, 06 Feb 2002 15:29:21 -0500 From: Henry Sobotka Subject: Re: Perl test script failures John Poltorak wrote: > > Is there any way to run these tests individually in isolation? Normally when you run "make test", your newly built perl and DLL are copied into /t to make sure you're testing it and not another one that may already be in your path. From there you can simply run, e.g. "perl op/magic.t". > Here I think the test must be flawed because of the REXX error msg. I'd > like to try running this test again after converting newlines on a number > of files to CRLF to see if it makes a difference, but have no idea how to > run this test... perl lib/rx_cmprt.t h~ **= Email 32 ==========================** Date: Wed, 6 Feb 2002 16:44:33 +0000 From: John Poltorak Subject: Re: Perl test script failures On Wed, Feb 06, 2002 at 02:56:42PM +0000, Lyn St George wrote: > On Wed, 6 Feb 2002 10:25:47 +0000, John Poltorak wrote: > > >Failed 5 test scripts out of 258, 98.06% okay. > > > > > >Is there anything I can do to improve this build? > > You need to get a working "multi-thread safe" db.lib. There is one > at http://www.ilyaz.org/software/os2/. Otherwise most of the other > tests either fail or are skipped for me too. OK I've added the new db.lib and am down to two (although it looks like three..) op/magic............. Process terminated by SIGINT lib/bigfltpm......... Process terminated by SIGPIPE FAILED at test 165 lib/rx_cmprt......... 1 +++ Call myfunc ? say 'ok 'myfunc1(1)myfunc2(2); REX0013: Error 13 running StartPerl, line 1: Invalid character in program REXX compartment returned non-zero status -13 at lib/rx_cmprt.t line 48. FAILED at test 16 Failed 2 test scripts out of 261, 99.23% okay. Has anyone looked at these fails? I'm not sure how to locate them but the REXX failure looks suspiciously like a Unix '\n' induced problem. REXX scripts fail with the error above when using CR instead of CRLF for line termination. > Cheers > Lyn St George > +--------------------------------------------------------------------------------- > + http://www.zolotek.net .. eCommerce hosting, consulting > + http://www.os2docs.org .. some 'How To' stuff ... > +---------------------------------------------------------------------------------- > -- John **= Email 33 ==========================** Date: Wed, 6 Feb 2002 17:04:14 +0000 From: John Poltorak Subject: Re: Perl test script failures On Wed, Feb 06, 2002 at 10:17:42AM -0500, Henry Sobotka wrote: > Not just recommended but essential for DB_File. Just run: > > emxomf -o db.lib db.a These file already exist as part of EMX. I guess it must be OK to overwrite them... Does db.h also need to be changed to correspond to these new files? > h~ -- John **= Email 34 ==========================** Date: Wed, 06 Feb 2002 17:37:18 +0000 From: "Lyn St George" Subject: Re: Perl test script failures On Wed, 6 Feb 2002 17:04:14 +0000, John Poltorak wrote: >On Wed, Feb 06, 2002 at 10:17:42AM -0500, Henry Sobotka wrote: > >> Not just recommended but essential for DB_File. Just run: >> >> emxomf -o db.lib db.a > >These file already exist as part of EMX. I guess it must be OK to >overwrite them... Yes, no problem. >Does db.h also need to be changed to correspond to these new files? No. They are both from version 1 of Berkeley DB (as reported by the perl install). I've been trying to build versions 3.x and 4.x but so far without success (or time to chase it down). You can get it from http://www.sleepycat.com if you want to try ... (Note that Berkeley DB from SleepyCat is different to the perl module BerkeleyDB from cpan) >> h~ > >-- >John Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 35 ==========================** Date: Wed, 6 Feb 2002 17:41:54 +0000 From: John Poltorak Subject: Long filenmes It has just been pointed out to me that GTAR has a '--posix' flag which supports 'long filenames'... The question is, what does 'long filenames' actually men? And is the definition different between OS/2 and Unix? I guess the definition on Unix will also differ between SVR4 and BSD... -- John **= Email 36 ==========================** Date: Wed, 06 Feb 2002 18:15:05 +0100 (CET) From: "Adrian Gschwend" Subject: Somewhat OT: C#, Mono and GNOME Hi all, I've just read an article about the future of GNOME. One of the developers writes why they decided to use C# in the future for many stuff in GNOME. When I heard that for the first time I was quite shocked because my normal anti MS-Genes in my body. Now the developer posted an email to the GNOME-Dev Mailinglist where he gives some more explanations about his idea. You can find the article at http://mail.gnome.org/archives/gnome-devel-list/2002-February/msg00042.h tml I still don't know exactly what I should think about this, expecially about C#. I do Java programming and I'm quite happy with it for a big range of applications (for sure not for everything). Did anyone out there had a closer look at the concept of C#? I haven't found the time to do so but I'm interested in other opinions about this concept. cu Adrian -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 37 ==========================** Date: Wed, 06 Feb 2002 18:38:33 +0000 (GMT) From: "Dave Saville" Subject: Re: Long filenmes On Wed, 6 Feb 2002 17:41:54 +0000, John Poltorak wrote: > >It has just been pointed out to me that GTAR has a '--posix' flag which >supports 'long filenames'... > >The question is, what does 'long filenames' actually men? And is the >definition different between OS/2 and Unix? > >I guess the definition on Unix will also differ between SVR4 and BSD... > In the messing with TAR the other day I noticed a comment to the effect that file name length had been doubled to 256 chars. IIRC. -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 38 ==========================** Date: Wed, 6 Feb 2002 18:38:44 +0100 From: Michael Zolk Subject: Re: installpkg bin.zip ? On Tue, Feb 05, 2002 at 09:55:04PM -0800, frank schmittroth wrote: [installpkg error message] > >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. Hmmm. I can't reproduce the error here. The bin package is installed successfully, without any error messages. Maybe you have got an older version? I plan to upload a newer version of ux2_base with a few minor updates soon (maybe tonight? :-) anyway. Maybe you can try this version. Michael -- **= Email 39 ==========================** Date: Wed, 6 Feb 2002 18:48:01 +0100 From: "Achim Hasenmueller" Subject: Re: Somewhat OT: C#, Mono and GNOME Hi, even though a Java vs .NET discussion is very much OT in this list, here are my comments. Java is: - a nice, flexible, convenient, familiar-looking programming language - a powerful, secure, fast, flexible virtual machine - a comprehensive, well designed, easy to use set of class libraries - an industry standard Microsoft .NET is: - C#, a programming language taking all the Java advantages and adding some more (after all, it's more recent) - a virtual machine like Java - a set of class libraries that are even more comprehensive and include more modern aspects (web services, etc.) - 100% supported by the industry leader One of Microsoft's main arguments is that .NET is language neutral. This is BS because Java is as well. In reality, Java is only used with one language but that's just because it's convenient. .NET is just the natural reaction after seeing where the market was going. Microsoft wanted to go down that route but of course not rely on "alien" technology and not being able to control it. The worst thing about .NET will be its tight integration with Windows. It will not have the portability aspect but Microsoft doesn't need that in reality (although they use it when publically talking about it). Technically, I think that .NET is excellent. But Java is as well and there is no need to replace it. And I don't like Microsoft. Kind regards / mit freundlichen Gruessen, Achim Hasenmueller InnoTek Systemberatung GmbH phon: +49 7151 9965-30 achimha at innotek.de http://www.innotek.de Germany InnoTek at the CeBIT fair (March 13-20, 2002, Hannover, Germany): Hall 4, booth A04 (IBM Partner booth), demo point D.03 **= Email 40 ==========================** Date: Wed, 6 Feb 2002 19:27:53 +0100 From: Holger Veit Subject: Re: Long filenmes On Wed, Feb 06, 2002 at 05:41:54PM +0000, John Poltorak wrote: > > It has just been pointed out to me that GTAR has a '--posix' flag which > supports 'long filenames'... > > The question is, what does 'long filenames' actually men? And is the > definition different between OS/2 and Unix? > > I guess the definition on Unix will also differ between SVR4 and BSD... Not having looked at the source code, but it seems to relate to the OS2ism of allowing a .longname extended attribute on FAT file systems to emulate >8.3 filenames there. There is a POSIX requirement of allowing longer names than 14 characters which has been the limit in stoneage UNIX (directory entry was 16 byte, minus 2 bytes for the inode number, leaving 14 bytes for a filename); that may also refer to this old problem. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 41 ==========================** Date: Wed, 6 Feb 2002 19:43:08 +0000 From: John Poltorak Subject: *Two* Linux standards Platforms With all the discussion about BSD and Linux standards, I've just read about the release of *two* Linux Standards Platforms, just to make everything even more complicated. See:- http://freestandards.org/news.php?id=25 If anyone is familiar with the Linux Standard Base (LSB) could you suggest what would be required to make UnixOS/2 LSB 1.1 compliant? -- John **= Email 42 ==========================** Date: Wed, 6 Feb 2002 19:50:50 +0100 (CET) From: Stefan Neis Subject: Re: GLIBC On Wed, 6 Feb 2002, John Drabik wrote: > > 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. :) > > Thank you for proving my point, which was, taking BSD code and > modifying it (and not returning the results to the community), will > result in mangled, incompatible systems. How will making the result available improve the situation? Why would BSD/Linux/whatever be interested in integrating patches which just obfuscate the whole issue and bring no progress to their system? And more specifically, why would they fix the remaining bugs? To put it differently: I'm not really a fan of the "one size fits all" philosophy. To take advantage of the individual strengths of the various operating systems, you have to admit for some differences. Ideally, autoconf/configure nicely takes care of them ... If everybody is moving in the same direction (no matter whether its MS or GLIBC or something else), choice is going to be limited or even unavailable at some later time. Support minorities, especially in the field of computers and software where majority/hype tells you strictly _nothing_ about quality. Anyway, AFAIK Holger's intention never was to take BSD libc and make some closed sourced LIBEMU from it. He could have played that kind of trick for XFree86 years ago. So this whole point breaks down anyway in our context. I rather put trust into the good intentions of porters than in some obscure licence which pretends to force people to act in a reasonable way. > Have you spent much time > trying to get a heterogeneous Doze/OS2/BSD network to "play > together"? It is a real mess. Apart from the subtle syntactic differences with respect to "route", what's the problem? Or have you been talking specifically about IPv6? > >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. > > Exactly. In no way did I intend to claim that every piece of code written on Linux is bad... But then, I wouldn't call code that has been written to be portable across various platforms "Linux code" just because that happens to be the platform where the programmer's editor is running most of the time. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 43 ==========================** Date: Wed, 6 Feb 2002 19:55:26 +0000 From: John Poltorak Subject: Re: Perl test script failures On Wed, Feb 06, 2002 at 01:35:36PM -0500, Henry Sobotka wrote: > Dug up my testlog from 5.6.1 and the first two results differ: > > op/magic............ok, 4/35 skipped: no caseless %ENV support > > The skipping comes from the else block to "if ($Is_MSWin32)" so I > haven't lost sleep over it. > > lib/bigfltpm........ok Hmmmm..... Is there any way to run these tests individually in isolation? If it works for you, I'd like it to work for me too. > With lib/rx_cmprt.t I got exactly the same result as you do. Here I think the test must be flawed because of the REXX error msg. I'd like to try running this test again after converting newlines on a number of files to CRLF to see if it makes a difference, but have no idea how to run this test... > h~ -- John **= Email 44 ==========================** Date: Wed, 6 Feb 2002 20:03:42 +0100 From: Holger Veit Subject: Re: GLIBC On Wed, Feb 06, 2002 at 07:50:50PM +0100, Stefan Neis wrote: [...] > Anyway, AFAIK Holger's intention never was to take BSD libc and make > some closed sourced LIBEMU from it. He could have played that kind LIBEMU and the IX.SYS driver (particularly this one, which I consider a template for writing (mostly) 32 bit PDDs - that's some teaching aspect) will be open source, and will have the free BSD-style license. This is a job I do for fun and personal satisfaction, not to earn some money later. I have some income from elsewhere. If I'd be interested in closed source to sell to all of you, I'd had started it in a different way - you would have seen eventually (likely much earlier than now; with faster progress) some advertising and some address where to buy it. I doubt, though, it would be too successful then. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 45 ==========================** Date: Wed, 6 Feb 2002 20:06:51 +0000 From: John Poltorak Subject: Re: installpkg bin.zip ? On Wed, Feb 06, 2002 at 11:55:53AM -0800, frank schmittroth wrote: > That does raise a question in my mind however. Is there some way to > distinguish the recommended vs. archival versions of various packages/ > programs in the unixos2.com directory tree? UnixOS/2 packages should be under:- ftp://unixos2.com/pub/unixos2/unixos2-current/unixos2 There is no versioning or archival at present. > Frank. > > ----------------------- > Frank Schmittroth > franks at owt.com > -- John **= Email 46 ==========================** Date: Wed, 6 Feb 2002 20:29:08 +0100 (CET) From: Stefan Neis Subject: Re: GLIBC On Wed, 6 Feb 2002, John Poltorak wrote: > consensus was that SlackWare was the most stable and mature, and its > package management was more easily portable to OS/2 than anything else > suggested. IIRC, the consensus rather was that SlackWare is at least not that much worse than anything else to justify further debates. As far as the packaging scheme goes, I still essentially agree, although those abbreviations like (AP), (DEV), (X) have a tendency of not being very helpful to those not familiar with the ugly details of Linux distros. > I thought Autoconf+friends were developed to simplify cross platform > developed so that code written on Linux could be rebuild on FreeBSD, > Solaris or anything else which had the relevant libraries. Essentially yes. _IF_ the application is written to use autoconf+friends and does take all the results into account. It's still easy to write code using something that's specific to one operating system and forgetting to add an autoconf-check for that feature and adding an alternative if it's not available. > > P.S.: Great, I finally managed to start a Linux/GNU vs. BSD war. :-( > > That's no problem. I'm an extreme neutral in this war and find it > interesting to hear both side of the argument. As long as it stays on the argument level, it's fine. Reading stuff implying it's all nonsense what I'm writing made me doubt that this would be the case. But I'm pleasantly surprised. ;-) > It should help to clarify > the format of the Unix-like environment we want on OS/2. Well, not really. We model the packaging after Slackware and essentially use BSD's libc for LIBEMU. Applications are more or less the same on all Unices, so which open questions are really left? We can start debating whether it was a good idea to use BSD's libc, but what's the point of it? Holger is doing (most of) the work on libc, so it's his decision anyway. It was just your wording ("aiming for GLIBC in the long term" or similar) which got me confused as it seemed to imply dropping LIBEMU in the long run (which isn't even finished yet) and replacing it by a glibc port. This seemed to be pure nonsense as it implies much work too get to a place where you already are. ;-) Plus I heartily dislike GNU's licences. I'm actively involved in distributing an application linked against GTK+ (one more LGPL'ed library) and we keep having all kinds of trouble with different versions of that library (It doesn't work? Oh you're using GTK+ version 1.2.(n-1)? Please upgrade to 1.2.n or at least copy the shared libs provided on our CD to some directory on your disk and modify LD_LIBRARY_PATH accordingly in the applications startup-script. Couple of days later, somebody else: Oh, you're using new GTK+ version 1.2.(n+1)? Let me check, I'll call you back. Yes, they did it again. Yet another subtle incompatibility. Please downgrade to 1.2.n or at least copy .... It's a support nightmare. But you're not allowed to link statically... (Plus in GTK's case, it doesn't even work correctly when linked statically). And it gets worse, when it comes to libstdc++ which could even be linked statically licence-wise but doing so while other libraries are supposed to be linked dynamically is a nightmare in its own right... And once you start supporting different glibc versions, it becomes even more trying - at least the rate of (incompatible) changes considerably slowed down lately. Well, enough of all that whining about (L)GPL, thanks for listening. Stefan **= Email 47 ==========================** Date: Wed, 06 Feb 2002 21:44:29 -0600 From: Jeff Robinson Subject: Re: *Two* Linux standards Platforms Sometimes I just can't stop thinking of the saying: "Standards are great. There are so many to choose from!" Jeff. Off topic again. John Poltorak wrote: > > With all the discussion about BSD and Linux standards, I've just read > about the release of *two* Linux Standards Platforms, just to make > everything even more complicated. See:- > > http://freestandards.org/news.php?id=25 > > If anyone is familiar with the Linux Standard Base (LSB) could you suggest > what would be required to make UnixOS/2 LSB 1.1 compliant? > > -- > John -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 48 ==========================** Date: Wed, 6 Feb 2002 22:09:38 +0100 From: Holger Veit Subject: Re: GLIBC On Thu, Feb 07, 2002 at 12:43:26AM -0500, Stepan Kazakov wrote: > Holger Veit wrote: > > > > > LIBEMU and the IX.SYS driver (particularly this one, which I consider > > is LIBEMU will support new TCP stacks (>=4.1) through TCPIP32.DLL ? > working through SO32DLL.DLL limited emx to 2048 sockets max, > but through TCPIP32.DLL - no limit. This discussion was already (not for the technical issue of the # of sockets) one or two weeks ago. Check the archive. Has anyone seen official documentation on TCPIP32.DLL yet? > so currently all emx programs limited to 2048 sockets max, and its > hardcoded into emxdll.asm & emxdll.h by: > > #define MAX_SOCKETS 2048 > extern ULONG sock_proc_count[MAX_SOCKETS]; At the time EMX was coined, that was the limit. -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection)