From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 27 Jul 2002 04:33:44 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 285 ************************************************** Friday 26 July 2002 Number 285 ************************************************** Subjects for today 1 Re: UnixOS/2 bootstrap : Dave Saville" 2 Re: wxWindows : John Poltorak 3 Re: wxWindows : John Poltorak 4 Re: baseline perl harness results : Maynard" 5 Re: Baseline EMX [emx_inst.cmd] : John Poltorak 6 Re: Baseline EMX [emx_inst.cmd] : Dave Saville" 7 Versions : Dave Saville" 8 Re: Versions : John Poltorak 9 Re: Baseline EMX [emx_inst.cmd] : John Poltorak 10 Re: wxWindows : xyzyx" 11 Re: Baseline EMX [emx_inst.cmd] : Lyn St George" 12 Re: wxWindows : John Poltorak 13 Re: ln.cmd : xyzyx" 14 RE: wxWindows : Stefan Neis 15 Re: Versions : Stefan Neis 16 RE: wxWindows : Stefan Neis 17 Re: baseline perl harness results : John Poltorak 18 Re: baseline perl harness results : John Poltorak 19 Re: baseline perl harness results : Stefan Neis 20 Re: Baseline EMX [emx_inst.cmd] : John Poltorak 21 Re: ln.cmd : Maynard" 22 Re: UnixOS/2 bootstrap : Maynard" 23 Re: Versions : Dave Saville" 24 Re: UnixOS/2 bootstrap : Maynard" 25 Re: Versions : Dave Saville" 26 Re: wxWindows : Stefan Neis 27 Re: UnixOS/2 bootstrap : Maynard" 28 Re: Versions : Stefan Neis 29 Threading support : John Poltorak 30 Re: ln.cmd : John Poltorak 31 Re: ln.cmd : Andreas Buening 32 Re: GLIBC : Andreas Buening 33 Re: wxWindows : Andreas Buening 34 Re: wxWindows : John Poltorak 35 Re: UnixOS/2 bootstrap : John Poltorak 36 Re: ln.cmd : John Poltorak 37 Re: ln.cmd : Andreas Buening 38 Re: UnixOS/2 bootstrap : John Poltorak **= Email 1 ==========================** Date: Sat, 27 Jul 2002 08:30:08 +0100 (BST) From: "Dave Saville" Subject: Re: UnixOS/2 bootstrap On Fri, 26 Jul 2002 21:18:49 +0100 (BST), Dave Saville wrote: >So the script would be > >type | ftp -nv >ftp.log >grep "Transfer complete" ftp.log >nul > >Check greps return code. Damn we have not got grep yet have we :-) try this or similar at echo off type | ftp -nv >ftp.log find /I /C "transfer complete" ftp.log >nul IF NOT ERRORLEVEL 1 GOTO STEP2 ECHO FTP FAILED PAUSE GOTO END :STEP2 ECHO FTP PROCEDURE COMPLETED SUCCESSFULLY :END -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 2 ==========================** Date: Sat, 27 Jul 2002 08:41:26 +0100 From: John Poltorak Subject: Re: wxWindows On Fri, Jul 26, 2002 at 10:38:27PM +0100, Csaba wrote: > On 26 Jul 2002, at 15:49, John Poltorak wrote: > > > It _is_ already available. What I meant was it couldn't be used with > > autoconf yet because it's make utility does not support POSIX flags which > > is something that autoconf requires. > > Are you sure it's wmake the culprit ? I had the impression that the > compiler itself does not conform to POSIX commandline standards > (e.g. -o to set the output file) and autoconf cannot deal with *that* My mistake. What Watcom needs is POSIX compatible 'CC driver' whatever that means. Apparently it already has CL and BCC drivers, and it sounds as though it may be a relatively trivial thing to add... I started a thread about 'POSIX compatible command line options' a couple of months ago on the OpenWatcom news server - news.openwatcom.org in the newsgroup openwatcom.users.c_c++ The requirements for a CC driver are explained there. -- John **= Email 3 ==========================** Date: Sat, 27 Jul 2002 08:52:30 +0100 From: John Poltorak Subject: Re: wxWindows On Fri, Jul 26, 2002 at 09:04:19AM -0500, Dave Webster wrote: > Actually, I am looking forward to WatcomC++ on OS/2. I thought it was > already available and I hadn't yet taken the plunge. I understand it comes > with complete support for STL??? You may be interested to know that there is an OpenWatcom news server - news.openwatcom.org and there has been some discussion about wxWindows in the newsgroup openwatcom.users.c_c++. Apparently wxWindows 2.2.7 builds fine with OpenWatcom on Windows. -- John **= Email 4 ==========================** Date: Sat, 27 Jul 2002 09:13:34 -0500 (CDT) From: "Maynard" Subject: Re: baseline perl harness results Stefan, >Thanks for information. Some really are no problem, but IMHO some of the >skips look quite troublesome... [...snippage...] >But 64-bit-integers, crypt, termcap, network and I18N (I think, that's >what gettext and related utilities/DLLs are for?) really should work. I'm going to have to offer up a WAG here while wondering if there just aren't OS/2 specific tests written for these. I expect that the voice of authority here would be the porter, with whom some on this list are likely in [semi-]regular contact and can formulate the proper question. ...in anticipation thereof, -- Maynard **= Email 5 ==========================** Date: Sat, 27 Jul 2002 09:23:21 +0100 From: John Poltorak Subject: Re: Baseline EMX [emx_inst.cmd] On Fri, Jul 26, 2002 at 03:29:07PM -0500, Maynard wrote: > So, if the only end in sight is to create a baseline environment which > will build perl, we're done. Originally, there were two seperate projects, a build system and a baseline install. What we have now is the two rolled into one. ux2_bootstrap was written as a proof of concept, ie to show that it is possible to install a build environment _and_ build a non-trivial app (Perl) automatically from scratch into a brand new environment, and the number of people who have succeeded shows that it is possible, although there is still plenty of scope for tidying things up. > If the project now becomes one of > continuing development of a working build environment, or office > environment with an enhanced toolset [%uxrt%\usr\bin in PATH], and with > integrated build capacity (no reboot required) then we are well poised > to proceed, eh. I have been extending the scripts so that any number of apps can be built initially, not just Perl. There is also an alternative of skipping the set up of the baseline install if that has been done already so that apps can be built using the pre-installed baseline. My immediate aim is to get most apps in the baseline rebuilt to conform with any UnixOS/2 standards, updating them to more recent versions where possible. In addition, some apps which should have been in the baseline such BYACC and FLEX are not available in usable states anyway, so may as well be built from scratch. I'm currently trying to iron out a couple of problems with those two, but they are almost done. > Thanks again, > > -- > Maynard -- John **= Email 6 ==========================** Date: Sat, 27 Jul 2002 11:32:55 +0100 (BST) From: "Dave Saville" Subject: Re: Baseline EMX [emx_inst.cmd] I am not sure I like emx in the root directory structure. I know you want to keep it in one lump but why not put it where *nix would put compilers? /usr/local/bin - perl is usually there as well. -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 7 ==========================** Date: Sat, 27 Jul 2002 12:53:18 +0100 (BST) From: "Dave Saville" Subject: Versions Just ran a compare between the build in /usr/bin and what I had on my box. There are some real oddities. Most match on date and size. A few are the same size but different dates - but that could have been me moving/coping things about. However.... In all cases the one in /usr/bin is listed first -rwxrwx--a 47626 Feb 22 1998 m4.exe -rwxrwx--a 40518 Feb 22 1998 m4.exe both yield GNU m4, version 1.4 -rwxrwx--a 185344 Aug 11 2001 make.exe -rwxrwx--a 171520 Oct 26 2001 make.exe both yield GNU Make version 3.76.1 -rwxrwx--a 17428 May 20 1994 sed.exe -rwxrwx--a 19466 Feb 22 1996 sed.exe /usr/bin/sed.exe SIGSEGVs mine GNU sed version 3.00 -rwxrwx--a 7680 Mar 31 1998 xargs.exe -rwxrwx--a 9749 Apr 4 1993 xargs.exe GNU xargs GNU find version 3.8 GNU xargs version 3.8 I have no idea what sh I am using - is there any way to ask sh what it is? -rwxrwx--a 163844 Feb 1 03:03 sh.exe -rwxrwx--a 126980 Jun 4 1996 sh.exe -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 8 ==========================** Date: Sat, 27 Jul 2002 13:48:16 +0100 From: John Poltorak Subject: Re: Versions On Sat, Jul 27, 2002 at 12:53:18PM +0100, Dave Saville wrote: > Just ran a compare between the build in /usr/bin and what I had on my > box. There are some real oddities. Most match on date and size. A few > are the same size but different dates - but that could have been me > moving/coping things about. However.... > > In all cases the one in /usr/bin is listed first > > -rwxrwx--a 47626 Feb 22 1998 m4.exe > -rwxrwx--a 40518 Feb 22 1998 m4.exe > > both yield GNU m4, version 1.4 > > -rwxrwx--a 185344 Aug 11 2001 make.exe > -rwxrwx--a 171520 Oct 26 2001 make.exe > > both yield GNU Make version 3.76.1 > > -rwxrwx--a 17428 May 20 1994 sed.exe > -rwxrwx--a 19466 Feb 22 1996 sed.exe > > /usr/bin/sed.exe SIGSEGVs > mine GNU sed version 3.00 > > -rwxrwx--a 7680 Mar 31 1998 xargs.exe > -rwxrwx--a 9749 Apr 4 1993 xargs.exe > > GNU xargs GNU find version 3.8 > GNU xargs version 3.8 > > I have no idea what sh I am using - is there any way to ask sh what > it is? > > -rwxrwx--a 163844 Feb 1 03:03 sh.exe > -rwxrwx--a 126980 Jun 4 1996 sh.exe Please bare in mind that the baseline toolset is not the definitive version of the toolset, it is merely a starting point which can be used to create the definitive version. This baseline itself is not necessarily fixed since it has only been used to create Perl so far. Building other apps is likely to highlight any shortcomings. You can easily trace the origin of every single app because everything has been installed in one go and you have a list of URLs from which you got them. Generally people would have built up their Unix-like environment over many years and would not have a clue where certain apps came from. > > -- > Regards > > Dave Saville > Please note new email address dave.saville at ntlworld.com > -- John **= Email 9 ==========================** Date: Sat, 27 Jul 2002 14:02:31 +0100 From: John Poltorak Subject: Re: Baseline EMX [emx_inst.cmd] On Sat, Jul 27, 2002 at 11:32:55AM +0100, Dave Saville wrote: > I am not sure I like emx in the root directory structure. I know you > want to keep it in one lump but why not put it where *nix would put > compilers? /usr/local/bin - perl is usually there as well. \emx is basically a legacy directory which I would like to eliminate altogether at some point, but I don't think that would be possible until gcc v3.+ is adopted. As far as Perl goes, that is a discrete package which is more or less self contained in \usr\lib\perl apart from the DLL and perl.exe which should be on the path and libpath. I don't like the idea of including emx under \usr, it just doesn't feel right. Of course, you have access to the scripts so you can tailor everything to your personal preferences. Once installed, you can move emx to wherever you want and I think you would only need to change the path in BUILD.CMD to accomodate it. > -- > Regards > > Dave Saville > Please note new email address dave.saville at ntlworld.com -- John **= Email 10 ==========================** Date: Sat, 27 Jul 2002 14:37:07 -0500 (CDT) From: "xyzyx" Subject: Re: wxWindows On Sat, 27 Jul 2002 18:04:32 +0200 (CEST), Stefan Neis wrote: >I'm under the impression that test for threading support (at least those >in autoconf) just test for presence of a pthreads library and which of the >"usual" functions it contains, so unless you've something suitable >installed (I myself am using some rather old version of pthreads by >Anthony Curtis), you'll get a failure there. >But since Apache 2.0 is using OS/2 threads directly (AFAIK), I though the >same might be true for Perl ... AFAIK, Apache 2.0 doesn't use pthreads. To quote from the Apache website: "Apache 2.0 is faster and more stable on non-Unix platforms such as BeOS, OS/2, and Windows. With the introduction of platform-specific multi-processing modules (MPMs) and the Apache Portable Runtime (APR), these platforms are now implemented in their native API, avoiding the often buggy and poorly performing POSIX-emulation layers." Paul **= Email 11 ==========================** Date: Sat, 27 Jul 2002 14:46:23 +0000 From: "Lyn St George" Subject: Re: Baseline EMX [emx_inst.cmd] On Sat, 27 Jul 2002 14:02:31 +0100, John Poltorak wrote: > >\emx is basically a legacy directory which I would like to eliminate >altogether at some point, but I don't think that would be possible until >gcc v3.+ is adopted. I agree on that. The policy I follow is to keep /emx absolutely untouched, as a known baseline. "Bleeding edge" experimental things go in /usr/test/foo (lib, bin, include), and anything which proves to be a good replacement for something in emx goes in /usr/foo. The paths in config.sys then put /usr/test/foo first, /usr/foo second, and /emx/foo last. Of course Holger V is building a new future ... - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 12 ==========================** Date: Sat, 27 Jul 2002 14:57:46 +0100 From: John Poltorak Subject: Re: wxWindows On Sat, Jul 27, 2002 at 03:22:12PM +0200, Stefan Neis wrote: > > I've been oversimplifying a bit, keep in mind that no two Unix variants > are really identical and the differences are more important than minor > differences in makefile syntax. autoconf/configure also is doing a good > job in determining which features are supported by which Unix platform, > e.g. are longs 32 bit or 64 bit? is POSIX threading supported or not? Talking of POSIX threading, is OS/2's native threading POSIX compliant? When there are any tests for threading support, what do they do on OS/2? > Regards, > Stefan > -- John **= Email 13 ==========================** Date: Sat, 27 Jul 2002 15:05:49 -0500 (CDT) From: "xyzyx" Subject: Re: ln.cmd On Sat, 27 Jul 2002 21:16:20 +0200, Andreas Buening wrote: >OS/2 has no (sym)links. Copying files is somewhat different >from creating links. Therefore I propose the following for >the "UnixOS/2 standard": There is no "ln" executable or >shell script that simulates links by copying files. If a >package wants to create (sym)links then the package has to be >fixed. I agree. Paul **= Email 14 ==========================** Date: Sat, 27 Jul 2002 15:08:08 +0200 (CEST) From: Stefan Neis Subject: RE: wxWindows On Fri, 26 Jul 2002, Dave Webster wrote: > But so far wxWindows for OS/2 works only under VisualAge and EMX and both > have valid and seldom changing makefiles, so I see no need to futz with > autoconf at all, Actually, the EMX makefiles _are_ generated by autoconf&configure. ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 15 ==========================** Date: Sat, 27 Jul 2002 15:11:13 +0200 (CEST) From: Stefan Neis Subject: Re: Versions On Sat, 27 Jul 2002, Dave Saville wrote: > /usr/bin/sed.exe SIGSEGVs > mine GNU sed version 3.00 Where did you get that one? It's broken and shouldn't even be distributed. Either get sed-2.05 or sed-3.0something, never use 3.00. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 16 ==========================** Date: Sat, 27 Jul 2002 15:22:12 +0200 (CEST) From: Stefan Neis Subject: RE: wxWindows On Fri, 26 Jul 2002, Dave Webster wrote: > Personally all this effort that goes into wx's configure stuff, a tmake to > generate a config script and then running an autoconf against that just to > get a makefile....classic lack of focus on the real issue, the library > itself. I've been oversimplifying a bit, keep in mind that no two Unix variants are really identical and the differences are more important than minor differences in makefile syntax. autoconf/configure also is doing a good job in determining which features are supported by which Unix platform, e.g. are longs 32 bit or 64 bit? is POSIX threading supported or not? which gtk version is installed (wxGTK always incorporates one or two #ifdefs per GTK-release to work around the new bugs of the underlying GTK :-( )? is byte ordering little endian or big endian? and tons more. Without autoconf, it might be possible to support e.g. Linux and Solaris, but not much more. With autoconf, we get *BSD, HP/UX, IRIX, AIX, OSF1 and more for (almost) free, so I don't think it's not worth it. tmake which is used to generate the input files for autoconf as well as for other compilers is a whole other story - but then, it's enabling wxWindows to reuse the same makefiles accross the various autoconf-based ports - without it, I suppose some people would still be busy writing makefiles for wxX11, so I'm not sure if having it is a good or a bad thing ... ;-) Regards, Stefan **= Email 17 ==========================** Date: Sat, 27 Jul 2002 15:22:56 +0100 From: John Poltorak Subject: Re: baseline perl harness results On Sat, Jul 27, 2002 at 03:31:08PM +0200, Stefan Neis wrote: > > all skipped: no termcap available to test > > all skipped: no threads > > all skipped: no use5005threads > > all skipped: no useithreads > > IF the OS/2 threading model is supported, we probably can forget about all > the skipped threading tests, How do we get support for the OS/2 threading model? Maybe it is a settable configuration option... > But 64-bit-integers, crypt, termcap, I think I should incorporate termcap into the baseline, but have never really been sure what to include. Slackware includes a TERMCAP pkg:- ftp://ftp.slackware.com/pub/slackware/slackware/slackware/l/libtermcap-1.2.3-i386-2.tgz but I don't know how much of this is applicable to OS/2 or if there already is a suitable package I can use... I could do with some help on this one. > Regards, > Stefan > -- John **= Email 18 ==========================** Date: Sat, 27 Jul 2002 15:29:23 +0100 From: John Poltorak Subject: Re: baseline perl harness results On Sat, Jul 27, 2002 at 09:13:34AM -0500, Maynard wrote: > Stefan, > > >Thanks for information. Some really are no problem, but IMHO some of the > >skips look quite troublesome... > [...snippage...] > >But 64-bit-integers, crypt, termcap, network and I18N (I think, that's > >what gettext and related utilities/DLLs are for?) really should work. > > I'm going to have to offer up a WAG here while wondering if there just > aren't OS/2 specific tests written for these. I expect that the voice > of authority here would be the porter, with whom some on this list are > likely in [semi-]regular contact and can formulate the proper question. I suspect the tests fail either because the (b)termcap.lib is not suitable or there is no terminfo or termcap.dat available. I've always been a little hazy on how OS/2 should handle termcap. > ...in anticipation thereof, > -- > Maynard -- John **= Email 19 ==========================** Date: Sat, 27 Jul 2002 15:31:08 +0200 (CEST) From: Stefan Neis Subject: Re: baseline perl harness results On Fri, 26 Jul 2002, Maynard wrote: > harness yields other information as well > grep skipped: harness | sort -u Thanks for information. Some really are no problem, but IMHO some of the skips look quite troublesome... Particularly, I'd expect some of those to be run succesfully in a more complete build environment: > all skipped: I18N::Langinfo or POSIX unavailable > all skipped: crypt unimplemented > all skipped: network dependent test > all skipped: no 64-bit file offsets > all skipped: no 64-bit types > all skipped: no ithreads > all skipped: no loopback net > all skipped: no termcap available to test > all skipped: no threads > all skipped: no use5005threads > all skipped: no useithreads IF the OS/2 threading model is supported, we probably can forget about all the skipped threading tests, and I'm unsure about the 64-bit file offsets, but with the new kernel support for large files, that should probably be added in the long run - not for the immediate future, though, it'll have to make its way in the C library first... But 64-bit-integers, crypt, termcap, network and I18N (I think, that's what gettext and related utilities/DLLs are for?) really should work. Regards, Stefan **= Email 20 ==========================** Date: Sat, 27 Jul 2002 15:33:46 +0100 From: John Poltorak Subject: Re: Baseline EMX [emx_inst.cmd] On Sat, Jul 27, 2002 at 02:46:23PM +0000, Lyn St George wrote: > On Sat, 27 Jul 2002 14:02:31 +0100, John Poltorak wrote: > > > > >\emx is basically a legacy directory which I would like to eliminate > >altogether at some point, but I don't think that would be possible until > >gcc v3.+ is adopted. > > I agree on that. The policy I follow is to keep /emx absolutely > untouched, as a known baseline. This only applies to \emx\bin in the baseline. lib and include are moved to their 'correct' location under \usr, and a number of variables are set accordingly. > - > Cheers > Lyn St George > +--------------------------------------------------------------------------------- > + http://www.zolotek.net .. eCommerce hosting, consulting > + http://www.os2docs.org .. some 'How To' stuff ... > +---------------------------------------------------------------------------------- -- John **= Email 21 ==========================** Date: Sat, 27 Jul 2002 16:14:52 -0500 (CDT) From: "Maynard" Subject: Re: ln.cmd On Sat, 27 Jul 2002 21:12:18 +0100, John Poltorak wrote: >This is what I got when building automake:- > >c:/bin/sh: ln: not found >make[3]: *** [install-exec-hook] Error 127 >All I want is for the error above to go away. ?? Perhaps a Unix_OS2 specific version of 'ln' which -writes to stderr -returns 'success' --?? **= Email 22 ==========================** Date: Sat, 27 Jul 2002 16:49:21 -0500 (CDT) From: "Maynard" Subject: Re: UnixOS/2 bootstrap On Sat, 27 Jul 2002 21:50:14 +0100, John Poltorak wrote: >Hmm... here's a technique I dug up from many years ago. It seems to work. Not quite yet ;-} >echo machine 213.152.37.92 login unixos2 password "" macdef init >>%etc%\netrc >echo bina >>%etc%\netrc >echo get /pub/unixos2/build_system/lib/wget.exe >>%etc%\netrc >echo bye >>%etc%\netrc >ftp 213.152.37.92 Ready for login. All accesses to this server are logged. 220 Xitami FTP 2.4d6 (c) 1991-98 iMatix Macro definition missing null line terminator. 221- Thank you for using this Xitami webserver. 221 User ftp> [n:\mptn\etc]type netrc machine 213.152.37.92 login unixos2 password "" macdef init bina get /pub/unixos2/build_system/lib/wget.exe bye **= Email 23 ==========================** Date: Sat, 27 Jul 2002 17:06:51 +0100 (BST) From: "Dave Saville" Subject: Re: Versions On Sat, 27 Jul 2002 15:11:13 +0200 (CEST), Stefan Neis wrote: >On Sat, 27 Jul 2002, Dave Saville wrote: > >> /usr/bin/sed.exe SIGSEGVs >> mine GNU sed version 3.00 > >Where did you get that one? It's broken and shouldn't even be distributed. >Either get sed-2.05 or sed-3.0something, never use 3.0 So how come mine appears to work and the baselib one aborts? -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 24 ==========================** Date: Sat, 27 Jul 2002 17:12:59 -0500 (CDT) From: "Maynard" Subject: Re: UnixOS/2 bootstrap Good job digging that one up, John!! >echo bye >>%etc%\netrc needs a "null line" at the end echo: >>%etc%\netrc may need some dancing to save pre-existing netrc files however; and to always create a fresh one. submitted untested, for testing: if exist netrc.ux2 del netrc.ux2 if exist %etc%/netrc copy %etc%/netrc netrc.ux2 echo machine 213.152.37.92 login unixos2 password "" macdef init >>%etc%\netrc echo bina >>%etc%\netrc echo get /pub/unixos2/build_system/lib/wget.exe >>%etc%\netrc echo bye >>%etc%\netrc echo: >>%etc%\netrc ftp 213.152.37.92 if exist netrc.ux2 copy netrc.ux2 %etc%/netrc -- Maynard LONG LIVES DOS ;-} **= Email 25 ==========================** Date: Sat, 27 Jul 2002 17:15:11 +0100 (BST) From: "Dave Saville" Subject: Re: Versions On Sat, 27 Jul 2002 13:48:16 +0100, John Poltorak wrote: >Please bare in mind that the baseline toolset is not the definitive >version of the toolset, it is merely a starting point which can be used to >create the definitive version. This baseline itself is not necessarily >fixed since it has only been used to create Perl so far. Building other >apps is likely to highlight any shortcomings. Oh - I had gotten the impression that all the apps were the latest versions/builds. -- Regards Dave Saville Please note new email address dave.saville at ntlworld.com **= Email 26 ==========================** Date: Sat, 27 Jul 2002 18:04:32 +0200 (CEST) From: Stefan Neis Subject: Re: wxWindows On Sat, 27 Jul 2002, John Poltorak wrote: > > Talking of POSIX threading, is OS/2's native threading POSIX compliant? > > When there are any tests for threading support, what do they do on OS/2? I'm under the impression that test for threading support (at least those in autoconf) just test for presence of a pthreads library and which of the "usual" functions it contains, so unless you've something suitable installed (I myself am using some rather old version of pthreads by Anthony Curtis), you'll get a failure there. But since Apache 2.0 is using OS/2 threads directly (AFAIK), I though the same might be true for Perl ... If not, our best chance might be to find the most current version of said pthread library (maybe at netlabs?) and try and see if the perl build process can make use of it (maybe after modifying that famous configuration file whose name always escapes me accordingly). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 27 ==========================** Date: Sat, 27 Jul 2002 18:05:04 -0500 (CDT) From: "Maynard" Subject: Re: UnixOS/2 bootstrap On Sat, 27 Jul 2002 17:12:59 -0500 (CDT), Maynard wrote: >ftp 213.152.37.92 INSERT->> del %etc%/netrc >if exist netrc.ux2 copy netrc.ux2 %etc%/netrc **= Email 28 ==========================** Date: Sat, 27 Jul 2002 18:36:09 +0200 (CEST) From: Stefan Neis Subject: Re: Versions On Sat, 27 Jul 2002, Dave Saville wrote: > On Sat, 27 Jul 2002 15:11:13 +0200 (CEST), Stefan Neis wrote: > > >On Sat, 27 Jul 2002, Dave Saville wrote: > > > >> /usr/bin/sed.exe SIGSEGVs > >> mine GNU sed version 3.00 > > > >Where did you get that one? It's broken and shouldn't even be distributed. > >Either get sed-2.05 or sed-3.0something, never use 3.0 > > So how come mine appears to work and the baselib one aborts? The baselib one is probably not getting the gnur(ege)x.DLL it wants, so it gives an obvious error. But while sed-3.00 appears to be working, it's producing wrong output sometimes... Regards, Stefan **= Email 29 ==========================** Date: Sat, 27 Jul 2002 19:55:48 +0100 From: John Poltorak Subject: Threading support On Sat, Jul 27, 2002 at 06:04:32PM +0200, Stefan Neis wrote: > On Sat, 27 Jul 2002, John Poltorak wrote: > > > > Talking of POSIX threading, is OS/2's native threading POSIX compliant? > > > > When there are any tests for threading support, what do they do on OS/2? > > I'm under the impression that test for threading support (at least those > in autoconf) just test for presence of a pthreads library and which of the > "usual" functions it contains, so unless you've something suitable > installed (I myself am using some rather old version of pthreads by > Anthony Curtis), you'll get a failure there. > But since Apache 2.0 is using OS/2 threads directly (AFAIK), I though the > same might be true for Perl ... How can anyone tell? > If not, our best chance might be to find the most current version of said > pthread library (maybe at netlabs?) There are some files here:- ftp://ftp.netlabs.org/pub/pthreads/ but two of them look corrupted... > and try and see if the perl build > process can make use of it (maybe after modifying that famous > configuration file whose name always escapes me accordingly). Any clues on its name or contents? > > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 30 ==========================** Date: Sat, 27 Jul 2002 21:12:18 +0100 From: John Poltorak Subject: Re: ln.cmd On Sat, Jul 27, 2002 at 09:16:20PM +0200, Andreas Buening wrote: > John Drabik wrote: > > Automake tries to setup a symbolic link, using ln. The OS/2 > > equivalent must make a copy of the file, since there are no symbolic > > links available. > > Not exactly. autoconf/automake contain some code to replace > ln by cp. But this feature has to be supported by the > package maintainer (it's not difficult to turn it on). > If any of your autoconf/automake generated configure scripts > or Makefiles uses "ln" for anything then it has to be fixed. This is what I got when building automake:- make[3]: Entering directory `C:/unixos2/workdir/automake-1.6.2' ln c:/usr/local/bin/automake c:/usr/local/bin/automake-1.6 c:/bin/sh: ln: not found ln c:/usr/local/bin/aclocal c:/usr/local/bin/aclocal-1.6 c:/bin/sh: ln: not found make[3]: *** [install-exec-hook] Error 127 > > It (ln) probably *should* be in the baseline tools. No idea about if > > it needs a specific timestamp (but, I doubt it, if it doesn't even > > exist). > > In my opinion it should not be in the baseline tools. > 1) "ln" has a different syntax than "ln -s" !!! > 2) "copy" cannot handle '/' in filenames > 3) "ln" can be provided with more than two command line options, > then the small script above fails. All I want is for the error above to go away. > OS/2 has no (sym)links. Copying files is somewhat different > from creating links. Therefore I propose the following for > the "UnixOS/2 standard": There is no "ln" executable or > shell script that simulates links by copying files. If a > package wants to create (sym)links then the package has to be > fixed. So is this a bug in automake? Maybe I only need a set %LN% or something like that... > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 31 ==========================** Date: Sat, 27 Jul 2002 21:16:20 +0200 From: Andreas Buening Subject: Re: ln.cmd John Drabik wrote: > > On Thu, 25 Jul 2002 17:14:46 +0100, John Poltorak wrote: > > >Does anyone have ln.cmd? :- > >It's a simple cmd file:- > > > > at echo off > >cp %1 %2 > > Automake tries to setup a symbolic link, using ln. The OS/2 > equivalent must make a copy of the file, since there are no symbolic > links available. Not exactly. autoconf/automake contain some code to replace ln by cp. But this feature has to be supported by the package maintainer (it's not difficult to turn it on). If any of your autoconf/automake generated configure scripts or Makefiles uses "ln" for anything then it has to be fixed. > That's all it does. You might also want to replace > "cp" with "copy", since automake might be run early in the build > process, or without cp on the path. Also, copy won't change the time > stamp (the new file matches the old), so -p isn't needed. In fact, > if you *want* the file to have a new timestamp, you'll need the old > "+ ,," at the end. > > It (ln) probably *should* be in the baseline tools. No idea about if > it needs a specific timestamp (but, I doubt it, if it doesn't even > exist). In my opinion it should not be in the baseline tools. 1) "ln" has a different syntax than "ln -s" !!! 2) "copy" cannot handle '/' in filenames 3) "ln" can be provided with more than two command line options, then the small script above fails. OS/2 has no (sym)links. Copying files is somewhat different from creating links. Therefore I propose the following for the "UnixOS/2 standard": There is no "ln" executable or shell script that simulates links by copying files. If a package wants to create (sym)links then the package has to be fixed. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 32 ==========================** Date: Sat, 27 Jul 2002 21:16:36 +0200 From: Andreas Buening Subject: Re: GLIBC Holger Veit wrote: > > On Fri, Jul 26, 2002 at 02:07:31PM +0100, Tobias Huerlimann wrote: [where to find regex] > > I'm not sure if this regex library is the one you're looking for > > because the BSD libc regex functions might differ from the GNU libc > > ones. > > There are multiple versions of standalone regex libraries on the net; > they usually fall in one of the following two categories. > Autoconf'd programs usually can deal with any of them. > > One style is: > re_comp() > re_exec() > the other is > regcomp() > regexec() > regerror() > regfree() > > You better search for the second one; this is the modern POSIX style. Is it correct that "re_compile_pattern" is a GNU extension? If this is the case then we have the following status: 1) A lot of GNU programs (grep, sed, awk, make, text utilities) use (GNU) regex. 2) Most of these programs allow to link (GNU) regex externally (saves about 10kb per executable). It's quite easy to implement this feature for all programs if requested. Therefore we have exactly two choices: a) We use GNU regex, make a dll of it, put it into the UnixOS/2 tree and everything is fine. b) We don't use GNU regex but BSD (or whatever) regex. In this case we have no program that uses this BSD regex.dll. In this case we don't need a regex.dll. Period. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 33 ==========================** Date: Sat, 27 Jul 2002 21:16:47 +0200 From: Andreas Buening Subject: Re: wxWindows Dave Webster wrote: [snip] > The main point is that even though toolkits like wxWindows that offer cross > platform development, does NOT mean that the resultant applications have to > install the same way. That is actually a horrible idea. Applications > should install natively, the way users on each platform expect applications > to be delivered to them. [snip] > Trust me, the best way to guarantee wide spread rejection of a consumer > targeted Open Source Windows-OS/2 application to make a user do "autoconf, > configure, make, make install". That's the quickest route to the Recycle > Box or Shredder. All I want as a Windows or OS/2 user is the classic > Setup.exe or Install.bat icon, nothing else will works if you want wide > spread acceptance. Far far too many Open Source zealots just don't get that. > They (the users) are NOT us (the developers). It it obvious that the "normal user" shouldn't be caused to use autoconf && configure && make && make install. I've just read that the new debian distro contains about 8000 packages. This is something nobody can install by running configure. It would take weeks or months even on a fast computer. Normally everybody will install a precompiled binary package. But the goal is that everybody is _able_ to configure && make every package if he wants to do it for one or another reason. autoconf && automake is intended for the developers of the package only. Unfortunately, most current Unix configure scripts don't work properly on OS/2. Therefore it's the job of the responsible UnixOS/2 maintainer to run autoconf && automake. configure && make && make install is intended for developers and every kind of experienced user who wants or needs to compile that specific package for himself. The real big advantage is that "configure && make && make install" provide a standard interface how to install an arbitrary program. You don't have to read a few hundred kb of docs. You don't have to care about hundreds of different Makefiles made by hundreds of different programmers which support different Makefile targets, env. vars. compiler flags. You don't have to analyze the Makefile to find out what's going on, how to get rid of that damn compiler option or how to put it into the Makefile or why the hell it requires that damn not existing header file. If you encounter the message that program "xyz" needs "foo", then you download "foo", run "./configure --help" to see whether there are any unusual options. Then you set up your standard environment (if not already done), e.g. for Linux: export CFLAGS="-O2" export LDFLAGS="-s" Then you run "configure && make && make install" and that's it. If you really run into trouble then you can still read the docs. That's it. It takes about 5 min to install a package from sources under Linux. Under OS/2 after 5 min I've just opened the 1st readme file, after 30 min I've read the most important docs, after 1 hr I may have just got a vague idea what this stupid Makefile.os2 is doing, after 2 hrs I may have it working, and after 2 more hrs I've found out which damn env. var. was keeping my new executable from working properly. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 34 ==========================** Date: Sat, 27 Jul 2002 21:19:39 +0100 From: John Poltorak Subject: Re: wxWindows On Sat, Jul 27, 2002 at 09:16:47PM +0200, Andreas Buening wrote: > Then you run "configure && make && make install" and that's it. > If you really run into trouble then you can still read the docs. > That's it. It takes about 5 min to install a package from > sources under Linux. Under OS/2 after 5 min I've just opened > the 1st readme file, after 30 min I've read the most important > docs, after 1 hr I may have just got a vague idea what this > stupid Makefile.os2 is doing, after 2 hrs I may have it working, > and after 2 more hrs I've found out which damn env. var. was > keeping my new executable from working properly. More likely, you find that this damned makefile.os2 was written specifically for the OS/2 release v1 of the app which is now at v6 and no one has ever checked it since, but included it anyway... > > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 35 ==========================** Date: Sat, 27 Jul 2002 21:50:14 +0100 From: John Poltorak Subject: Re: UnixOS/2 bootstrap On Fri, Jul 26, 2002 at 10:38:27PM +0100, Csaba wrote: Content-Description: Mail message body > On 26 Jul 2002, at 19:32, John Poltorak wrote: > > > On Fri, Jul 26, 2002 at 06:35:41PM +0100, Dave Saville wrote: > > > I notice that after the build, wget is not in /usr/bin - should it > > > not be moved/copied from the build side of the fence? > > > > WGET is a bit of an oddball... > > > > The whole idea of the bootstrap falls down because the system depends on > > WGET already being available, and so it is subsequently ignore in putting > > all the apps in place. > > > > Ideally, I should use programs which are automatically available to the > > user in the first place so it would be better to use FTP for the initial > > file retrieval, since FTP is part of a standard OS/2 installation. > > > > I'm not sure FTP is able to work in a noninteractive way. Hmm... here's a technique I dug up from many years ago. It seems to work. Latest ux2_bootstrap.cmd incorporating various changes:- at echo off echo: echo: Please set variables to suit your own environment before echo: running this script for the first time. echo: set bldrt=c: set uxrt=c: set osrt=c: echo: * osrt is where OS/2 boots from. echo: echo: - currently %osrt% echo: echo: * bldrt is where the build environment will reside. echo: echo: - currently %bldrt% echo: echo: * uxrt is where the Unix-like environment will be installed. echo: echo: - currently %uxrt% echo: echo: If these variables are not set correctly, press ctrl-break otherwise echo: press any other key to install the UnixOS/2 baseline build echo: which should include building Perl 5.8.0. This may take a couple echo: of hours... echo: pause set bld_home=unixos2 echo machine 213.152.37.92 login unixos2 password "" macdef init >>%etc%\netrc echo bina >>%etc%\netrc echo get /pub/unixos2/build_system/lib/wget.exe >>%etc%\netrc echo bye >>%etc%\netrc ftp 213.152.37.92 wget -x -Ncr -nH --cut-dirs=3 -t 1 -P %bldrt%/%bld_home% ftp://unixos2: at 213.152.37.92/pub/unixos2/build_system/ %bldrt% cd \%bld_home%\lib ux2_inst %1 %2 %3 %4 %5 %6 %7 %8 %9 > > Can anyone provide a simple FTP script? > I cobbled rexftp together (see attachment) That looks too much like programming :-)... > Ceci n'est pas un .signature -- John **= Email 36 ==========================** Date: Sat, 27 Jul 2002 22:51:04 +0100 From: John Poltorak Subject: Re: ln.cmd On Sat, Jul 27, 2002 at 10:59:46PM +0200, Andreas Buening wrote: > [snip] > > > This is what I got when building automake:- > > > > make[3]: Entering directory `C:/unixos2/workdir/automake-1.6.2' > > ln c:/usr/local/bin/automake c:/usr/local/bin/automake-1.6 > > c:/bin/sh: ln: not found > > ln c:/usr/local/bin/aclocal c:/usr/local/bin/aclocal-1.6 > > c:/bin/sh: ln: not found > > make[3]: *** [install-exec-hook] Error 127 > > [snip] > > > So is this a bug in automake? Maybe I only need a set %LN% or something > > like that... > > Yes, it was in the original 1.6.2 sources. The according > patch has already been applied and will appear in the next > release. The version I've uploaded to hobbes should be fixed, too. Having checked through the build it looks as though it failed to add your patches. I've just run it again and the error disappears now and the build seems OK apart from this msg:- config.status: creating lib/am/Makefile config.status: creating m4/Makefile config.status: creating m4/amversion.m4 config.status: creating tests/Makefile make: *** empty string invalid as file name. Stop. cd . && \ perllibdir=./lib /unixos2/workdir/automake-1.6.2/automake --libdir=lib --gnu Makefile cd . && c:/bin/sh ./config.status Makefile ./config.status[243]: >&5 : bad file descriptor config.status: WARNING: ac_executable_extensions not set, assuming .exe config.status: creating Makefile Making install in . Have I done something strange to create this error? > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 37 ==========================** Date: Sat, 27 Jul 2002 22:59:46 +0200 From: Andreas Buening Subject: Re: ln.cmd John Poltorak wrote: > > On Sat, Jul 27, 2002 at 09:16:20PM +0200, Andreas Buening wrote: [snip] > This is what I got when building automake:- > > make[3]: Entering directory `C:/unixos2/workdir/automake-1.6.2' > ln c:/usr/local/bin/automake c:/usr/local/bin/automake-1.6 > c:/bin/sh: ln: not found > ln c:/usr/local/bin/aclocal c:/usr/local/bin/aclocal-1.6 > c:/bin/sh: ln: not found > make[3]: *** [install-exec-hook] Error 127 [snip] > So is this a bug in automake? Maybe I only need a set %LN% or something > like that... Yes, it was in the original 1.6.2 sources. The according patch has already been applied and will appear in the next release. The version I've uploaded to hobbes should be fixed, too. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 38 ==========================** Date: Sat, 27 Jul 2002 23:07:14 +0100 From: John Poltorak Subject: Re: UnixOS/2 bootstrap On Sat, Jul 27, 2002 at 04:49:21PM -0500, Maynard wrote: > On Sat, 27 Jul 2002 21:50:14 +0100, John Poltorak wrote: > > >Hmm... here's a technique I dug up from many years ago. It seems to work. > > Not quite yet ;-} It seems to depend on whether you already have a valid netrc file, which as it turns out, you won't have if you are starting from scratch. A missing blank line seems to be the culprit... Try this (after deleting netrc) :- echo machine 213.152.37.92 login unixos2 password "" macdef init >>%etc%\netrc echo bina >>%etc%\netrc echo get /pub/unixos2/build_system/lib/wget.exe >>%etc%\netrc echo bye >>%etc%\netrc echo: >>%etc%\netrc ftp 213.152.37.92 -- John