From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 7 Mar 2002 04:19:06 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 156 ************************************************** Wednesday 06 March 2002 Number 156 ************************************************** Subjects for today 1 Re: %UNIXROOT% : Dave and Natalie" 2 Re: Shell issues, was: Re: Autoconf 2.52h : csaba.raduly at sophos.com 3 Re: Shell issues, was: Re: Autoconf 2.52h : John Poltorak 4 Re: M4 tutorial : Henry Sobotka 5 Re: INFO2INF ? : Henry Sobotka 6 M4 tutorial : John Poltorak 7 Re: Re: Viewing Perl POD docs : John Poltorak 8 INFO2INF ? : John Poltorak 9 Re: Autoconf 2.52h : Henry Sobotka 10 Automake v1.6 : John Poltorak 11 Re: Autoconf 2.52h : John Poltorak 12 Re: INFO2INF ? : John Poltorak 13 Re: INFO2INF ? : Yuri Prokushev" 14 Re: INFO2INF ? : Yuri Prokushev" 15 Re: %UNIXROOT% : Jun Sawataishi **= Email 1 ==========================** Date: Thu, 07 Mar 2002 07:31:03 +0000 From: "Dave and Natalie" Subject: Re: %UNIXROOT% On Wed, 6 Mar 2002 10:29:37 +0100, Holger Veit wrote: > >UNIXROOT is a "does not exist" for configure. Assume that you have a >Unix compliant filesystem under OS/2, i.e. no drive letters and the >directory layout according to the FHS standard. Thus, you would configure >your application to install in /usr or /usr/local or alike, as you would >do so under Unix, and leave the real translation that converts >"/usr/bin/foo.bar" to "c:\unixos2\usr\bin\foo.bar" to the runtime system. Looks like I should keep on doing what I'm doing --prefix-/usr. Dave **= Email 2 ==========================** Date: Thu, 7 Mar 2002 09:19:54 +0000 From: csaba.raduly at sophos.com Subject: Re: Shell issues, was: Re: Autoconf 2.52h On 06/03/2002 20:05:54 owner-os2-unix wrote: >Fine, so let's start to collect problems of the different shells >and talk the respective maintainers in fixing "their" shells. > >I some time ago mentioned 2 problems that exclude any shell from >being sufficient for all my unix-like tasks: > >1) all but bash.exe: the asynchronity problem: if a shell calls >a shell script, then it does not wait for finishing of the script >before issuing the next command > Heh. I only saw this problem *with* bash. Never with pdksh. -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 3 ==========================** Date: Thu, 7 Mar 2002 09:25:15 +0000 From: John Poltorak Subject: Re: Shell issues, was: Re: Autoconf 2.52h On Wed, Mar 06, 2002 at 09:05:54PM +0100, Thomas Hoffmann wrote: > Fine, so let's start to collect problems of the different shells > and talk the respective maintainers in fixing "their" shells. I've been trying to put together a list of issues with various shells for some time, but there seems to be little interest in doing so. In addition, I'm not sure how many shells are actively maintained... 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 What other shells are available? > I some time ago mentioned 2 problems that exclude any shell from > being sufficient for all my unix-like tasks: > > 1) all but bash.exe: the asynchronity problem: if a shell calls > a shell script, then it does not wait for finishing of the script > before issuing the next command > > 2) bash.exe: has a strange drive letter handling algorithm (cuts > the first two characters of a directory under certain circumstances). > > Further details on request. Let's get all the issues listed so that we all know what problems do exist. Maybe there are work arounds for some of them. > Andreas Buening schrieb: > > > > And exactly this misbehaviour must really be removed. > > I've never heard of a Unix user who had to things like > > > > rm /bin/sh > > cp -p /usr/local/bin/ksh /bin/sh > > > > to get one specific software package installed. > > -- > Thomas Hoffmann Telephone: > 49-351-4598831 > thoffman at zappa.sax.de Dresden, > Germany > > ..sig under construction ... -- John **= Email 4 ==========================** Date: Thu, 07 Mar 2002 09:25:28 -0500 From: Henry Sobotka Subject: Re: M4 tutorial John Poltorak wrote: > > Does anyone know if anything like an M4 tutorial exists anywhere? Don't know, but m4.texinfo is pretty thorough. h~ **= Email 5 ==========================** Date: Thu, 07 Mar 2002 09:41:17 -0500 From: Henry Sobotka Subject: Re: INFO2INF ? John Poltorak wrote: > > Has anyone come across and INFO to INF converter? > > Or maybe a PM version of the INFO viewer? emacs works pretty well. You can add entries to the DIR file and access them from Help->Browse Manuals. Another conversion path is to use texi2html and then a browser. h~ **= Email 6 ==========================** Date: Thu, 7 Mar 2002 11:25:42 +0000 From: John Poltorak Subject: M4 tutorial Does anyone know if anything like an M4 tutorial exists anywhere? I don't really have any idea why it is specifically used by Autoconf, but it seems pretty fundamental to having an understanding of how Autoconf works. -- John **= Email 7 ==========================** Date: Thu, 7 Mar 2002 11:39:58 +0000 From: John Poltorak Subject: Re: Re: Viewing Perl POD docs On Tue, Mar 05, 2002 at 07:34:21PM +0900, Masaru Nomiya wrote: > Hello, > > In the Message; > > Subject : Viewing Perl POD docs > Message-ID : <20020305101149.T92 at eyup.org> > Date & Time: Tue, 5 Mar 2002 10:11:50 +0000 > > [John] == John Poltorak has written: > > John> What should I use to view Perl POD files? > > I use perldoc.cmd which I made this by inserting > > extproc perl.exe -Sx > > at the top line of the perldoc, and save as perldoc.cmd. Thanks, I tried that, but got this error msg:- Superuser must not run C:\USR\PROCLIB/perldoc.cmd without security audit and taint checks. Any idea what it means or what I should do? I guess it must have something to do with my PASSWD file... > Regards, > > --- > Masaru Nomiya mail-to: nomiya at ttmy.ne.jp > > "No WIndows, no gains!" ..... "Why, I am wrong?" > > -- Bill -- -- John **= Email 8 ==========================** Date: Thu, 7 Mar 2002 12:10:06 +0000 From: John Poltorak Subject: INFO2INF ? Has anyone come across and INFO to INF converter? Or maybe a PM version of the INFO viewer? I find GNU INFO very awkward to use. Wonder if it is configurable as far keyboard definitions go... -- John **= Email 9 ==========================** Date: Thu, 07 Mar 2002 12:17:21 -0500 From: Henry Sobotka Subject: Re: Autoconf 2.52h John Poltorak wrote: > > Should I be able to generate a > configure script from a configure.in containing only? :- > > AC_PROG_AWK > > I get some error msg about m4_defn - undefined macro... Starting with AC_INIT will get rid of that, i.e. you need: AC_INIT AC_PROG_AWK > Is it possible to get a copy of your config.sh with some notes explaining > changes to the defaults? Sure, if you tell me which one(s) you want (5.6.1 and/or 5.7.2) and where to put it as there's no point flogging everyone on the list with the attachment(s). Unfortunately, I don't have time to annotate them but recall changing the compilation/linkage flags (for pgcc, more optimization, warnings full-blast), un-undefining functions I know to be available in EMX libc, ditto for any utilities/programs that I have installed but found set to empty strings, turning on 64-bit-math-via-long-long support, and (moreso with 5.7.2) playing around with the module list and other options (all of which are amply documented in Config.PM). h~ **= Email 10 ==========================** Date: Thu, 7 Mar 2002 14:37:00 +0000 From: John Poltorak Subject: Automake v1.6 GNU Automake v1.6 has just been released. It's available here:- ftp://ftp.mirror.ac.uk/sites/ftp.gnu.org/pub/gnu/automake/automake-1.6.tar.gz I wonder what the chances are of this working under OS/2... Looking at the last OS/2 port of v1.4-p5 there were only two files patched and those patches were pretty minimal and now one of those files is not included any more. Has anyone given this new version a try? -- John **= Email 11 ==========================** Date: Thu, 7 Mar 2002 15:12:07 +0000 From: John Poltorak Subject: Re: Autoconf 2.52h On Tue, Mar 05, 2002 at 11:21:25AM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > OK, maybe 'correct' is the wrong word, but being able to build Perl is an > > indication of having, as you say, a healthy environment. > > Again, for building Perl. Sure, the Perl build uses many of the standard > tools, but it's an exceptional system with all kinds of OS/2- and > EMX-specific tweaks. Just about any mainstream GNU package that uses the > routine configure-make system would be a more reliable indicator. Possibly so, but Perl is quite a big app and it's pretty satisfying to build something like this for yourself. I would never have contemplated it without a number of people here saying they had built it. > > > Stringing a selection of AC* macros > > > together in a configure.in and running that to check the setup might > > > make for a more suitable test; since the macros are there and a cinch to > > > work with, why not use them? > > > > Care to amplify? > > Instead of writing an elaborate shell script, create a configure.in > containing, for example: > > AC_INIT > AC_PROG_CPP > AC_PROG_CXXCPP > AC_PROG_AWK > AC_PATH_PROGS(EMACS, xemacs lemacs emacs, :) > AC_PATH_PROGS(PERL, $PERL perl5 perl ) > AC_PATH_PROG(WHOAMI, whoami, :) > AC_PATH_PROG(AUTOCONF, autoconf, :) > AC_PATH_PROG(UNZIP, unzip, :) > AC_PATH_PROGS(ZIP, zip) > AC_CHECK_LIB(cposix,strerror) > > Feed it to autoconf to create configure, snip out the block of > substitutions at the end, and rename it "check-unixos2" or whatever. > You've got a ~1250-line script that runs those particular tests. My > point is simply that the above 11 macros are easy to write and make > exactly what we're checking for.clear at a glance. There are all kinds > of other macros available (e.g. AC_TRY_COMPILE) and obviously this > should be done properly by someone more familiar with the full range of > macros. I'm not sure that we have many people sufficiently familiar with Autoconf to make it as comprehensive as you suggest. But maybe if we start with something basic, it can be enhanced over time. However, I can't even get started with getting this working... Should I be able to generate a configure script from a configure.in containing only? :- AC_PROG_AWK I get some error msg about m4_defn - undefined macro... > > > > I'd like to document a procedure which ought to create a specific build, > > > > > > What's wrong with Ilya's detailed instructions in the OS/2 section of > > > the Perl docs? > > > > Well, detailed instructions are not the same as a build script. They can > > easily be misinterpreted or make assumptions which are not valid. > > I took "document a procedure..." to mean write a how-to-build doc. A > script is a whole other ballgame. OK, I phrased it badly... I meant document=write procedure=script :-)... > > > Any two people who follow them to the letter, have the > > > same source, matching toolkits, and go with the default values, i.e. > > > don't edit config.sh, should get identical results. > > > > Maybe they should but they don't. I recently compared my results against > > yours and found a large number of differences. AFAIAA I followed the > > instructions as best I could. I used the same source and the only change I > > made to the defaults was the value of PREFIX. However, the main difference > > is probably due to toolkits. Until a standard toolkit is defined and > > accepted, we are bound to have differences. > > But I hadn't built with the defaults; I went through config.sh line by > line, making all kinds of adjustments before building. Yet the first > times I built Perl a few years ago with zero tweaks I remember getting > test results identical to those Ilya discusses in the doc. Is it possible to get a copy of your config.sh with some notes explaining changes to the defaults? > h~ -- John **= Email 12 ==========================** Date: Thu, 7 Mar 2002 15:31:01 +0000 From: John Poltorak Subject: Re: INFO2INF ? On Thu, Mar 07, 2002 at 09:19:34PM -0500, Yuri Prokushev wrote: Please don't Cc: to the list. There is some sort of problem with Majordomo and the Cc:ed copy ends up blank. > On Thu, 7 Mar 2002 12:10:06 +0000, John Poltorak wrote: > > >Has anyone come across and INFO to INF converter? > >Or maybe a PM version of the INFO viewer? > >I find GNU INFO very awkward to use. Wonder if it is configurable as far > >keyboard definitions go... > texi2inf can be solution. > How do you suggest this is done? Personally, I'd like to see this automated through the build system so if the Makefile has a a target of foo.info, then foo.inf is also built. I don't know how this could be done, maybe some tweaks to Automake could achieve this, assuming we can find a good texi2inf converter... Last time I checked there seemed to be quite a few problems. -- John **= Email 13 ==========================** Date: Thu, 07 Mar 2002 21:19:34 -0500 (EST) From: "Yuri Prokushev" Subject: Re: INFO2INF ? **= Email 14 ==========================** Date: Thu, 07 Mar 2002 22:32:15 -0500 (EST) From: "Yuri Prokushev" Subject: Re: INFO2INF ? On Thu, 7 Mar 2002 15:31:01 +0000, John Poltorak wrote: >Please don't Cc: to the list. There is some sort of problem with Majordomo >and the Cc:ed copy ends up blank. Ok >> >Has anyone come across and INFO to INF converter? >> >Or maybe a PM version of the INFO viewer? >> >I find GNU INFO very awkward to use. Wonder if it is configurable as far >> >keyboard definitions go... >> texi2inf can be solution. > >How do you suggest this is done? Just execute texi2inf. :) >Personally, I'd like to see this automated through the build system so if >the Makefile has a a target of foo.info, then foo.inf is also built. I don't know about texinfo to info compilation, but you can use a texicompiler wrapper. e.g. rename makeinfo to makegnuinfo, make new makeinfo file wich will execute texti2inf and makeinfo. (This is if you don't want to change each makefile) >I don't know how this could be done, maybe some tweaks to Automake could >achieve this, assuming we can find a good texi2inf converter... Last time >I checked there seemed to be quite a few problems. All my texinfo files was converted fine (instead some russian texinfo files). Was used texi2ipf - Texinfo to OS/2 IPFC source file converter ----------------------------------------------------- This program is a modified version of texi2roff. texi2roff is Copyright 1988, 1989, 1990 by Beverly A. Erlebacher texi2ipf was written by Marcus Groeber 1992/93 and modified by Martin "Herbert" Dietze 1996 **= Email 15 ==========================** Date: Thu, 7 Mar 2002 23:18:16 +0900 From: Jun Sawataishi Subject: Re: %UNIXROOT% >So how do you get a program to use %UNIXROOT%. Is it as simple as >--prefix=$UNIXROOT/usr or do you have to hack the code? If so could >I see an example Also what happens if %UNIXROOT% isn't defined? >Dave Introduction of UNIXROOT env. var. has beed discussed a lot in this mailing list. I think: When porting Open Source Softwares, we __must__ make a strong effort to introcude UNIXROOT. Here I list OSSs for which I have modified source code to use UNIXROOT. OSS status -------------------------------------------------------------- - bash 2.05, 2.05a WF, IN - a2ps 2.13b WF, IN - man 1.5j WF, IN - GNU groff 1.17.2 WF, IN - Red Hat rpm 4.0.2 WF, IN - VFlib 3.7.12 WF, IN - TeX-Guy 1.2.4 WF, IN WF: working fine in my machine IN: writing instruction is not completed ID: writing instruction completed, but not uploaded I think we should not run configure with "-prefix=$UNIXROOT/usr". By doing this path or directory may be hard-coded in executables. To avoid this risk, I use a function "char *unixrootify(const *char)". unixrootify returns ' getenv("UNIXROOT") + FOO ' if UNIXROOT is not empty, if it is empty 'drive name of HOME + FOO '. c.f. In Makefile: $(CC) -DFOO=\"/usr/share/foo\" ......... -c bar.c In bar.c #define libdir FOO ............... From f = FOO; To #ifndef __EMX__ f = FOO; #else f = unixrootify(FOO); #endif To install a program do like this. If Makefile suppourt DESTDIR: $ make install DESTDIR=${UNIXROOT} If not $ make install prefix=${UNIXROOT}/usr datadir=${UNIXROOT}/usr/share \ mandir=${UNIXROOT}/usr/share/man infodir=${UNIXROOT}/usr/share/info\ .............. By using UNIXROOT env. var. in source code level, program can be run without any env. vars which indicate location of files except for UNIXROOT. I think new emx library should contain function like unixrootify. Already introduced ? #ifdef __EMX__ char *unixrootify(char *src) { if (src[0] == '/') { const char *unixroot = getenv("UNIXROOT"); const char *home = getenv("HOME"); char *buf; buf = (char *)xmalloc(strlen(src) + 5); if ( unixroot && *unixroot != '\0') { if ( (strlen(unixroot) == 2 ) && (unixroot[1] == ':') ) { sprintf(buf, "%s%s", unixroot, src); return buf; } } else if ( home && home[0] != '\0') { if ( strlen(home) > 2 && home[1] == ':' ) { strcpy(buf, home); buf[2] = '\0'; strcat(buf, src); return buf; } } else { free(buf); fprintf(stderr, "\nError: You should define UNIXROOT env var\n"); fprintf(stderr, " for %s\n", src); } } return src; } #endif /* __EMX__ */ Problem of UNIXROOT When a drive specified by UNIXROOT lacks enough space, one must install program another drive. In such a case, he/she must make a wrapper script/batch file which defines UNIXROOT diffrent from config.sys. A solution may be simple. unixrootify() searches for UNIXROOT, UNIXROOT_1, UNIXROOT_2, ..... I'd like to discuss on UNIXROOT. # OS/2 is not a question, it's a solution. # SAWATAISHI Jun # http://www2s.biglobe.ne.jp/~vtgf3mpr/