From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 6 Mar 2002 04:19:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 155 ************************************************** Tuesday 05 March 2002 Number 155 ************************************************** Subjects for today 1 Re: Autoconf 2.52h : Andreas Buening 2 Re: Make problem : Andreas Buening 3 Re: Make problem : Andreas Buening 4 Re: Freesco : Stepan Kazakov 5 Re: %UNIXROOT% : John Poltorak 6 Re: Make problem : csaba.raduly at sophos.com 7 EXTPROC : John Poltorak 8 Re: Autoconf 2.52h : Stefan Neis 9 Re: %UNIXROOT% : Holger Veit 10 BSD compatible install... c:/os2/install -c : John Poltorak 11 Re: EXTPROC : csaba.raduly at sophos.com 12 Autoconf & lstat : John Poltorak 13 os2.m4 in Autoconf : John Poltorak 14 Re: EMX port of Python... : Andrew MacIntyre 15 Shell issues, was: Re: Autoconf 2.52h : Thomas Hoffmann **= Email 1 ==========================** Date: Wed, 06 Mar 2002 00:33:52 +0100 From: Andreas Buening Subject: Re: Autoconf 2.52h John Poltorak wrote: [snip] > BTW PDKSH includes sh.exe as well as ksh.exe. I always use sh.exe, but > have no idea what difference is between them... I guess, sh.exe is compiled without some extra features. For a noninteractive shell you e.g. don't need any fancy command line key mappings. 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. **= Email 2 ==========================** Date: Wed, 06 Mar 2002 00:34:01 +0100 From: Andreas Buening Subject: Re: Make problem lamikr wrote: > > What is causing this the drive-letter based hardcoding? (I am have my OS/2 build > systems in > f:\unixos2\usr...) Two possible reasons: a) nls support. The message files are harcoded to e:/usr/share/locale (at least on my system), but this is handled by gettext, not by make itself (which normally should mean that first e:/usr/share/locale is checked for those files and than other directories). b) There is a hardcoded INCLUDEDIR (== $prefix/include) within the make code but it seems to have no real sense. At least I can't imagine a reason why make should have an advantage of having a special include directory. All necessary targets and dependencies should be defined within the Makefile. But I wouldn't care about that. In principle make is prefixdir-independent. I've only implemented that make uses $UNIXROOT/bin/sh if it doesn't find /bin/sh. That's all. However, to avoid thing like "Drive x: not ready" binaries should be built for "c:". 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. **= Email 3 ==========================** Date: Wed, 06 Mar 2002 00:34:12 +0100 From: Andreas Buening Subject: Re: Make problem John Poltorak wrote: > > On Tue, Mar 05, 2002 at 08:13:34PM +0100, Andreas Buening wrote: > > John Poltorak wrote: > It makes me think that it is probably better to build apps directly on the > target system rather than simplying installing them with hard-coded paths > which are not relevant.... > > One idea I had was to include some sort of patching of hard-coded paths as > part of the install process so that c: would be changed to the value of > %UNIXROOT% by the installer. > > Does anyone foresee any problems in doing something like that? If you compile with /exepack:2, i.e. with compression you shouldn't have any strings in the executable you can simply change. 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. **= Email 4 ==========================** Date: Wed, 06 Mar 2002 00:45:37 -0500 From: Stepan Kazakov Subject: Re: Freesco John Poltorak wrote: > > second: > > there is bridging solution in IBM product - Lan Distance (included in WS/WSeb); > Whereabouts is LAN Distance on the WSeB CD? I'll see what I can do with > it. 'network selective install' i think. -- madded. [Red Hot Chili Hackers] **= Email 5 ==========================** Date: Wed, 6 Mar 2002 09:16:09 +0000 From: John Poltorak Subject: Re: %UNIXROOT% On Tue, Mar 05, 2002 at 06:53:36PM +0000, Dave and Natalie wrote: > 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? --prefix=$UNIXROOT/usr is used by the configure script when building an app and this _resolved_ path normally appears embedded somewhere in the .exe, that's why it is a good idea to build your own apps, tailored to your own environment. The use of $UNIXROOT is not a run time option AFAIK but gets hard coded. If it is not defined, I would expect it to be set to null, in which case you would have /usr. > Dave -- John **= Email 6 ==========================** Date: Wed, 6 Mar 2002 09:26:12 +0000 From: csaba.raduly at sophos.com Subject: Re: Make problem On 05/03/2002 23:34:01 Andreas B. wrote: [snip] >However, to avoid thing like "Drive x: not ready" >binaries should be built for "c:". > Which would give "Drive C: not ready" if C: is e.g. a CD drive (it's possible, I've done it with WSeB). -- 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 7 ==========================** Date: Wed, 6 Mar 2002 10:17:16 +0000 From: John Poltorak Subject: EXTPROC Is there any way to tell whether a program will work with EXTPROC? I seem to experience some problems when using BASH such as:- extproc: command not found The included script does appear to run however... If I use PDKSH, no such error occurs. When using ASH the msg is:- extproc: No such file or directory Try this CMD file using different shells:- extproc c:\bin\sh # MSG="Hello, world" echo $MSG I just wondered whether there was a problem with BASH or ASH, or does EXTPROC have a list of shells which it works with? -- John **= Email 8 ==========================** Date: Wed, 6 Mar 2002 10:26:05 +0100 (CET) From: Stefan Neis Subject: Re: Autoconf 2.52h On Tue, 5 Mar 2002, Andreas Buening wrote: > > E.g. even if perl is working best with - maybe - pdksh for sh.exe, all > > standard autoconf-configure-make software might prefer a different shell. > > 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. Well, "just" fix all the shells. They all use their own magic to handle e.g. path translation and similar OS/2 specific stuff and they currently just _are_ different in a number of areas where they behave identical on any true Unix system ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 9 ==========================** Date: Wed, 6 Mar 2002 10:29:37 +0100 From: Holger Veit Subject: Re: %UNIXROOT% On Wed, Mar 06, 2002 at 09:16:09AM +0000, John Poltorak wrote: > On Tue, Mar 05, 2002 at 06:53:36PM +0000, Dave and Natalie wrote: > > 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? > > --prefix=$UNIXROOT/usr > > is used by the configure script when building an app and this _resolved_ path > normally appears embedded somewhere in the .exe, that's why it is a good > idea to build your own apps, tailored to your own environment. The use of > $UNIXROOT is not a run time option AFAIK but gets hard coded. If it is not > defined, I would expect it to be set to null, in which case you would have > /usr. 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. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 10 ==========================** Date: Wed, 6 Mar 2002 11:47:40 +0000 From: John Poltorak Subject: BSD compatible install... c:/os2/install -c 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... -- John **= Email 11 ==========================** Date: Wed, 6 Mar 2002 12:34:16 +0000 From: csaba.raduly at sophos.com Subject: Re: EXTPROC On 06/03/2002 10:17:16 owner-os2-unix wrote: >Is there any way to tell whether a program will work with EXTPROC? > >I seem to experience some problems when using BASH such as:- > >extproc: command not found > >The included script does appear to run however... If I use PDKSH, no such >error occurs. [snip] > >extproc c:\bin\sh ># >MSG="Hello, world" >echo $MSG > AFAIU, extproc simply invokes the command with the present filename Therefore, the "shell" will see the extproc line. In case of Perl, the .CMD file begins with: extproc perl -wSx #!perl -wSx The -x switch tells perl to *ignore* everything until the #!perl line (-S tells perl to search the path, because extproc only passes the filename, not the full path; this way you can call .CMDs not in the current directory). It looks like the shells have no provision to skip the extproc line itself. One possible workaround would be to copy echo.exe to extproc.exe :-) -- 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 12 ==========================** Date: Wed, 6 Mar 2002 16:02:49 +0000 From: John Poltorak Subject: Autoconf & lstat In the OS/2 port of Autoconf v2.50 there is some code specifically added for handling requirements for lstat() among other things. Is there any chance of getting that code bundled into Autoconf v2.52i ? -- John **= Email 13 ==========================** Date: Wed, 6 Mar 2002 18:43:31 +0000 From: John Poltorak Subject: os2.m4 in Autoconf Here's a reply I got from the autoconf list about including OS/2 specific code:- On Wed, Mar 06, 2002 at 06:59:28PM +0100, Akim Demaille wrote: > >>>>> "John" == John Poltorak writes: > > John> test -f $THISPLATFORM.m4 && use $THISPLATFORM.m4 > > In lib/autom4te.cfg, you add: > > ## ---------- ## > ## Autoconf. ## > ## ---------- ## > > begin-language: "Autoconf" > # patterns: "*.ac" > # patterns: "configure.in" > args: --include /usr/local/share/autoconf > args: autoconf/autoconf.m4f > args: acsite.m4? > 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? 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? -- John **= Email 14 ==========================** Date: Wed, 6 Mar 2002 18:54:11 +1100 (EDT) From: Andrew MacIntyre Subject: Re: EMX port of Python... On Tue, 5 Mar 2002, Jeff Robinson wrote: > Does this mean that (soon) I will be able to just grab the source > distribution of Python and build it myself... thus having the proper > pre-makefile that is required to build Zope...? Starting with Python 2.3, you should be able to build from the release tarball. I've looked at Zope a time or two, going so far as to d/l the source for several versions, but haven't had the spare cycles to give it a serious attack. At this stage, I suspect that some work will be required to get Zope running :-( -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 15 ==========================** Date: Wed, 06 Mar 2002 21:05:54 +0100 From: Thomas Hoffmann Subject: Shell issues, was: Re: Autoconf 2.52h 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 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. 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 ...