From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 17 Jan 2003 04:48:30 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 16 ************************************************** Thursday 16 January 2003 Number 16 ************************************************** Subjects for today 1 Re: UnixOS/2 Build System - mailing list : John Poltorak 2 Re: How to identify OS/2 from shell script : John Poltorak 3 Re: Python home directory : Andrew MacIntyre 4 glibc completion : Bart van Leeuwen" 5 Re: glibc completion : John Poltorak 6 Re: Testing for LINK386 on path : John Poltorak 7 Re: ZLIB : John Poltorak 8 Re: ZLIB : John Poltorak 9 Re: Testing for LINK386 on path : Stefan Neis 10 Re: ZLIB : Stefan Neis 11 Re: glibc completion : Stefan Neis 12 Re: Testing for LINK386 on path : Stefan Neis 13 Re: How to identify OS/2 from shell script : Stefan Neis 14 Re: ZLIB : Stefan Neis 15 Re: UnixOS/2 Build System - mailing list : John Poltorak 16 Re: UnixOS/2 Build System - mailing list : Yuri Dario" 17 Re: UnixOS/2 Build System - mailing list : Steve Wendt 18 Re: glibc completion : Adrian Gschwend" 19 Re: How to identify OS/2 from shell script : Adrian Gschwend" 20 Re: glibc completion : Bart van Leeuwen" 21 Mailman 2.0.13 final is out! : Ted Sikora 22 Re: ZLIB : Franz Bakan" 23 Security/2 updated : nickk" 24 Re: ZLIB : John Poltorak **= Email 1 ==========================** Date: Fri, 17 Jan 2003 09:37:36 +0000 From: John Poltorak Subject: Re: UnixOS/2 Build System - mailing list On Thu, Jan 16, 2003 at 11:32:23PM +0100, Yuri Dario wrote: > Hi John, > > >A new mailing list has been set up specifically to test out and extend the > >UnixOS/2 Build System and everyone is invited to join. > > I'm sorry, but why another list? isn't this one enough? Yuri, When some of us were trying to get Perl 5.8.0 working around six months ago, a number of people were complaining about the high volume of traffic on this list and said it should be split. A number of people also left the list at the time. The other list will be much more narrowly focused and I anticipate periods when traffic levels will be high as participants report feedback on various tests. > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ -- John **= Email 2 ==========================** Date: Fri, 17 Jan 2003 09:46:26 +0000 From: John Poltorak Subject: Re: How to identify OS/2 from shell script On Thu, Jan 16, 2003 at 11:17:47PM +0100, Sebastian Wittmeier (ShadoW) wrote: > On Thu, 16 Jan 2003 21:01:22 +0000, John Poltorak wrote: > > >if `ver`="Operating System/2" ? > > And tomorrow ver says "eComStation x.y" > or "OSFree 0.x running on FreeOS 0.y" Hmmm... yes this is like to cause a major problem which I had not anticipated. What will 'uname -s' show for these two? > Sebastian -- John **= Email 3 ==========================** Date: Fri, 17 Jan 2003 11:56:02 +1100 (EST) From: Andrew MacIntyre Subject: Re: Python home directory On Mon, 13 Jan 2003, Ted Sikora wrote: > John Poltorak wrote: > > Where does Python normally get installed on a Unix system? I'm assuming an > > FHS compliant location, BTW. > > /usr > > > > > Is there any reason why the OS/2 port would not work if installed in the > > same location? - given that the DLL is on the libpath and the required > > environment variables are set correctly... > > > None provided the env settings reflect this. > > . but Andrew prefers /Apps as does Apache so it just made things > neater. I have Zope and MySQL there too. Makes backups and migrations a > snap. Unzip and run. I don't actually have a preference, but Python should work fine as long as:- - python22.dll is in the LIBPATH - PYTHONHOME points to the root of the Python installation - PYTHONPATH contains at least the following: %PYTHONHOME%/Lib;%PYTHONHOME%/Lib/plat-os2emx;\ %PYTHONHOME%/Lib/lib-dynload;%PYTHONHOME%/Lib/site-packages Strictly speaking, the site-packages reference isn't required until you add some 3rd-party Python packages, most of which go into the %PYTHONHOME%/Lib/site-packages directory. On Unix, Python's default install is to /usr/local:- - /usr/local/bin (executables) - /usr/local/lib/python. (library modules, configuration info). For UnixOS2, you could put the .exe/.dll files into /usr/local/bin, and everything else from the Python binary distribution into /usr/local/lib/python2.2, and set PYTHONHOME/PYTHONPATH accordingly. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 4 ==========================** Date: Fri, 17 Jan 2003 12:08:14 +0100 From: "Bart van Leeuwen" Subject: glibc completion Hi, I already tried to put some attention to the subject with a mail about the ISC DHCP client/server but there was noone appart form joh reacting. I think this is a major issue, I run into incompatibilites and missing parts off the glibc version we use with EMX. I've added some functions to a private lib to get stuff compiled but thats defenitly not the way, A roadmap for this has to be discussed, otherwise we end up making the same mistakes over and over again. my current effort is to make the dhcp client compile with as few source changes as possible, sofar it works okay, but stil I had to compile some stuff from the glibc on the internet.. With Regards Bart van Leeuwen **= Email 5 ==========================** Date: Fri, 17 Jan 2003 14:18:02 +0000 From: John Poltorak Subject: Re: glibc completion On Fri, Jan 17, 2003 at 12:08:14PM +0100, Bart van Leeuwen wrote: > I already tried to put some attention to the subject with a mail about the > ISC DHCP client/server but there was noone appart form joh reacting. > I think this is a major issue, I run into incompatibilites and missing > parts off the glibc version we use with EMX. You're right, it is a major issue and something we need to address. > I've added some functions to a private lib to get stuff compiled but thats > defenitly not the way, A roadmap for this has to be discussed, otherwise we > end up making the same mistakes over and over again. > my current effort is to make the dhcp client compile with as few source > changes as possible, sofar it works okay, but stil I had to compile some > stuff from the glibc on the internet.. What did you need to compile? There are probably many private collections of libs around the Internet. We really need to pool them together and try on bring out a standard. > With Regards > Bart van Leeuwen > -- John **= Email 6 ==========================** Date: Fri, 17 Jan 2003 14:20:36 +0000 From: John Poltorak Subject: Re: Testing for LINK386 on path On Fri, Jan 17, 2003 at 03:12:50PM +0100, Stefan Neis wrote: > On Thu, 16 Jan 2003, John Poltorak wrote: > > > Is LINK386.EXE considered to be an absolute requirement for a build > > environment? > > The answer probably is: It depends. > If you want to build any OMF based stuff, then LINK386.EXE is mandatory, > if a.out is sufficient for your purposes, then you probably don't need it. How do I know if I want to build OMF based stuff or a.out? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 7 ==========================** Date: Fri, 17 Jan 2003 14:37:50 +0000 From: John Poltorak Subject: Re: ZLIB On Fri, Jan 17, 2003 at 03:20:45PM +0100, Stefan Neis wrote: > On Thu, 16 Jan 2003, John Poltorak wrote: > > > I have never understood all the issues surrounding ZLIB and why it is so > > difficult to have a single distribution of the package. Why can't we > > just have one? > > In short, different "version" of zlib DLL's use different ordinals for > the functions and executables compiled against different zlib DLL's use > different ordinals to retrieve the same function. E.g. application A > says: give me function "nr. 1" from zlib DLL and expects to find a > decompression routine, while function "nr. 2" is expected to give it a > compression routine and application B does it the other way round since > it's linked against a different zlib DLL. > (Sane applications should say "give me the function named "_deflate" from > zlib.DLL" and everything would be fine, no matter what DLL you use, but > unfortunately not all applications behave in that way (yet)). Is there a 'preferred' way of calling these functions? And if so, can we try to standardise on it and encourage all porters to comply. We will continue with chaos otherwise... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 8 ==========================** Date: Fri, 17 Jan 2003 14:51:39 +0000 From: John Poltorak Subject: Re: ZLIB On Fri, Jan 17, 2003 at 03:43:35PM +0100, Stefan Neis wrote: > On Fri, 17 Jan 2003, John Poltorak wrote: > > > Is there a 'preferred' way of calling these functions? And if so, can we > > try to standardise on it and encourage all porters to comply. > > > > We will continue with chaos otherwise... > > I think we did reach a consensus of relying on "call by name" instead of > "call by ordinal", So how do I recognise which type a particular build of ZLIB is for? I think we should have a standard UnixOS/2 version of ZLIB. Is there one we can adopt? > but for one that won't "fix" existing applications and > moreover it doesn't help as long as some developers insist on linking > against there own version (known to work well and using ordinals) of > something. I guess if the source and patches for these apps are available then we can rebuild them to be compliant if necessary... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 9 ==========================** Date: Fri, 17 Jan 2003 15:12:50 +0100 (CET) From: Stefan Neis Subject: Re: Testing for LINK386 on path On Thu, 16 Jan 2003, John Poltorak wrote: > Is LINK386.EXE considered to be an absolute requirement for a build > environment? The answer probably is: It depends. If you want to build any OMF based stuff, then LINK386.EXE is mandatory, if a.out is sufficient for your purposes, then you probably don't need it. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 10 ==========================** Date: Fri, 17 Jan 2003 15:20:45 +0100 (CET) From: Stefan Neis Subject: Re: ZLIB On Thu, 16 Jan 2003, John Poltorak wrote: > I have never understood all the issues surrounding ZLIB and why it is so > difficult to have a single distribution of the package. Why can't we > just have one? In short, different "version" of zlib DLL's use different ordinals for the functions and executables compiled against different zlib DLL's use different ordinals to retrieve the same function. E.g. application A says: give me function "nr. 1" from zlib DLL and expects to find a decompression routine, while function "nr. 2" is expected to give it a compression routine and application B does it the other way round since it's linked against a different zlib DLL. (Sane applications should say "give me the function named "_deflate" from zlib.DLL" and everything would be fine, no matter what DLL you use, but unfortunately not all applications behave in that way (yet)). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 11 ==========================** Date: Fri, 17 Jan 2003 15:30:42 +0100 (CET) From: Stefan Neis Subject: Re: glibc completion On Fri, 17 Jan 2003, Bart van Leeuwen wrote: > I think this is a major issue, I run into incompatibilites and missing > parts off the glibc version we use with EMX. For the 316th time: There is no such thing as _G_libc that is used with EMX. It's using it's own libc which has no relation at all with the GNU version of libc. > A roadmap for this has to be discussed, otherwise we > end up making the same mistakes over and over again. Actually, the current proposal would be to try using the POSIX/2 library (cExt.a). That's based on BSD libc, again totally unrelated to GNU libc, but about as complete as it can get - and I would be surprised if the dhcp client really required _GNU_ libc, as that would imply that Linux and Hurd would be about the only systems being able to compile it.... Note that POSIX/2's cExt.a has some rather annoying bugs in some of the more esoteric functions. I hope to be able to integrate a couple of patches during this weekend ... Regards, Stefan **= Email 12 ==========================** Date: Fri, 17 Jan 2003 15:33:02 +0100 (CET) From: Stefan Neis Subject: Re: Testing for LINK386 on path On Fri, 17 Jan 2003, John Poltorak wrote: > How do I know if I want to build OMF based stuff or a.out? Well, if you're using -Zomf, you're building OMF based stuff. _The_ argument in favour of OMF is that it usually results in smaller executables, that AFAIK, that's it. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 13 ==========================** Date: Fri, 17 Jan 2003 15:39:44 +0100 (CET) From: Stefan Neis Subject: Re: How to identify OS/2 from shell script On Thu, 16 Jan 2003, John Poltorak wrote: > What is the best way of identifying the operating system as OS/2 from > within a shell script? The main problem is, that it shouldn't break the script on other platforms, so this > if `ver`="Operating System/2" ? is pretty much ruled out. > Is there any way to identify that the OS uses drive letters, or ';' as > path seperators, or '\' as directory seperators? One could try to analyze the path variable, but the path variable might get mangled to some shell compatible form by the shell??? > I wouldn't want to rely on environment variables, but are there any unique > to OS/2? I guess, OS2_SHELL, RUNWORKPLACE and VIDEO_DEVICES would be good candidates. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 14 ==========================** Date: Fri, 17 Jan 2003 15:43:35 +0100 (CET) From: Stefan Neis Subject: Re: ZLIB On Fri, 17 Jan 2003, John Poltorak wrote: > Is there a 'preferred' way of calling these functions? And if so, can we > try to standardise on it and encourage all porters to comply. > > We will continue with chaos otherwise... I think we did reach a consensus of relying on "call by name" instead of "call by ordinal", but for one that won't "fix" existing applications and moreover it doesn't help as long as some developers insist on linking against there own version (known to work well and using ordinals) of something. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 15 ==========================** Date: Fri, 17 Jan 2003 16:40:03 +0000 From: John Poltorak Subject: Re: UnixOS/2 Build System - mailing list On Fri, Jan 17, 2003 at 04:58:55PM +0100, Yuri Dario wrote: > Hi John, > > >When some of us were trying to get Perl 5.8.0 working around six months > >ago, a number of people were complaining about the high volume of traffic > >on this list and said it should be split. A number of people also left > > I think the purpouse of this list, is to let people discuss problems related to building unix > applications under OS/2: if you start 'fork()ing' the list for every new application build, you will > end having a lot of mailing list; people can't join all of them, and it could happen that some > interesting stuffs are shared only between a few split-list subscribers. > > Or people having some problems on a specific list, will not gain help from the other lists (not all > people are subscribed). Yuri, I take your point, but in this case the other list has been specifically set up as a support list for a particular project, and subscribers to that list are expected to participate and provide feedback. Experience has shown that many people do not like high bandwidth here especially when it involves a very narrow field like getting a few Perl test failures sorted out. Your experience with builds of large apps would be invaluable on the other list and you are most welcome to join and share your expertise with us. Periodically, I hope to provide summaries of builds of different apps, on this list but the minutiae can be very tedious for people not involved. You can get details of the other list here:- http://powerusersbbs.net/mailman/listinfo/ux2bs although archives are not yet available. > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.quasarbbs.net/yuri > * http://www.teamos2.it > * http://www.opera.com/os2/ > */ -- John **= Email 16 ==========================** Date: Fri, 17 Jan 2003 16:58:55 +0100 (CET) From: "Yuri Dario" Subject: Re: UnixOS/2 Build System - mailing list Hi John, >When some of us were trying to get Perl 5.8.0 working around six months >ago, a number of people were complaining about the high volume of traffic >on this list and said it should be split. A number of people also left I think the purpouse of this list, is to let people discuss problems related to building unix applications under OS/2: if you start 'fork()ing' the list for every new application build, you will end having a lot of mailing list; people can't join all of them, and it could happen that some interesting stuffs are shared only between a few split-list subscribers. Or people having some problems on a specific list, will not gain help from the other lists (not all people are subscribed). Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.quasarbbs.net/yuri * http://www.teamos2.it * http://www.opera.com/os2/ */ **= Email 17 ==========================** Date: Fri, 17 Jan 2003 17:47:10 -0800 (PST) From: Steve Wendt Subject: Re: UnixOS/2 Build System - mailing list On Fri, 17 Jan 2003, John Poltorak wrote: > Periodically, I hope to provide summaries of builds of different apps, > on this list but the minutiae can be very tedious for people not involved. I wish to express my thanks for creating the secondary list. ;) **= Email 18 ==========================** Date: Fri, 17 Jan 2003 19:20:54 +0100 (CET) From: "Adrian Gschwend" Subject: Re: glibc completion On Fri, 17 Jan 2003 15:30:42 +0100 (CET), Stefan Neis wrote: >Actually, the current proposal would be to try using the >POSIX/2 library (cExt.a). That's based on BSD libc, again >totally unrelated to GNU libc, but about as complete as it can >get - and I would be surprised if the dhcp client really required >_GNU_ libc, as that would imply that Linux and Hurd would be >about the only systems being able to compile it.... > >Note that POSIX/2's cExt.a has some rather annoying bugs in >some of the more esoteric functions. I hope to be able to >integrate a couple of patches during this weekend ... Maybe Holger could comment that topic as well about his efforts with LIBEMU. He does focus on the unix-system calls and in the future his work will be the base of all ports (hopefully). cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 19 ==========================** Date: Fri, 17 Jan 2003 19:23:28 +0100 (CET) From: "Adrian Gschwend" Subject: Re: How to identify OS/2 from shell script On Thu, 16 Jan 2003 21:01:22 +0000, John Poltorak wrote: >One suggestion is uname. Anything else? > >How about using something like > >if `ver`="Operating System/2" ? why not report UnixOS2 in uname( )? Then it doesn't matter if it's eCS or OS/2 and it does not give headache with / in the name. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 20 ==========================** Date: Fri, 17 Jan 2003 19:32:09 +0100 From: "Bart van Leeuwen" Subject: Re: glibc completion On 17-01-2003 19:20:54 owner-os2-unix wrote: >On Fri, 17 Jan 2003 15:30:42 +0100 (CET), Stefan Neis wrote: > >>Actually, the current proposal would be to try using the >>POSIX/2 library (cExt.a). That's based on BSD libc, again >>totally unrelated to GNU libc, but about as complete as it can >>get - and I would be surprised if the dhcp client really required >>_GNU_ libc, as that would imply that Linux and Hurd would be >>about the only systems being able to compile it.... >> >>Note that POSIX/2's cExt.a has some rather annoying bugs in >>some of the more esoteric functions. I hope to be able to >>integrate a couple of patches during this weekend ... > >Maybe Holger could comment that topic as well about his efforts with >LIBEMU. He does focus on the unix-system calls and in the future his >work will be the base of all ports (hopefully). > okay maybe this has been discussed here before as well, just for the record.. do Posix/2 and libemu relate ? are they a like or are they two seperate things working together ? how can I help on either off them, I do know libemu is closed for now. or should I just wait ?, don't mind buildig my own libs in the mean time. Bart **= Email 21 ==========================** Date: Fri, 17 Jan 2003 22:00:46 -0500 From: Ted Sikora Subject: Mailman 2.0.13 final is out! http://powerusersbbs.net/ftp/pub/mailman/ The patched source is also available. -- Ted Sikora tsikora at ntplx.net **= Email 22 ==========================** Date: Fri, 17 Jan 2003 22:30:47 +0100 (CET) From: "Franz Bakan" Subject: Re: ZLIB On Fri, 17 Jan 2003 14:51:39 +0000, John Poltorak wrote: >I think we should have a standard UnixOS/2 version of ZLIB. Is there one >we can adopt? I suggest to use 'my' version just because it's backwardscompatible to some XFree-program I use (Gimp and some others). Other possiblility is that someone rebuilds the gdk/gtk/gimp things without calling by ordinals. Should I upload the 'gimp-compatible'-version to HOBBES and replace the gimp-incopatible-version which is still there? If you don't find it on os2unix/unixos2 it's still available at: http://home.tiscalinet.de/fbakan/temp/zlib114.zip Waiting for comments, Franz **= Email 23 ==========================** Date: Fri, 17 Jan 2003 23:02:04 +0300 (MSK) From: "nickk" Subject: Security/2 updated Hi! There is a new drop of Security/2 at http://ecomstation.ru/openssh. Is anybody already uses Security/2 stuff ? **= Email 24 ==========================** Date: Fri, 17 Jan 2003 23:49:13 +0000 From: John Poltorak Subject: Re: ZLIB On Fri, Jan 17, 2003 at 10:30:47PM +0100, Franz Bakan wrote: > On Fri, 17 Jan 2003 14:51:39 +0000, John Poltorak wrote: > > >I think we should have a standard UnixOS/2 version of ZLIB. Is there one > >we can adopt? > > I suggest to use 'my' version just because it's backwardscompatible > to some XFree-program I use (Gimp and some others). Can we agree on a single maintainer? > Other possiblility is that someone rebuilds the gdk/gtk/gimp things > without calling by ordinals. Does anyone maintain these programs? > Should I upload the 'gimp-compatible'-version to HOBBES and > replace the gimp-incopatible-version which is still there? > > If you don't find it on os2unix/unixos2 it's still available at: > > http://home.tiscalinet.de/fbakan/temp/zlib114.zip > > Waiting for comments, I just tried building it with my UnixOS/2 Build System and it looked as if it ran OK apart from one thing... Makefile.os2 specifies SHELL=bash. Can that be changed? I would prefer it to be SHELL=sh ... BTW what is minigzip for? > Franz -- John