From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 7 Feb 2002 04:14:40 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 128 ************************************************** Wednesday 06 February 2002 Number 128 ************************************************** Subjects for today 1 Re: GLIBC : John Drabik" 2 Re: GLIBC : Stepan Kazakov 3 Re: GLIBC : Stepan Kazakov 4 Re: Scilab : Alex Newman" 5 Re: Perl test script failures : John Poltorak 6 Re: installpkg bin.zip ? : John Poltorak 7 Re: GLIBC : Holger Veit 8 Re: Perl test script failures : Lyn St George" 9 Re: Perl test script failures : John Poltorak 10 gcc 3.0.2 status : John Poltorak 11 Re: Perl test script failures : Henry Sobotka 12 Re: TCPIP32.DLL : Gerhard Arnecke" 13 Re: Perl test script failures : Henry Sobotka 14 Re: TCPIP32.DLL : John Poltorak 15 Re: Perl test script failures : Henry Sobotka 16 STLport 4.5.1 and gcc 3.0.2 : MS" 17 Re: Perl test script failures : John Poltorak 18 Re: TCPIP32:DLL : Gerhard Arnecke" 19 Re: TCPIP32.DLL : John Poltorak 20 Re: Perl test script failures : John Poltorak 21 Re: TCPIP32.DLL : nick" 22 Re: TCPIP32.DLL : Stepan Kazakov 23 Re: TCPIP32.DLL : Sergey I. Yevtushenko" 24 Re: TCPIP32.DLL : nick" 25 Re: TCPIP32.DLL : Stepan Kazakov **= Email 1 ==========================** Date: Thu, 07 Feb 2002 00:38:14 -0700 (MST) From: "John Drabik" Subject: Re: GLIBC On Wed, 6 Feb 2002 19:50:50 +0100 (CET), Stefan Neis wrote: >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? By allowing others to: a) use the SAME code across all systems, or at least code defensively b) let others see the purposeful incompatibilities, and DO something about them quickly c) put an end to "security" through obscurity, and near-theft of intellectual advances made by others d) improve code e) shame coders into producing better systems; God knows the DoJ, the legal system in general, and even being found guilty of breaking the law has not changed them f) demonstrate the technical basis for bugs which unscrupulous vendors either claim will not be exploited, or which they refuse to admit and correct. g) allow all systems to offer the same "features" at the same time, without forcing legions of people to reverse engineer the "extensions" added by programmers that are hell-bent on creating incompatibilities without adding value. Remember, the keeper can choose to reject changes. And I have infinitely more confidence in the likes of Linus or Alan Cox, than I do in hordes of anti-trust-violating coders with no names, no accountability, and no reason to improve their OWN code. h) remove the hammerlock that unscrupulous companies use to lock out competition i) this could be a very looonnnggg list. 'Nuf said. >Why would BSD/Linux/whatever be interested in integrating patches which >just obfuscate the whole issue and bring no progress to their system? At least the CHOICE would be theirs under GPL. No such guarantee with BSD. In the same vein as your argument, why should BSD/Linux/whatever be forced to incorporate code months or years later to handle those same issues (they WILL have to just to deal with heterogeneous networks at least), without compensation or access to their OWN code base, while some unscrupulous company makes millions off of their labor? To add insult to injury, where do you see the BSD credit on the likes of, say, Windows? So the BSD license isn't being honored either. >And more specifically, why would they fix the remaining bugs? Pride of authorship, something you never get from proprietary code vendors, or from thieves who steal code and try to pretend it's their own. Open source coders have the courage to put their name on their "product". >> 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? IPv6 is part of it. So are cross-platform differences such as case sensitivity or not (and the effect on, say, passwords), security issues, port 139 and other NetBIOS/NetBEUI bogosity, etc.. If the differences were limited to "route" syntax, there would not be so many articles written on getting these systems, which all claim to be based on BSD, to work together. Have you tried to get OS/2 and W2K to work together WITHOUT the patches needed to get around purposeful incompatibilities (yet remember, both were derived from BSD)? Good luck. Open source and GPL help end proprietary strangleholds; they do ***NOT*** preclude commercialization, extension, or improvement. John **= Email 2 ==========================** Date: Thu, 07 Feb 2002 00:43:26 -0500 From: Stepan Kazakov Subject: Re: GLIBC 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. 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]; -- madded. [Red Hot Chili Hackers] **= Email 3 ==========================** Date: Thu, 07 Feb 2002 01:32:36 -0500 From: Stepan Kazakov Subject: Re: GLIBC Holger Veit wrote: > Has anyone seen official documentation on TCPIP32.DLL yet? only standart toolkit/2. without socketpair() call.. also i disassembled tcpip32.dll & sockets.sys.. ;) -- madded. [Red Hot Chili Hackers] **= Email 4 ==========================** Date: Thu, 07 Feb 2002 07:55:36 +1100 (EDT) From: "Alex Newman" Subject: Re: Scilab I have had the source on my machine for some weeks now, but until I can resolve my shell/make/gtk+ (= gtk v. 2.0) problems, I won't be able to attempt anything. On the other hand, Octave has already been ported to OS/2: it gives a pretty useful mathematical and statistical coverage, and already has many of the features mentioned below. Worth checking out. Alex. On Wed, 6 Feb 2002 14:59:10 +0000, John Poltorak wrote: > > > 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 5 ==========================** Date: Thu, 7 Feb 2002 09:20:24 +0000 From: John Poltorak Subject: Re: Perl test script failures On Wed, Feb 06, 2002 at 03:29:21PM -0500, Henry Sobotka wrote: > 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". Thanks for the explanation. I can now pinpoint the error here:- lib/bigfltpm......... Process terminated by SIGPIPE FAILED at test 165 Does this indicate what is missing from my environment? :- 1..370 ok 1 ok 164 not ok 165 # '$x = new Math::BigFloat "-0.0065";0+$x->ffround(-3);' expected: /-0\.006|-7e-03/ got: '-6e-03' ok 166 ok 370 > > 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 Or even:- perl -d lib.rx_cmprt.t which reveals that the error is here:- sub MYFUNC1 {shift} sub MYFUNC2 {3 * shift} REXX_eval_with "call myfunc say 'ok 'myfunc1(1)myfunc2(2)", myfunc => sub { register qw(myfunc1 myfunc2) }; Unfortunately this is so obfuscated that I don't have a clue what is being attempted, but since it is a REXX test it ought to work on OS/2. Can anyone explain how this is supposed to get converted into REXX or provide the equivalent REXX code? Presumably some temporary REXX code is generated... If so is there anywhere I can see it? > h~ -- John **= Email 6 ==========================** Date: Thu, 7 Feb 2002 09:44:57 +0000 From: John Poltorak Subject: Re: installpkg bin.zip ? On Wed, Feb 06, 2002 at 01:47:56PM -0800, frank schmittroth wrote: > 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 > > 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/ I don't know anything about that. Maybe the site maintainer could clarify what should go there... > 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? AIUI the distro is being built up under unixos2-current. At some point there will be a cut-off and a snapshot of what was there will become release 1 and the next release will continue to get built up under current. However we are still at an early stage and I'm not sure how things will pan out. Also the procedure is not set in stone and subject to being completely replaced with something entirely different if someone comes up with better ideas... > Frank. > > ----------------------- > Frank Schmittroth > franks at owt.com > -- John **= Email 7 ==========================** Date: Thu, 7 Feb 2002 10:00:29 +0100 From: Holger Veit Subject: Re: GLIBC On Thu, Feb 07, 2002 at 12:38:14AM -0700, John Drabik wrote: > On Wed, 6 Feb 2002 19:50:50 +0100 (CET), Stefan Neis wrote: [...] > >How will making the result available improve the situation? > > By allowing others to: [...longlist...] IT prophets have already declared Linux to be the only Unix OS still existing in a few years. This is sound, but you should be aware of the consequences as well: - monoculture has always been a bad thing, with proprietary systems as well as with open source ones - nowadays, 99% of all viri/worms/trojans are for WinXX, tendency to build root kits, hacker tools, spy software not just running under Linux but actively attacking Linux systems (particularly the loser-friendly out-of-the-CD-box installable ones). Expect Linux to become as user friendly as Windows, and as open as it in soem years. Security is not a technical issue; a system is only as secure as the 'problem between keyboard and chair'. The monoculture problem is best demonstrated with OS/2: do you see any viri or worms for OS/2? I don't - this is because OS/2 is, admittedly, not or no longer a mainstream OS. If I were malevolent and would find a security leak in some open source code, I wouldn't loudly publish it but wait whether it will spread, and then use it for a controlled attack. The idea that open source is read by bazillions of people in the world, so fixes would be made almost immediately, is a popular myth; it has been disproven multiple times already in the past - Linux kernels (2.4.x; x<10), PGP, Mozilla, XFree86, are prominent examples of large packages where this happened, even multiple time. There is no such control by the community; and not even if OSS becomes more popular. If everyone has, say, finally one of those glorious Linux systems on his desktop, why would any of them a) contribute experiences, b) fix code c) even read the kernel code? "We just want to work with that Pee-Cee". The number of active people to be able to do such work is constant, and even more important: if everyone plays with the same code, it will become unattractive: humans do everything to be individual - different from everyone else, unique. With popular packages the claims are already made and fixed: try, as an individual, to get a significant change into a large system like the Linux kernel; you'll very very likely stomp onto feet of "core developers" who don't want you outsider to spoil their play. Partly this is why I am not much interested in ongoing plays with fashion systems like Linux. I just use them, like a car or a toaster. Open source in a community of "only-users" is rather worthless slack; it is there like EDLIN in DOS; installed but never used. Source code for non-programmers is like Finnish documentation for Englishmen. The few who are skilled to read it have typically other jobs to spend their time with. > >Why would BSD/Linux/whatever be interested in integrating patches which > >just obfuscate the whole issue and bring no progress to their system? > > At least the CHOICE would be theirs under GPL. No such guarantee > with BSD. In the same vein as your argument, why should > BSD/Linux/whatever be forced to incorporate code months or years Users won't care about the source code at all; programmers (!= fanatics) are very much concerned about their intellectual property if they have to make their living with it. So they tend to avoid GPL code like the plague GNU were totally unsuccesful without LGPL. GPL is ruled by envy, BSD is ruled by artist- or craftmanship. With a BSD license, I am proud to have produced some piee of work, and if I see the mandatory "BSD copyright by me" in foreign code, it is okay. With GPL, I give out code but still want to control and rule others what they should do with it - if they'd just use it in own projects, I could lose something. What do I lose then at all? I could have better sold my code to them, if compensation were the problem. > later to handle those same issues (they WILL have to just to deal > with heterogeneous networks at least), without compensation or access > to their OWN code base, while some unscrupulous company makes > millions off of their labor? To add insult to injury, where do you > see the BSD credit on the likes of, say, Windows? So the BSD license > isn't being honored either. That's an issue of the Berkeley University if they don't care about their TCP/IP stack code, not mine. But as explained above: I do see that there is code created by "me" in some software like Windows. That is enough. The 100 or so bytes saying "Copyright by...." in a file are irrelevant, as noone except me will likely search for them. If I were Picasso (now, I wouldn'be alive any more, then, but assume that) I'd *see* if someone had painted a similar picture as Guernica; even though it were a foreign artwork, I could still see *my* idea, my handwriting, my style, and I know others will observe this as well. This is sufficient: that some people can see that Windows "inherited" some BSD code. Most people don't see anything at all, and don't care about anything - so what? What would I gain? Rumour? What for? Money? Why then haven't I sold the stuff? > >And more specifically, why would they fix the remaining bugs? > > Pride of authorship, something you never get from proprietary code > vendors, or from thieves who steal code and try to pretend it's their > own. Open source coders have the courage to put their name on their > "product". How many people are involved in Linux or FreeBSD development? Somewhere in FreeBSD there is still some code from me, and maybe there is even a name mentioned in the header of the file. No user will ever see this normally. So what product am I proud of? 0.000001% of FreeBSD is "mine"? 0.000001% of this earth is mine: I have recently bought a piece of land, with a house. Great! I don't need some kind of *have* to define myself, I *am*. > IPv6 is part of it. So are cross-platform differences such as case > sensitivity or not (and the effect on, say, passwords), security > issues, port 139 and other NetBIOS/NetBEUI bogosity, etc.. If the > differences were limited to "route" syntax, there would not be so > many articles written on getting these systems, which all claim to be > based on BSD, to work together. Have you tried to get OS/2 and W2K > to work together WITHOUT the patches needed to get around purposeful > incompatibilities (yet remember, both were derived from BSD)? Good > luck. > > Open source and GPL help end proprietary strangleholds; they do > ***NOT*** preclude commercialization, extension, or improvement. They rather lead to incompatible "workarounds". They show Microsoft and others how the TCP/IP code is written, and what they need to do to circumvent in order to push a proprietary solution on the market. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 8 ==========================** Date: Thu, 07 Feb 2002 10:02:26 +0000 From: "Lyn St George" Subject: Re: Perl test script failures On Thu, 7 Feb 2002 09:20:24 +0000, John Poltorak wrote: >On Wed, Feb 06, 2002 at 03:29:21PM -0500, Henry Sobotka wrote: >> 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". > >Thanks for the explanation. I can now pinpoint the error here:- > >lib/bigfltpm......... >Process terminated by SIGPIPE >FAILED at test 165 > >Does this indicate what is missing from my environment? :- > >1..370 >ok 1 >ok 164 >not ok 165 ># '$x = new Math::BigFloat "-0.0065";0+$x->ffround(-3);' expected: /-0\.006|-7e-03/ got: '-6e-03' >ok 166 >ok 370 My result is identical - is it anything worth worrying about?? >> > 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 > >Or even:- > >perl -d lib.rx_cmprt.t > > >which reveals that the error is here:- > >sub MYFUNC1 {shift} >sub MYFUNC2 {3 * shift} >REXX_eval_with "call myfunc > say 'ok 'myfunc1(1)myfunc2(2)", > myfunc => sub { register qw(myfunc1 myfunc2) }; > > >Unfortunately this is so obfuscated that I don't have a clue what is being >attempted, but since it is a REXX test it ought to work on OS/2. These above are the last 4 lines of rx_cmprt.t. When I run perl -d lib\rx_cmprt.t I get this: ====== 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. ====== if I knew where to find 'StartPerl' ... there's no file under that name anywhere, so it must refer to something else ? >Can anyone explain how this is supposed to get converted into REXX or >provide the equivalent REXX code? > >Presumably some temporary REXX code is generated... If so is there >anywhere I can see it? > > >> h~ > > >-- >John > > Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 9 ==========================** Date: Thu, 7 Feb 2002 10:22:52 +0000 From: John Poltorak Subject: Re: Perl test script failures On Thu, Feb 07, 2002 at 10:02:26AM +0000, Lyn St George wrote: > >lib/bigfltpm......... > >Process terminated by SIGPIPE > >FAILED at test 165 > > > >Does this indicate what is missing from my environment? :- > > > >1..370 > >ok 1 > >ok 164 > >not ok 165 > ># '$x = new Math::BigFloat "-0.0065";0+$x->ffround(-3);' expected: /-0\.006|-7e-03/ got: '-6e-03' > >ok 166 > >ok 370 > > My result is identical - is it anything worth worrying about?? I have no idea, but Henry doesn't get it. In my simple view of these things, tests are run for good reasons. Passing is good, failing is bad. Henry gets a better pass mark than me so must have a better Perl build. > >perl -d lib.rx_cmprt.t > > > > > >which reveals that the error is here:- > > > >sub MYFUNC1 {shift} > >sub MYFUNC2 {3 * shift} > >REXX_eval_with "call myfunc > > say 'ok 'myfunc1(1)myfunc2(2)", > > myfunc => sub { register qw(myfunc1 myfunc2) }; > > > > > >Unfortunately this is so obfuscated that I don't have a clue what is being > >attempted, but since it is a REXX test it ought to work on OS/2. > > > These above are the last 4 lines of rx_cmprt.t. When I run perl -d lib\rx_cmprt.t > I get this: > ====== > 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. > ====== You get this sort of error from a program such as:- /* */ say 'hello, world' if you save it as a Unix file and try running it. > if I knew where to find 'StartPerl' ... there's no file under that name anywhere, > so it must refer to something else ? Config.pm contains the line:- startperl='#!c:/usr/lib/perl/bin/perl' so I guess it simply being used as an alias... > Cheers > Lyn St George > +--------------------------------------------------------------------------------- > + http://www.zolotek.net .. eCommerce hosting, consulting > + http://www.os2docs.org .. some 'How To' stuff ... > +---------------------------------------------------------------------------------- > -- John **= Email 10 ==========================** Date: Thu, 7 Feb 2002 10:59:47 +0000 From: John Poltorak Subject: gcc 3.0.2 status What is the status of gcc v3.0.2? The beta version has been available for over two months. When is it expected to be released? -- John **= Email 11 ==========================** Date: Thu, 07 Feb 2002 11:38:11 -0500 From: Henry Sobotka Subject: Re: Perl test script failures John Poltorak wrote: > > In my simple view of these things, tests are run for good reasons. > Passing is good, failing is bad. Henry gets a better pass mark than me so > must have a better Perl build. More likely a coniguration difference. Here I turned on the use of long long for 64-bit types so that perl -V:i64type returns i64type='long long' Similarly u64type='unsigned long long'. Ditto for quadtype and uquadtype. There are at least a dozen other variables in Config.pm related to this feature. Turning it on shows up as one of the options when you step through Configure rather than simply use the default values. > > if I knew where to find 'StartPerl' ... there's no file under that name anywhere, > > so it must refer to something else ? > > Config.pm contains the line:- > > startperl='#!c:/usr/lib/perl/bin/perl' > > so I guess it simply being used as an alias... You'll find that explained farther down in the pod section of Config.pm as: This variable contains the string to put on the front of a perl script to make sure (hopefully) that it runs with perl and not some shell. Of course, that leading line must be followed by the classical perl idiom: eval 'exec perl -S $0 ${1+$ at }' if $running_under_some_shell; to guarantee perl startup should the shell execute the script. Note that this magic incatation is not understood by csh. h~ **= Email 12 ==========================** Date: Thu, 07 Feb 2002 13:04:18 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: TCPIP32.DLL Conc. functions in TCPIP32.DLL: One can find programming advices and other informations in WINSOC11.INF which is involved in Warp 4.0 and 4.5 toolkit. One one can access through: http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?../html/book/Toolkt40/WINSOC11.IN F GA **= Email 13 ==========================** Date: Thu, 07 Feb 2002 13:17:07 -0500 From: Henry Sobotka Subject: Re: Perl test script failures John Poltorak wrote: > > Is there any way to get hold of your Config.pm? It's a 7000 line file so > posting it here isn't a good idea. If you have a copy of the binary package I put on Hobbes, it's in there. Otherwise I can email it to you to spare you the download. h~ **= Email 14 ==========================** Date: Thu, 7 Feb 2002 14:29:49 +0000 From: John Poltorak Subject: Re: TCPIP32.DLL On Thu, Feb 07, 2002 at 01:04:18PM +0100, Gerhard Arnecke wrote: > Conc. functions in TCPIP32.DLL: > > One can find programming advices and other informations in WINSOC11.INF which is > involved in Warp 4.0 and 4.5 toolkit. > > One one can access through: > > http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?../html/book/Toolkt40/WINSOC11.IN > F Is it possible to develop a third party replacement of TCPIP32.DLL? If so could this be a route to providing support for IPv6 since IBM seems to be reluctant to do this for OS/2? > GA > > > -- John **= Email 15 ==========================** Date: Thu, 07 Feb 2002 16:03:52 -0500 From: Henry Sobotka Subject: Re: Perl test script failures John Poltorak wrote: > > I notice that yours is compiled with pgcc 2.95.2 whereas I'm using > gcc 2.8.1. Is that likely to account for many differences where you have > 'define' and I have 'undef'? eg. i_fcntl, use64bitint... osvers is even > different, you have 4.5, I have 2.45. I noticed that Configure's library-checking routine, which IIRC tries to use nm, was producing faulty values, so I went through the variables in config.sh one by one, making whatever adjustments were necessary. This included those for the various build utilities as it facilitates building and/or installing CPAN modules that might use them and simply check the value in Config.pm rather than search the user's PATH. The uname distributed with bash returns 4.50; the one with gnu shell utilities 2.45. The latter is the official IBM versioning returned by DosQuerySysInfo; the former is common usage. A difference in porter preferences. h~ **= Email 16 ==========================** Date: Thu, 07 Feb 2002 17:08:24 +0100 (MEZ) From: "MS" Subject: STLport 4.5.1 and gcc 3.0.2 Hello people, I am trying to compile stlport version 4.5.1 with gcc 3.0.2. Wrapper mode does not work with this version off gcc because it implements Koenig lookup. This results in the necessity to use stlport's iostreams instead of the compiler's native ones. However, I have some trouble compiling it. There is a section in ./stlport/cwchar which goes like this: _STLP_BEGIN_NAMESPACE # ifdef _STLP_NO_WCHAR_T typedef int wint_t; # else // gcc 3.0 has a glitch : wint_t only sucked into the global namespace if _GLIBCPP_USE_WCHAR_T is defined # if defined (__GNUC__) && ! defined (_GLIBCPP_USE_WCHAR_T) using ::wint_t; # else using _STLP_VENDOR_CSTD::wint_t; # endif # endif using _STLP_VENDOR_CSTD::size_t; ... Since __GNUC__ is defined and _GLIBCPP_USE_WCHAR_T has not been defined, it tries to use the line using ::wint_t; which fails, probably because we are in a different namespace then std. So my question is: should _GLIBCPP_USE_WCHAR_T have been defined anywhere? In D:/DEVEL/C/EMX/include/g++-v3/i386-pc-os2_emx/bit/c++config.h it is not undefined, but what does it mean? Is it a bug, or is this okay? Also, it seems gcc3.0.2 is defining the symbols __unix and unix, in contrast to gcc2.95.3. Is this a bug or a feature? And another: Has it been decided what symbol will be used to distinguish unixos/2? Just __unix__ and __OS2__? Regards, Martin Schafföner **= Email 17 ==========================** Date: Thu, 7 Feb 2002 17:30:08 +0000 From: John Poltorak Subject: Re: Perl test script failures On Thu, Feb 07, 2002 at 11:38:11AM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > In my simple view of these things, tests are run for good reasons. > > Passing is good, failing is bad. Henry gets a better pass mark than me so > > must have a better Perl build. > > More likely a coniguration difference. Here I turned on the use of long > long for 64-bit types so that > > perl -V:i64type > > returns > > i64type='long long' > > Similarly u64type='unsigned long long'. Ditto for quadtype and > uquadtype. There are at least a dozen other variables in Config.pm > related to this feature. Turning it on shows up as one of the options > when you step through Configure rather than simply use the default > values. The values you have for these variables must be the defaults as I have the same... Can you suggest what I should change to preven this error when doing the bigfltpm.t test? Here's what I get:- not ok 165 # '$x = new Math::BigFloat "-0.0065";0+$x->ffround(-3);' expected:/-0\.006|-7e-03/ got: '-6e-03' Is there any way to get hold of your Config.pm? It's a 7000 line file so posting it here isn't a good idea. > h~ -- John **= Email 18 ==========================** Date: Thu, 07 Feb 2002 18:18:42 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: TCPIP32:DLL Conc. the question for programming a new TCPIP32.DLL This work was already done in Japan. This page l shows it as an EMX version: http://www.omronsoft.co.jp/~yamasita/gn/gn-1.40/os2/tcpip32.html There is an e-mail address on this side. One can try to contact the administrator. GA **= Email 19 ==========================** Date: Thu, 7 Feb 2002 19:01:23 +0000 From: John Poltorak Subject: Re: TCPIP32.DLL On Thu, Feb 07, 2002 at 09:13:01PM -0500, Stepan Kazakov wrote: > > If so could this be a route to providing support for IPv6 since IBM seems > > to be reluctant to do this for OS/2? > > hmm. > OS/2 TCP/IP stack consist of 2 drivers: afinet[k].sys & sockets[k].sys > all stack code & data - inside these drivers. Are these the only files which would need changing? How easy is it to write these drivers? > -- > madded. [Red Hot Chili Hackers] -- John **= Email 20 ==========================** Date: Thu, 7 Feb 2002 19:59:20 +0000 From: John Poltorak Subject: Re: Perl test script failures On Thu, Feb 07, 2002 at 01:17:07PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > Is there any way to get hold of your Config.pm? It's a 7000 line file so > > posting it here isn't a good idea. > > If you have a copy of the binary package I put on Hobbes, it's in there. > Otherwise I can email it to you to spare you the download. OK, I've downloaded it compared it with mine and am surprised at just how many differences there are... After removing differences related to PERl_HOME and EMX_DRIVE, 116 lines differ. I notice that yours is compiled with pgcc 2.95.2 whereas I'm using gcc 2.8.1. Is that likely to account for many differences where you have 'define' and I have 'undef'? eg. i_fcntl, use64bitint... osvers is even different, you have 4.5, I have 2.45. Do you have a specific build script where a number of environment variables are set? For instance you have settings for tail, tar, test, tee, etc. whereas mine are all set to null even though they are on the path. I can see that getting a standard UnixOS/2 build together will be a very tricky business. > h~ -- John **= Email 21 ==========================** Date: Thu, 07 Feb 2002 20:09:01 +0300 (MSK) From: "nick" Subject: Re: TCPIP32.DLL On Thu, 7 Feb 2002 14:29:49 +0000, John Poltorak wrote: >Is it possible to develop a third party replacement of TCPIP32.DLL? yes, of course ;) >If so could this be a route to providing support for IPv6 since IBM seems >to be reluctant to do this for OS/2? Not exactly. By writing only tcpip32.dll we can realize only incapsulation ipv6->ipv4 packets for routing ipv6 via ipv4 network. To do complete support for ipv6 we need to write additional driver to sockets.sys/afinet.sys to send selfcooked ethernet packets directly. Faithfully Yours, Nick **= Email 22 ==========================** Date: Thu, 07 Feb 2002 21:13:01 -0500 From: Stepan Kazakov Subject: Re: TCPIP32.DLL John Poltorak wrote: > Is it possible to develop a third party replacement of TCPIP32.DLL? no problem. > If so could this be a route to providing support for IPv6 since IBM seems > to be reluctant to do this for OS/2? hmm. OS/2 TCP/IP stack consist of 2 drivers: afinet[k].sys & sockets[k].sys all stack code & data - inside these drivers. tcpip32.dll - only interface to drivers API for ring3 applications.. (also old APIs in 32-bit so32dll.dll+tcp32dll.dll & 16-bit tcpipdll.dll) -- madded. [Red Hot Chili Hackers] **= Email 23 ==========================** Date: Thu, 07 Feb 2002 22:28:59 +0200 (EET) From: "Sergey I. Yevtushenko" Subject: Re: TCPIP32.DLL On Thu, 07 Feb 2002 23:53:55 -0500, Stepan Kazakov wrote: >> > hmm. >> > OS/2 TCP/IP stack consist of 2 drivers: afinet[k].sys & sockets[k].sys >> > all stack code & data - inside these drivers. >> Are these the only files which would need changing? How easy is it to >> write these drivers? > >We can use BSD* stack sources for example. >We can write own stack, but it must be compatible with existing MPTS system, >for working with standart OS/2 netcard drivers and other OS/2 net protocols (netbeui, ipx..). >And i think there is a great problem with native IBM TCPBEUI. I think this is not necessary. Just keep standard NDIS stack as it is and all other protocols will work as usual. Everything you need is to write your own NDIS protocol driver and connect to stack just like other protocols do. >So, the main problem - very poor documentation on OS/2 MPTS interfaces.. If you mean standard NDIS interface, then it is documented in NDIS specs version 2.01. It _is_ complete and _is_ enough to write protocol drivers. In fact, even DDK samples are not very helpful for that. >Ofcourse, IDA can help ;) Regards, Sergey. *-------------------------------------- ES at Home **= Email 24 ==========================** Date: Thu, 07 Feb 2002 23:48:05 +0300 (MSK) From: "nick" Subject: Re: TCPIP32.DLL On Thu, 07 Feb 2002 23:53:55 -0500, Stepan Kazakov wrote: >John Poltorak wrote: > >> > hmm. >> > OS/2 TCP/IP stack consist of 2 drivers: afinet[k].sys & sockets[k].sys >> > all stack code & data - inside these drivers. >> Are these the only files which would need changing? How easy is it to >> write these drivers? > >We can use BSD* stack sources for example. >We can write own stack, but it must be compatible with existing MPTS system, >for working with standart OS/2 netcard drivers and other OS/2 net protocols (netbeui, ipx..). >And i think there is a great problem with native IBM TCPBEUI. Thats why i think that not replacing those drivers but adding the third one specially for ipv6 and some other features can be a good compromise. Faithfully Yours, Nick **= Email 25 ==========================** Date: Thu, 07 Feb 2002 23:53:55 -0500 From: Stepan Kazakov Subject: Re: TCPIP32.DLL John Poltorak wrote: > > hmm. > > OS/2 TCP/IP stack consist of 2 drivers: afinet[k].sys & sockets[k].sys > > all stack code & data - inside these drivers. > Are these the only files which would need changing? How easy is it to > write these drivers? We can use BSD* stack sources for example. We can write own stack, but it must be compatible with existing MPTS system, for working with standart OS/2 netcard drivers and other OS/2 net protocols (netbeui, ipx..). And i think there is a great problem with native IBM TCPBEUI. So, the main problem - very poor documentation on OS/2 MPTS interfaces.. Ofcourse, IDA can help ;) -- madded. [Red Hot Chili Hackers]