From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 9 Mar 2002 04:19:13 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 158 ************************************************** Friday 08 March 2002 Number 158 ************************************************** Subjects for today 1 Re: Autoconf 2.52h : Henry Sobotka 2 Re: Autoconf 2.52h : John Poltorak 3 ANN: Gnat 3.14p for OS/2 available : DWParsons at t-online.de (Dave Parsons) 4 http://unix.os2site.com/ada : John Poltorak 5 giflib : Dave and Natalie" 6 Re: os2.m4 in Autoconf : John Poltorak 7 Re: Shell issues, was: Re: Autoconf 2.52h : John Poltorak 8 Re: BSD compatible install... c:/os2/install -c : John Poltorak 9 Building GREP : John Poltorak 10 Re: [XFreeOS2] giflib : Henry Sobotka 11 Re: Autoconf 2.52h : Henry Sobotka 12 Re: giflib : Dave and Natalie" 13 Re: Make problem : John Poltorak 14 Re: Make problem : Holger Veit 15 Re: giflib : John Poltorak 16 Re: Make problem : Jun Sawataishi 17 Re: Shell issues, was: Re: Autoconf 2.52h : Jun Sawataishi **= Email 1 ==========================** Date: Sat, 09 Mar 2002 00:53:35 -0500 From: Henry Sobotka Subject: Re: Autoconf 2.52h Andreas Buening wrote: > > Okay, then please tell me: Where in that doc file is the sentence: > "DO NOT USE BASH! If you're using bash please enter 'exit' > on your command line before you may dare to run './Configure'" It doesn't say that literally, but the third item under Prerequisites is "You need the latest version of pdksh installed as sh.exe." The corollary is obviously "Don't use the bash or any other flavor of sh.exe." > Additionally, where is the list of env. vars. that must > be unset before I may start "./Configure"? I don't unset anything here, so I'm not clear on what you're referring to. > The more prerequisites you need the more fragile the final result will be. No, the more prerequisites, the more complex the build system. The complexity may be good (best way to do the job) or bad (e.g. historical/multideveloper accretion that never got cleaned up, eccentric totally twisted maintainer etc.). Where a special version of a tool is required, there's usually a reason for it; other versions may create problems, and because of priorities or whatever it's easier to specify the version that works; or it may be a concession to a particular platform where another version fails. Some projects even build their own tools. The Perl prerequisites are pretty straightforward. The required tools are common utilities, the sort/find/patch conflicts are old hat, and the only unusual requirements are pdksh and a multithread db.lib. Over the past five years I've been able to build successive versions of Perl with a series of gcc's, as well as all kinds of CPAN modules including some of the GUI toolkits for XFree86/OS2. Sure, I run into problems but most stem from my own eternal vein of duhness. To me, that adds up to robust build machinery. > What I'm trying to tell you is that compiling perl > was everything else than a "catwalk" on my system. > I got no hint from the build system what's wrong, > so I tried and tried and tried. I'll be glad to try to help if you detail what's failing. h~ PS: For the record, I said "cakewalk", not "catwalk". A catwalk is only a cakewalk for the feline-footed. **= Email 2 ==========================** Date: Sat, 9 Mar 2002 11:31:47 +0000 From: John Poltorak Subject: Re: Autoconf 2.52h On Sat, Mar 09, 2002 at 12:53:35AM -0500, Henry Sobotka wrote: > Andreas Buening wrote: > > > > Okay, then please tell me: Where in that doc file is the sentence: > > "DO NOT USE BASH! If you're using bash please enter 'exit' > > on your command line before you may dare to run './Configure'" > > It doesn't say that literally, but the third item under Prerequisites is > "You need the latest version of pdksh installed as sh.exe." The > corollary is obviously "Don't use the bash or any other flavor of > sh.exe." > > > Additionally, where is the list of env. vars. that must > > be unset before I may start "./Configure"? > > I don't unset anything here, so I'm not clear on what you're referring > to. I think some *FLAGS may be set which could interfere with the defaults used when building Perl. What I was wondering was whether there is any way to create a wrapper which sets all environment variables to null so that we can set up exactly those variables which are required rather than inheriting some settings by mistake... > The Perl prerequisites are pretty straightforward. The required tools > are common utilities, the sort/find/patch conflicts are old hat, Unfortunately there is large possibility of using some common utility which is in some way incompatible with the Perl build environment. I think we need to document exactly which utilities are required and which versions of those utilities are recommended, or maybe even try assembling a discrete Perl build kit which will work in isolation from the normal UnixOS/2 environment... > and the > only unusual requirements are pdksh and a multithread db.lib. Over the > past five years I've been able to build successive versions of Perl with > a series of gcc's, as well as all kinds of CPAN modules including some > of the GUI toolkits for XFree86/OS2. Sure, I run into problems but most > stem from my own eternal vein of duhness. To me, that adds up to robust > build machinery. Are you able to get problems resolved? There seem to be two outstanding problems at the moment:- 1. 'Make install' does not work AFAICS because of the presence of INSTALL 2. One of the tests does not work. This appears to be REXX related and is probably specifically devised for OS/2. > h~ -- John **= Email 3 ==========================** Date: Sat, 09 Mar 2002 11:41:04 From: DWParsons at t-online.de (Dave Parsons) Subject: ANN: Gnat 3.14p for OS/2 available Hello all, The latest OS/2 version of Gnat 3.14p is now available at:- ftp://cs.nyu.edu/pub/gnat/3.14p/contrib/os2 and http://dwparsons.bei.t-online.de as gnat-3.14p-os2-bin-20020303.zip Please check the README files for more information before downloading. Thanks to ACT and NYU. Enjoy. Dave **= Email 4 ==========================** Date: Sat, 9 Mar 2002 11:43:26 +0000 From: John Poltorak Subject: http://unix.os2site.com/ada Can someone get this Ada page refreshed to reflect the updated port of GNAT to v3.14p? :- http://unix.os2site.com/ada -- John **= Email 5 ==========================** Date: Sat, 09 Mar 2002 12:09:44 +0000 From: "Dave and Natalie" Subject: giflib Has anyone ported giflib (ftp://sunsite.unc.edu/pub/Linux/libs/giflib/giflib-4.1.0.tar.gz) ideally with dll lib and headers? Dave **= Email 6 ==========================** Date: Sat, 9 Mar 2002 13:33:02 +0000 From: John Poltorak Subject: Re: os2.m4 in Autoconf On Fri, Mar 08, 2002 at 11:55:52PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > args: aclocal.m4? > > > args: os2.m4? > > > args: --mode 777 > > > args: --warning syntax > > > args: --language Autoheader-preselections > > > args: --language Automake-preselections > > > args: --language Autoreconf-preselections > > > args: --language Autoscan-preselections > > > args: --language M4sh > > > end-language: "Autoconf" > > > > > > > Does this mean anything to anyone here? > > These are command line options for autom4te to handle > some files. Can you provide a simple example? > > What I'm thinking about is how to include some of the patches in the OS/2 > > port of v2.50 for Autoheader which substituted some functions such as stat() > > for lstat(). > > > > Is os2.m4 something that we need to put together? Anyone got an example? > > This is a good question. A while ago there was a discussion > whether it makes sense to define some macros for fchown(), > readlink(), whatever. > That code in autoconf 2.50 was intended to be _experimental_. I would like to see that experimental code in 2.53 - I don't like having too many versions of Autoconf around. > However, at least the following conditions must be met: > - it must be possible to turn these features off > - it must work reliable and become some kind of unixos2 > standard. > - it must be compatible with EMX as well as with LIBEMU > (i.e. initialize_main() means _wildcard() for EMX and > nothing for LIBEMU) > - it must be reasonable documented > > > Meanwhile I think the right place to define lstat and > lchown is in lstat.m4 and lchown.m4 respectively. > > (these are macro files that deal with broken lstat()/lchown() > implementations for various unix systems). I don't see these files. Are you suggesting that they should be created? > strcasecmp()/strncasecmp() should be handled in string.h. Can't this be handled by adding something like this to CFLAGS? :- -Dstrncasecmp=strnicmp -Dstrcasecmp=stricmp > initialize_main() would be a nice idea for autoconf. Would that help to eliminate most of the diffs from the textutils? > The best place to handle fchown()/chown()/symlink()/... > might be in the according header file of each package. How would that work? IMV it is a global problem that should be handled by the OS/2 build environment rather than on an individual package basis. > What I won't like is another test like those > "testing for AIX/Cygwin/Mingw environment..." It would be nice to eliminate such tests. > > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Redmond where the Shadows lie. -- John **= Email 7 ==========================** Date: Sat, 9 Mar 2002 13:46:17 +0000 From: John Poltorak Subject: Re: Shell issues, was: Re: Autoconf 2.52h On Sat, Mar 09, 2002 at 10:01:59PM +0900, Jun Sawataishi wrote: > John P. wrote: > >ASH is no longer maintained - maintainer has disappeared. > >BASH old version - maintainer's plans for update not known > >PDKSH recent release - active maintainer > >TCSH old version - maintainer's plans for update not known > >ZSH is no longer maintained - maintainer not known > > >> 2) bash.exe: has a strange drive letter handling algorithm (cuts > >> the first two characters of a directory under certain circumstances). > > I may be a maintainer for bash. I have mentioned before, OS/2 port of > bash 2.05 and bash 2.05a have already finished. I know you ported 2.03 - the UnixOS/2 package is based on your port, but I wasn't aware you were working on 2.05. I would like to get hold of the latest version if possible. > In my mind, uploading bash 2.05a for OS/2 is top priority. Please wait for a while. > (Please believe me. I wish someone presses me hard for bash or other already > ported software about which I had said "Please wait for a while". ) I don't think people want to appear as nuisances... > # OS/2 is not a question, it's a solution. > # SAWATAISHI Jun > # http://www2s.biglobe.ne.jp/~vtgf3mpr/ > -- John **= Email 8 ==========================** Date: Sat, 9 Mar 2002 15:33:27 +0000 From: John Poltorak Subject: Re: BSD compatible install... c:/os2/install -c On Fri, Mar 08, 2002 at 11:53:45PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > When building GREP v2.4.2 the configure script locates the wrong > > install program. > > > > Every other configure script locates:- > > > > c:/usr/bin/install > > > > The path is:- > > > > c:\usr\bin;c:\os2; > > > > and I'm using the same build script and environment. What would cause GREP > > to behave differently? I can only guess that it must be something in > > GREP's configure.in file... > > No, there's only "AC_PROG_INSTALL" which should be the default. > The only thing I can imagine is that this configure script > has been created by a different autoconf version. > (However, I cannot reproduce this behaviour) What I tried to do was rebuild GREP from the original source, add your patches, and then run the new Autoconf, followed by configure. However, it looks as though Autonconf is failing for some reason and therefore the original configure script is being used and results in this selection of a BSD install - which I don't really understand:- + echo -n 'checking for a BSD compatible install... ' checking for a BSD compatible install... + echo 'configure:577: checking for a BSD compatible install' + test -z '' ++ echo '${ac_cv_path_install+set}' + eval 'test "${ac_cv_path_install+set}" = set' ++ test '' = set + IFS= + ac_save_IFS= + IFS=: + test -x c:/usr/bin/ginstall + test -x c:/usr/bin/scoinst + test -x c:/usr/bin/install + test -x c:/emx/bin/ginstall + test -x c:/emx/bin/scoinst + test -x c:/emx/bin/install + test -x c:/usr/local/bin/ginstall + test -x c:/usr/local/bin/scoinst + test -x c:/usr/local/bin/install + test -x c:/os2/ginstall + test -x c:/os2/scoinst + test -x c:/os2/install + test install = install + grep dspmsg c:/os2/install + ac_cv_path_install=c:/os2/install -c + break 2 + IFS= > bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Redmond where the Shadows lie. -- John **= Email 9 ==========================** Date: Sat, 9 Mar 2002 15:49:35 +0000 From: John Poltorak Subject: Building GREP I would like to be able to build GREP using a standard GNU build procedure with gcc 3.0.3, Make 3.79.1, Autoconf 2.53, Automake 1.6 using the original source along with OS/2 patches, although it doesn't sound possible currently. What would need to be changed to allow this? I think we are very close to having an uptodate build environment on OS/2, although I'm not exactly sure what is still required... -- John **= Email 10 ==========================** Date: Sat, 09 Mar 2002 16:15:57 -0500 From: Henry Sobotka Subject: Re: [XFreeOS2] giflib Dave and Natalie wrote: > > Has anyone ported giflib (ftp://sunsite.unc.edu/pub/Linux/libs/giflib/giflib-4.1.0.tar.gz) ideally with dll lib and headers? I've got a gif.[dll|lib|a] in Xfree86/lib and lib_gif.h in include but can't find the archive they came in. Probably got it from one of the XF2 sites. h~ **= Email 11 ==========================** Date: Sat, 09 Mar 2002 16:27:33 -0500 From: Henry Sobotka Subject: Re: Autoconf 2.52h John Poltorak wrote: > > I think some *FLAGS may be set which could interfere with the defaults > used when building Perl. No *FLAGS in the environment here which may explain why I'm not seeing that problem. > What I was wondering was whether there is any way to create a wrapper > which sets all environment variables to null so that we can set up exactly > those variables which are required rather than inheriting some settings by > mistake... Offhand I can't think of any special settings that a Perl build requires. Just a functioning emx+gcc environment and whatever it takes to get the tools running properly. > a discrete Perl build kit which will work in isolation from the normal > UnixOS/2 environment... I think that would be overkill. Perl's build machinery is unique, but the tools it uses are basically the normal ones. > Are you able to get problems resolved? > > There seem to be two outstanding problems at the moment:- > > 1. 'Make install' does not work AFAICS because of the presence of INSTALL Right, but running installperl gets the job done, and "make install" works fine for extra modules so I haven't yanked hairs over it. Which is not to say that it shouldn't be fixed, but simply that my itches lie elsewhere. > 2. One of the tests does not work. This appears to be REXX related and is > probably specifically devised for OS/2. Similarly, the REXX extension is not something I use. If you really want it fixed, report the test failure to the module's author. h~ **= Email 12 ==========================** Date: Sat, 09 Mar 2002 17:28:14 +0000 From: "Dave and Natalie" Subject: Re: giflib On Sat, 9 Mar 2002 21:20:01 +0000, John Poltorak wrote: >On Sat, Mar 09, 2002 at 12:09:44PM +0000, Dave and Natalie wrote: >> Has anyone ported giflib (ftp://sunsite.unc.edu/pub/Linux/libs/giflib/giflib-4.1.0.tar.gz) ideally with dll lib and headers? > > >I have a GIFDLL.ZIP but don't recall where I got it from. It was probably >ported by HCChiu, so I guess it came from either Hobbes, LEO or UnixOS2. > This is from http://pluto.spaceports.com/~os2/main_news.html, unluckily just a DLL. Found a full archive at Holgers site, ported by HCChiu Dave **= Email 13 ==========================** Date: Sat, 9 Mar 2002 21:04:34 +0000 From: John Poltorak Subject: Re: Make problem On Sat, Mar 09, 2002 at 09:06:39PM +0100, Holger Veit wrote: > Wrong way. If UNIXROOT is not defined, the program should complain > about this and terminate immediately. Personally, I would prefer it if the default for UNIXROOT was the boot drive if not otherwise defined... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 14 ==========================** Date: Sat, 9 Mar 2002 21:06:39 +0100 From: Holger Veit Subject: Re: Make problem On Sat, Mar 09, 2002 at 09:24:20PM +0900, Jun Sawataishi wrote: > Andreas wrote: > >However, the question arises: Why a hardcoded prefix > >at all? One could define that all programs should look > >in $UNIXROOT/whatever and only there. > >But in this case if anybody wants to compile and install > >GNU foo in g:/test/foo he isn't able to do so because > >every request is redirected to $UNIXROOT (which might be d:). > This is a real problem. > Possible solution is: > Search for UNIXROOT, UNIXROOT1, UNIXROOT2, UNIXROOT3 No, this is the wrong way. And it is not a problem, because everyone can take GNU sources and write a port for himself if he likes to. The topic here is UnixOS/2, not general GNU support for everybody's odd system setup. If you want to have a "UnixOS/2"("trademark!"), then the rule of the game is: everything under UNIXROOT. Not UNIXROOT1, not MYOWNUNIX or SPECIALETCDIR or SUPERGNUTOOLS, or whatever some ill-minded soul wants to call some private version. I don't think we should provide the catch-everything solution to serve any possible master in the world, but a single working solution that is consistently maintained through all packages we call "UnixOS/2" compliant. > Example in foo.c > #define SYSCONFDIR "/etc" > > conf_file = unixrootify(SYSCONFDIR); > When UNIXROOT is "x:" and "x:/etc" exist, > conf_file = "x:/etc" > When UNIXROOT is absent or $UNIXROOT/etc > is absent, and UNIXROOT1=y: and y:/etc exists > conf_file="y:/etc" Wrong way. If UNIXROOT is not defined, the program should complain about this and terminate immediately. I have a crt0.o im my repository which will check for the IX.SYS driver (and get the syscall() callgate address from it) - if it does not find the IX.SYS driver installed, it will write a message to handle 1 and exit. The IX.SYS driver itself will require UNIXROOT to be defined, otherwise it won't start up. You can accept this policy or not - if not, UnixOS/2 code won't run (it is not too different from the policy that you have to install EMX.DLL to run EMX apps). > Implementation of unixrootify() like this is not difficult. A possible template code is the XOS2RedirRoot code in XFree86/OS2. The drawback is - neither XOS2RedirRoot nor unixrootify should be visible in any user code; it is too easy to forget one location where this has to be added, and it will result in requests like the above "I want to install this in g:/test/foo - so please add some hack to disable unixrootify again or extend it with a UNIXROOT1". Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 15 ==========================** Date: Sat, 9 Mar 2002 21:20:01 +0000 From: John Poltorak Subject: Re: giflib On Sat, Mar 09, 2002 at 12:09:44PM +0000, Dave and Natalie wrote: > Has anyone ported giflib (ftp://sunsite.unc.edu/pub/Linux/libs/giflib/giflib-4.1.0.tar.gz) ideally with dll lib and headers? I have a GIFDLL.ZIP but don't recall where I got it from. It was probably ported by HCChiu, so I guess it came from either Hobbes, LEO or UnixOS2. > Dave > > -- John **= Email 16 ==========================** Date: Sat, 9 Mar 2002 21:24:20 +0900 From: Jun Sawataishi Subject: Re: Make problem Andreas wrote: >However, the question arises: Why a hardcoded prefix >at all? One could define that all programs should look >in $UNIXROOT/whatever and only there. >But in this case if anybody wants to compile and install >GNU foo in g:/test/foo he isn't able to do so because >every request is redirected to $UNIXROOT (which might be d:). This is a real problem. Possible solution is: Search for UNIXROOT, UNIXROOT1, UNIXROOT2, UNIXROOT3 Example in foo.c #define SYSCONFDIR "/etc" conf_file = unixrootify(SYSCONFDIR); When UNIXROOT is "x:" and "x:/etc" exist, conf_file = "x:/etc" When UNIXROOT is absent or $UNIXROOT/etc is absent, and UNIXROOT1=y: and y:/etc exists conf_file="y:/etc" ................ Implementation of unixrootify() like this is not difficult. # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/ **= Email 17 ==========================** Date: Sat, 9 Mar 2002 22:01:59 +0900 From: Jun Sawataishi Subject: Re: Shell issues, was: Re: Autoconf 2.52h John P. wrote: >ASH is no longer maintained - maintainer has disappeared. >BASH old version - maintainer's plans for update not known >PDKSH recent release - active maintainer >TCSH old version - maintainer's plans for update not known >ZSH is no longer maintained - maintainer not known >> 2) bash.exe: has a strange drive letter handling algorithm (cuts >> the first two characters of a directory under certain circumstances). I may be a maintainer for bash. I have mentioned before, OS/2 port of bash 2.05 and bash 2.05a have already finished. Drive letter problems have fixed . Here I show a description from README_bash-2.05a.OS2 (I am writing instruction). >Fixed Problems of older version  >===============================  > OS/2 ported bash 2.00 to 2.03 had a buggy feature on current > working directory. I have fixed them.    >Shell command pwd returns true absolute path >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In older port: > $ pwd > $ /foo/bar # should be x:/foo/bar  > $ ls /foo   > Now  > $ pwd > $ x:/foo/bar >Preservation of current directory in each drive >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Change drive : Now you can change drive freely without affecting a > current directory of drives. Older port of bash > was unable to do this. > e.g. > [c:/] cd os2 > [c:/os2] cd g: > [g:/] cd usr > [g:/usr] cd c: > [c:/os2] cd g: > [g:/usr] Other improvements includes: Works fine in virtual terminals of XFree86 for OS/2 - Alt + [a-z0-1] key are available - can recognize window size correctly - file name completion works fine Menu oriented file/directory selection mode Using ncurses 5.2 (menu) Pushing ALT-key and `i' simultaneously, or push ESC-key followed by `i'. You will see a menu like this.   at --------- 12 possible completions --------- at   +------------------------+ |-x:/usr/ / : 0| | x:/usr/TclTk / : 1| | x:/usr/bin / : 2| | x:/usr/dll / : 3| | x:/usr/doc / : 4| | x:/usr/etc / : 5| | x:/usr/html / : 6| | x:/usr/include / : 7| | x:/usr/lib / : 8| | x:/usr/libexec / : 9| | x:/usr/man / : 10| | x:/usr/share / : 11| | x:/usr/src / : 12| +------------------------+  Pushing ALT-key and `m' simultaneously on command line will  create menu window for drive lists.   at --------- 19 possible completions --------- at   +-------------------------------+ |-C:/ / : 0| | D:/00upload/bash-2.05 / : 1| | E:/ / : 2| | F:/ / : 3| | G:/usr/dll / : 4| | H:/ / : 5| | I:/ / : 6| | J:/ / : 7| | K:/ / : 8| | L:/ / : 9| | M:/ / : 10| | N:/ / : 11| | O:/ / : 12| | P:/GNU / : 13| Using menu mode, one can change directory or view files easily. One can define which program is used to view a file according to its suffix (.exe, .dll, .gif, .txt, ........) in $HOME/.inputrc . In my mind, uploading bash 2.05a for OS/2 is top priority. Please wait for a while. (Please believe me. I wish someone presses me hard for bash or other already ported software about which I had said "Please wait for a while". ) # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/