From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 10 Mar 2002 04:19:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 159 ************************************************** Saturday 09 March 2002 Number 159 ************************************************** Subjects for today 1 Re: Autoconf 2.52h : Andreas Buening 2 Re: os2.m4 in Autoconf : Andreas Buening 3 Re: Make problem : Andreas Buening 4 Re: Make problem : James Cannon 5 Re: Make problem : Holger Veit 6 Make problem with Gettext 0.11 : John Poltorak 7 Gettext v0.11 : John Poltorak 8 Re: Make problem : John Poltorak 9 Re: Make problem with Gettext 0.11 : John Poltorak 10 Re: Make problem : Dave and Natalie" 11 Re: Make problem : Dave and Natalie" 12 Re: Make problem : Dave and Natalie" 13 Re: Make problem : John Poltorak 14 Re: Make problem : Lyn St George" 15 Re: Make problem with Gettext 0.11 : Andreas Buening 16 Re: Make problem : Andreas Buening 17 Re: Make problem : Stefan Neis 18 Re: Make problem : Stefan Neis 19 Re: Make problem : John Poltorak 20 Re: Make problem : John Poltorak 21 Re: Make problem : John Poltorak 22 Re: Make problem with Gettext 0.11 : John Poltorak 23 Re: Make problem : Andreas Buening 24 Re: Make problem : Stefan Neis 25 Re: Make problem : Stefan Neis 26 Re: Make problem : Stefan Neis **= Email 1 ==========================** Date: Sun, 10 Mar 2002 01:45:30 +0100 From: Andreas Buening Subject: Re: Autoconf 2.52h Henry Sobotka wrote: > > Andreas Buening wrote: [snip] > > 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. Some of the scripts use env. vars like 'CONFIG' or 'TOP'. If you've already set one of them on your system you have a problem. They'd better use e.g. 'perl_config' or 'perl_top'. 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: Sun, 10 Mar 2002 01:48:51 +0100 From: Andreas Buening Subject: Re: os2.m4 in Autoconf John Poltorak wrote: > > 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? Not really. ;-) That autom4te.cfg file is divided into sections (languages). Every section starts with 'begin-language: "blurb"' and ends with 'end-language: "blurb"'. That code you've cited is part of the autoconf "language". "args: --language M4sh" means if the "autoconf" language is executed then also the "M4sh" language is executed. In the above case something will be done with os2.m4 and aclocal.m4 and some other "languages" will be executed. That's all I can say. > > > 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 It could be handled this way. But it makes the compilation more complicated than it ought to be. It should be as simple as you can imagine. With ./configure --prefix=blurb make make install you should be able to get something that works. If you want an additional feature (-Zomf, /exepack:2, -mpentium) you simply put this option into your flags. But if you need a bunch of options to get started at all then it becomes more and more difficult and the README files get longer and longer. > > initialize_main() would be a nice idea for autoconf. > > Would that help to eliminate most of the diffs from the textutils? No. It would allow to use a standardized treatment of _wildcard() & others. If you want to add a function to the default initialization (or to remove them at all for LIBEMU) then you change only autoconf, recompile the packages and that's it. > > 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. Until the build environment doesn't handle this it might be better to handle this individually for each package. There was a long discussion with Holger some weeks ago about that topic. [snip] 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: Sun, 10 Mar 2002 01:51:10 +0100 From: Andreas Buening Subject: Re: Make problem 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 Too complicated in my opinion. This would mean a loop over all allowed UNIXROOT variables until the file could be found, One $UNIXROOT should be enough. > 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. This might lead to a memory leak if the input file name was allocated. However, it's not only a hardcoded "/etc" that could be handled in a simple way by an #ifdef like: char *sysconfdir = SYSCONFIGDIR; ... /* before SYSCONFIGDIR is used the first time */ #ifdef __EMX__ sysconfdir = unix_do_something(sysconfdir); #endif then a "sed -e s/SYSCONFIGDIR/sysconfigdir/g" over all source files and that's it. The real problem is if there is a prefix dir that has explicitely specified by the user. If it is "/usr/share", you can add $UNIXROOT, but what if it is "e:/usr/share"? - Replace "e:" by $UNIXROOT => the user has no control over the prefix dir any more - Search for "e:/usr/share" and "$UNIXROOT/usr/share" => "e:" might be a CD ROM or ZIP drive on another system => annoying and time consuming access to that drive - Search for "e:/usr/share" only => no $UNIXROOT - No drive letters for prefix dirs in binary distributions, i.e. search for "/usr/share" and "$UNIXROOT/usr/share" => result depends on the current drive. I don't see how this problem can be solved 100% failure safe. The best solution I can think of is to use "c:" for all prefixes and implement $UNIXROOT support into all unixos2 packages. 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: Sun, 10 Mar 2002 08:29:47 -0800 (PST) From: James Cannon Subject: Re: Make problem Hi Holger, --- Holger Veit wrote: [HUGE SNIP] >So keep it simple: > UNIXROOT or nothing. > > Holger I'll have to agree on keeping it simple. When it comes to maintaining systems, one always asks, "Isn't there a better way". Then you get to the point of being backwards compatible with existing standards. The right design considerations up front will provide long lasting rewards. My take, parse the echo from set for UNIXROOT, if that fails, provide an answer .... "UNIXROOT not found, application can not proceed". Give the user an opportunity to provide one ... "set UNIXROOT variable?", if yes or no, provide name of document that explains the UNIXROOT variable. Then crap out. Of course, not being an active developer here, you can designate me as a "back seat driver". ===== Sincerely, James Cannon Using OS/2 Warp in the beautiful Wine Country of Northen California! __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ **= Email 5 ==========================** Date: Sun, 10 Mar 2002 11:44:22 +0100 From: Holger Veit Subject: Re: Make problem On Sat, Mar 09, 2002 at 09:04:34PM +0000, John Poltorak wrote: > 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... And what if the appropriate file system structure is not present there? You end up in complicated, and *thus necessarily* failing heuristics to locate things like /etc/passwd, /etc/hosts, /etc/services (are they in boot:\tcpip\etc or in boot:\mptn\etc or in %ETC% or even elsewhere). And these prominent files are just the simple cases? Where to obtain certain settings? XFree86/OS2 (and even to some degree EMX itself) is the well-known example that ordinary users cannot read docs that say "do first this, then that, and finally this". So any system that offers flexibility and provides complicated heuristics to identify messed up file and data structures is doomed to fail miserably. So keep it simple: UNIXROOT or nothing. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 6 ==========================** Date: Sun, 10 Mar 2002 12:56:41 +0000 From: John Poltorak Subject: Make problem with Gettext 0.11 According to README.OS2 in gettext-0.11:- 2. Go to os2 and just run `make'. If you have all the required tools, it should painlessly compile. Here is what I get when using Make 3.79.1:- sed: -e expression #1, char 8: Unterminated address regex sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #1, char 25: Unterminated address regex sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #1, char 8: Unterminated address regex sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #1, char 8: Unterminated address regex sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #1, char 25: Unterminated address regex sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #1, char 8: Unterminated address regex sed: -e expression #1, char 8: Unterminated address regex sed: -e expression #1, char 8: Unterminated address regex sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #1, char 25: Unterminated address regex sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #1, char 13: Unterminated address regex sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #2, char 13: Unterminated `s' command sed: -e expression #2, char 13: Unterminated `s' command make: *** could not duplicate stdout . Stop. What is wrong here? The README mentions possible problems due to bugs in 3.76.1, so I tried to avoid using it. -- John **= Email 7 ==========================** Date: Sun, 10 Mar 2002 14:18:52 +0000 From: John Poltorak Subject: Gettext v0.11 Has anyone built Gettext v0.11? It's available from here:- ftp://ftp.mirror.ac.uk/sites/ftp.gnu.org/pub/gnu/gettext/gettext-0.11.tar.gz It looks like the INTL.DLL which gcc uses is not compatible with the one Make v3.79.1 uses - it has functions missing. Can we have a new one based on Gettext v0.11? -- John **= Email 8 ==========================** Date: Sun, 10 Mar 2002 14:40:01 +0000 From: John Poltorak Subject: Re: Make problem On Sun, Mar 10, 2002 at 11:44:22AM +0100, Holger Veit wrote: > On Sat, Mar 09, 2002 at 09:04:34PM +0000, John Poltorak wrote: > > 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... > > And what if the appropriate file system structure is not present there? > You end up in complicated, and *thus necessarily* failing heuristics > to locate things like /etc/passwd, /etc/hosts, /etc/services > (are they in boot:\tcpip\etc or in boot:\mptn\etc or in %ETC% or > even elsewhere). And these prominent files are just the simple cases? > Where to obtain certain settings? IMV it is a big mistake not to treat ETC as a special case and allow for it existing out side ot UNIXROOT. I think the only way things will work properly with the current UNIXROOT design is if UNIXROOT=bootdrive and %ETC%=bootdrive\etc. If ETC has two locations, which is what will happen if UNIXROOT != bootdrive then people will be forced to maintain two copies of various config files, which is bad enough in itself, but the chances are that discrepancies will occur over time. > XFree86/OS2 (and even to some degree EMX itself) is the well-known example > that ordinary users cannot read docs that say "do first this, then that, > and finally this". So any system that offers flexibility and provides > complicated heuristics to identify messed up file and data structures > is doomed to fail miserably. So keep it simple: UNIXROOT or nothing. Sure, many users do not read docs, but sometimes docs are incorrect, sometimes there are so many docs, that it is difficult to see the wood for the trees. I always like it best when things work automagically without anything needing to be set by the user. Keeping it simple means having sensible defaults. I would also like it if most utilities such SED, GREP, AWK etc would work indepedently of UnixOS/2 which they wouldn't if %UNIXROOT% was a prerequisite. > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 9 ==========================** Date: Sun, 10 Mar 2002 14:51:30 +0000 From: John Poltorak Subject: Re: Make problem with Gettext 0.11 On Sun, Mar 10, 2002 at 12:56:41PM +0000, John Poltorak wrote: > > > According to README.OS2 in gettext-0.11:- > > > 2. Go to os2 and just run `make'. If you have all the required tools, > it should painlessly compile. > > Here is what I get when using Make 3.79.1:- > > sed: -e expression #2, char 13: Unterminated `s' command > make: *** could not duplicate stdout > . Stop. > > > What is wrong here? The README mentions possible problems due to bugs in > 3.76.1, so I tried to avoid using it. Now I have tried 3.76.1 I get:- make: *** No rule to make target `out/release/intl.a', needed by `all'. Stop. This is actually mentioned in the README:- Such messages are a bad joke. Ignore it, and re-run make. This is a long-standing bug in GNU make, alas. However when I re-run it I get:- make6: *** No rule to make target `../intl/gettext.h', needed by `out/release/intl/intl-compat.o'. Stop. and I never get past this if I keep re-running it any more. The same thing happens using Make 3.75. Maybe I should look at the masochist options... -- John **= Email 10 ==========================** Date: Sun, 10 Mar 2002 16:12:08 +0000 From: "Dave and Natalie" Subject: Re: Make problem On Sun, 10 Mar 2002 18:37:55 +0100, Andreas Buening wrote: >Holger Veit wrote: >> >> On Sat, Mar 09, 2002 at 09:24:20PM +0900, Jun Sawataishi wrote: > >[snip] > >> > 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. > >I think this would be a bad idea. If I boot from floppy >to restore my broken system the absolutely last thing >I want to see is > >[OS/2]>set endlibpath=e:\emx\dll;e:\usr\lib >[OS/2]>e: >[OS/2]>diff -u config.old config.sys >error: IX.SYS not installed >aborted >[OS/2]> > >It had better print a warning like you get one if you're >using emx 0.9c but the program was compiled with emx 0.9d. >Most of the tools (at least the low level ones) don't really >need that UNIXROOT stuff seriously, and if they need their own >config files or libraries then they mostly have an env. var. >(like AWKPATH) you can specify for that special case. >If latex or gcc or maybe emacs don't work when I boot from >floppy it's not that problem, but if joe or vi (or whatever >my textmode emergency editor is) refuse to work then >I have a _real_ problem. > >[snip] > >> 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). > >But I can install emx.dll at runtime and set endlibpath to >get some basic survival & rescue tools working. > >> > 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, > >Okay, then there will be some more bug reports, but this is no >principle problem. The number of such locations is finite. ;-) > > >> 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". > >We're still talking about open source code? If somebody wants >support for GNU_MY_OWN_FEATURE or UNIXROOTPATH then he is >free to implement it as long as it doesn't hurt other >systems. Personally, I think it should be possible to compile >all unixos2 packages for g:/test/foo. However, there will >be no support from the unixos2 group and no precompiled >binaries for g:/test/foo, so what? If I want to have a special >tool on a Unix system there is also no precompiled binary >(unless I'm root) but I can compile it for every directory >I have write access for. > Seems to me that EMX is still going to be required on most systems, 1: For old ports which haven't been recompiled for libemu. 2: For OS/2 programs that were built with gcc eg screensaver.exe So perhaps some common tools can still be linked against emx.dll instead of libemu, for example bc doesn't need much in the way of unixy support so why not just link it against EMX? This could allso be an users choice so if I want my vi linked against EMX I can replace the UnixOS2 version with an EMX version. Or install in /usr/local and have /usr/local/bin come first in %PATH%. Dave **= Email 11 ==========================** Date: Sun, 10 Mar 2002 16:13:26 +0000 From: "Dave and Natalie" Subject: Re: Make problem On Fri, 08 Mar 2002 23:49:10 +0100, Andreas Buening wrote: >To avoid this I propose to use an absolute path >_including_ a drive letter. But which one? If you use >e: or z: or whatever it's possible that this drive is >a CD ROM or zip drive ot whatever. An access to this drive >would be not only annoying but also slow. The idea is, >that every OS/2 user has a readable hard disk partition c:, >no matter whether it is HPFS or FAT or whatever. >(okay, with LVM you should be able to avoid c:) >If the file can't be found on c:/whatever then >$UNIXROOT/whatever should be tried. While I understand what your saying and C: has the most chance of existing the problem with C: is [E:\]dir c: Volume in drive C has no label. The Volume Serial Number is 534E:4A52. Directory of C:\ SYS0026: The specified disk or diskette cannot be accessed. This is with warp v4 fp 15 and win98 (fat32) on C:, a fairly common setup I think. I also tried a test case with bc-1.06 and got this Making install in bc make.exe[1]: Entering directory `/usr/src/bc-1.06/bc' make.exe[2]: Entering directory `/usr/src/bc-1.06/bc' e:/emx/bin/bash.exe ../mkinstalldirs c:/usr/bin mkdir c:/usr mkdir: cannot make directory `c:/usr': I/O error mkdir c:/usr/bin mkdir: cannot make directory `c:/usr/bin': I/O error make.exe[2]: *** [install-binPROGRAMS] Error 1 make.exe[2]: Leaving directory `/usr/src/bc-1.06/bc' make.exe[1]: *** [install-am] Error 2 make.exe[1]: Leaving directory `/usr/src/bc-1.06/bc' e:/emx/bin/make.exe: *** [install-recursive] Error 1 As a lot of programs only use --prefix= for make install, / is still a good choice though more complex programs will need more thought and hacking for $UNIXROOT. Hopefully when libemu is ready a lot of these problems will disappear. Dave ps it is also possible that C: is fat which could see failures due to long file name issues. **= Email 12 ==========================** Date: Sun, 10 Mar 2002 16:16:31 +0000 From: "Dave and Natalie" Subject: Re: Make problem On Sun, 10 Mar 2002 11:44:22 +0100, Holger Veit wrote: > So keep it simple: UNIXROOT or nothing. Sometimes nothing may be the best choice. Does bc need to know UNIXROOT? Dave **= Email 13 ==========================** Date: Sun, 10 Mar 2002 17:11:29 +0000 From: John Poltorak Subject: Re: Make problem On Sun, Mar 10, 2002 at 08:29:47AM -0800, James Cannon wrote: > Hi Holger, > --- Holger Veit wrote: > [HUGE SNIP] > >So keep it simple: > > UNIXROOT or nothing. > > > > Holger > I'll have to agree on keeping it simple. When it comes > to maintaining systems, one always asks, "Isn't there > a better way". Then you get to the point of being > backwards compatible with existing standards. The > right design considerations up front will provide long > lasting rewards. My take, parse the echo from set for > UNIXROOT, if that fails, provide an answer .... > "UNIXROOT not found, application can not proceed". > Give the user an opportunity to provide one ... "set > UNIXROOT variable?", if yes or no, provide name of > document that explains the UNIXROOT variable. I would suggest that providing an interactive option is making things more complicated. My preference would be for alternative locations for finding the required variables. I'd like to see UNIXOS2.RC outside of UNIXROOT as the file which holds all the necessary variables for the UnixOS/2 environment. This file could be in root of boot drive, in %INIT%, in %ETC% or located via %UNIXOS2RC% or any other common location. > ===== > Sincerely, > James Cannon > > Using OS/2 Warp in the beautiful Wine > Country of Northen California! -- John **= Email 14 ==========================** Date: Sun, 10 Mar 2002 17:21:01 +0000 From: "Lyn St George" Subject: Re: Make problem On Sun, 10 Mar 2002 14:40:01 +0000, John Poltorak wrote: >On Sun, Mar 10, 2002 at 11:44:22AM +0100, Holger Veit wrote: >> On Sat, Mar 09, 2002 at 09:04:34PM +0000, John Poltorak wrote: >> > 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... >> >> And what if the appropriate file system structure is not present there? >> You end up in complicated, and *thus necessarily* failing heuristics >> to locate things like /etc/passwd, /etc/hosts, /etc/services >> (are they in boot:\tcpip\etc or in boot:\mptn\etc or in %ETC% or >> even elsewhere). And these prominent files are just the simple cases? >> Where to obtain certain settings? > >IMV it is a big mistake not to treat ETC as a special case and allow for >it existing out side ot UNIXROOT. I think the only way things will work >properly with the current UNIXROOT design is if UNIXROOT=bootdrive and >%ETC%=bootdrive\etc. In fact most systems will have a couple more etc/ directories - one for SOMIR and possibly one for Lotus SS, though only one %ETC%. In my case %ETC% is on f:\ and works fine. This is also my UNIXROOT. My bootdrive has only enough room for its main purpose, as would most people's. I would have to vote for %ETC% being on UNIXROOT for simplicity - after all it's no trouble to change it to there by simply copying mptn\etc\* to it - and UNIXROOT *must* be settable by the user otherwise it simply won't work on many systems. >If ETC has two locations, which is what will happen if UNIXROOT != >bootdrive then people will be forced to maintain two copies of various >config files, which is bad enough in itself, but the chances are that >discrepancies will occur over time. > > >> XFree86/OS2 (and even to some degree EMX itself) is the well-known example >> that ordinary users cannot read docs that say "do first this, then that, >> and finally this". So any system that offers flexibility and provides >> complicated heuristics to identify messed up file and data structures >> is doomed to fail miserably. So keep it simple: UNIXROOT or nothing. > > >Sure, many users do not read docs, but sometimes docs are incorrect, >sometimes there are so many docs, that it is difficult to see the wood for >the trees. > >I always like it best when things work automagically without anything >needing to be set by the user. Keeping it simple means having sensible >defaults. I would also like it if most utilities such SED, GREP, AWK etc >would work indepedently of UnixOS/2 which they wouldn't if %UNIXROOT% was >a prerequisite. You would still be free to use those tools outside of UnixOS/2, but it would just mean that those particular instances were not part of the "official UnixOS/2" package. > >> Holger >> >> -- >> Please update your tables to my new e-mail address: >> holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) >> > >-- >John > > - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 15 ==========================** Date: Sun, 10 Mar 2002 18:37:35 +0100 From: Andreas Buening Subject: Re: Make problem with Gettext 0.11 John Poltorak wrote: > > According to README.OS2 in gettext-0.11:- > > 2. Go to os2 and just run `make'. If you have all the required tools, > it should painlessly compile. > > Here is what I get when using Make 3.79.1:- > > sed: -e expression #1, char 8: Unterminated address regex [snip] I see the problem. My main intention was to get make working 100% reliable when using /bin/sh. With cmd there might be some problems. However, I think I know how to solve this. > make: *** could not duplicate stdout > . Stop. That was a typo. I thought I had uploaded the fix but maybe not. > What is wrong here? The README mentions possible problems due to bugs in > 3.76.1, so I tried to avoid using it. Be careful with that Makefile. I ran "make -n" and somewhat after your error it tried to do the following: mkdir.exe -p out/release mkdir.exe -p emx/dll mkdir.exe -p emx/doc/gettext- mkdir.exe -p emx/include mkdir.exe -p emx/lib mkdir.exe -p emx/share/locale mkdir.exe -p emx/share/locale/ca/LC_MESSAGES ... There's no separate 'install' target so everything will be installed if you run "make", hardcoded paths are /usr/..., install path seems to be emx/ (?). However, it's currently not possible to compile this gettext version as an included (static) gettext in other packages like gawk. 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 16 ==========================** Date: Sun, 10 Mar 2002 18:37:55 +0100 From: Andreas Buening Subject: Re: Make problem Holger Veit wrote: > > On Sat, Mar 09, 2002 at 09:24:20PM +0900, Jun Sawataishi wrote: [snip] > > 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. I think this would be a bad idea. If I boot from floppy to restore my broken system the absolutely last thing I want to see is [OS/2]>set endlibpath=e:\emx\dll;e:\usr\lib [OS/2]>e: [OS/2]>diff -u config.old config.sys error: IX.SYS not installed aborted [OS/2]> It had better print a warning like you get one if you're using emx 0.9c but the program was compiled with emx 0.9d. Most of the tools (at least the low level ones) don't really need that UNIXROOT stuff seriously, and if they need their own config files or libraries then they mostly have an env. var. (like AWKPATH) you can specify for that special case. If latex or gcc or maybe emacs don't work when I boot from floppy it's not that problem, but if joe or vi (or whatever my textmode emergency editor is) refuse to work then I have a _real_ problem. [snip] > 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). But I can install emx.dll at runtime and set endlibpath to get some basic survival & rescue tools working. > > 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, Okay, then there will be some more bug reports, but this is no principle problem. The number of such locations is finite. ;-) > 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". We're still talking about open source code? If somebody wants support for GNU_MY_OWN_FEATURE or UNIXROOTPATH then he is free to implement it as long as it doesn't hurt other systems. Personally, I think it should be possible to compile all unixos2 packages for g:/test/foo. However, there will be no support from the unixos2 group and no precompiled binaries for g:/test/foo, so what? If I want to have a special tool on a Unix system there is also no precompiled binary (unless I'm root) but I can compile it for every directory I have write access for. 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 17 ==========================** Date: Sun, 10 Mar 2002 19:24:37 +0100 (CET) From: Stefan Neis Subject: Re: Make problem On Sun, 10 Mar 2002, Andreas Buening wrote: > Most of the tools (at least the low level ones) don't really > need that UNIXROOT stuff seriously, and if they need their own > config files or libraries then they mostly have an env. var. > (like AWKPATH) you can specify for that special case. More and more of the tools - even of the low level ones - start to be requirinf that UNIXROOT variable - even if only for finding it's message catalogues for localization. You've interest to "fix" your boot disks if you intend to use any unix stuff from it... > floppy it's not that problem, but if joe or vi (or whatever > my textmode emergency editor is) refuse to work then > I have a _real_ problem. Use 'tedit' or put ix.sys on your floppy - two easy working solutions should be enough. > Okay, then there will be some more bug reports, but this is no > principle problem. The number of such locations is finite. ;-) Not really. Every new version of some software will/may add new problems, so we'll never get to the simple 'configure/make/make install' solution that all this stuff is aiming at.. Regards, Stefan **= Email 18 ==========================** Date: Sun, 10 Mar 2002 19:27:19 +0100 (CET) From: Stefan Neis Subject: Re: Make problem On Sun, 10 Mar 2002, John Poltorak wrote: > IMV it is a big mistake not to treat ETC as a special case and allow for > it existing out side ot UNIXROOT. I think the only way things will work > properly with the current UNIXROOT design is if UNIXROOT=bootdrive and > %ETC%=bootdrive\etc. I don't think so. Over here it's separated and working nicely. I still have to find an example for a file from /etc or %ETC% that's really shared between OS/2 and unix-like stuff... > If ETC has two locations, which is what will happen if UNIXROOT != > bootdrive then people will be forced to maintain two copies of various > config files, Which ones? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 19 ==========================** Date: Sun, 10 Mar 2002 19:33:38 +0000 From: John Poltorak Subject: Re: Make problem On Sun, Mar 10, 2002 at 07:27:19PM +0100, Stefan Neis wrote: > On Sun, 10 Mar 2002, John Poltorak wrote: > > > IMV it is a big mistake not to treat ETC as a special case and allow for > > it existing out side ot UNIXROOT. I think the only way things will work > > properly with the current UNIXROOT design is if UNIXROOT=bootdrive and > > %ETC%=bootdrive\etc. > > I don't think so. Over here it's separated and working nicely. I still > have to find an example for a file from /etc or %ETC% that's really > shared between OS/2 and unix-like stuff... Many OS/2 ports use %ETC% as a location for config files, whereas they use /etc on Unix. Once LIBEMX is available, then the correct location for SYSCONFDIR will be /etc because LIBEMU will be able to identify it correctly, so %ETC% will need to move to %UNIXROOT%\etc. I find this infexible because I will always want %ETC% on my boot drive so that a system can be up and running quickly after a crash and CHKDSK. I only CHKDSK the boot drive in CONFIG.SYS, the rest are processed by STARTUP.CMD. > > If ETC has two locations, which is what will happen if UNIXROOT != > > bootdrive then people will be forced to maintain two copies of various > > config files, > > Which ones? RESOLV PASSWD GROUP TERMCAP SERVICES NAMED.CONF NETRC WGETRC .NEWSRC In principle it just a mess having ETC being split over two locations and its just asking for something to go wrong sooner or later. > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 20 ==========================** Date: Sun, 10 Mar 2002 19:41:45 +0000 From: John Poltorak Subject: Re: Make problem On Mon, Mar 11, 2002 at 02:34:27AM +0900, Jun Sawataishi wrote: > On UNIXROOT env. var, Holger wrote: > John P.>And what if the appropriate file system structure is not present there? > >You end up in complicated, and *thus necessarily* failing heuristics > >to locate things like /etc/passwd, /etc/hosts, /etc/services > >(are they in boot:\tcpip\etc or in boot:\mptn\etc or in %ETC% or > >even elsewhere). And these prominent files are just the simple cases? > >Where to obtain certain settings? > > Holger>XFree86/OS2 (and even to some degree EMX itself) is the well-known example > >that ordinary users cannot read docs that say "do first this, then that, > >and finally this". So any system that offers flexibility and provides > >complicated heuristics to identify messed up file and data structures > >is doomed to fail miserably. So keep it simple: UNIXROOT or nothing. > > After consideration, I completely agreed with Holger. > From now on, I rewrite sources: > When UNIXROOT env. var. is not set or empty, programs will > say "set UNIXROOT env. var." and terminate. I don't think you should do that. If anything is going to check for the presence of %UNIXROOT% it should be the LIBEMU runtime environment. That would be the correct place to have any environment checking. It doesn't make sense for a single program to have such code. > > # OS/2 is not a question, it's a solution. > # SAWATAISHI Jun > # http://www2s.biglobe.ne.jp/~vtgf3mpr/ > -- John **= Email 21 ==========================** Date: Sun, 10 Mar 2002 19:48:06 +0000 From: John Poltorak Subject: Re: Make problem On Sun, Mar 10, 2002 at 07:24:37PM +0100, Stefan Neis wrote: > On Sun, 10 Mar 2002, Andreas Buening wrote: > > > Most of the tools (at least the low level ones) don't really > > need that UNIXROOT stuff seriously, and if they need their own > > config files or libraries then they mostly have an env. var. > > (like AWKPATH) you can specify for that special case. > > More and more of the tools - even of the low level ones - start > to be requirinf that UNIXROOT variable - even if only for finding > it's message catalogues for localization. IMV the only program that should be concerned about %UNIXROOT% should be the LIBEMU run time. > > floppy it's not that problem, but if joe or vi (or whatever > > my textmode emergency editor is) refuse to work then > > I have a _real_ problem. > > Use 'tedit' or put ix.sys on your floppy - two easy working solutions > should be enough. I would expect IX.SYS to be fairly large... > Regards, > Stefan > -- John **= Email 22 ==========================** Date: Sun, 10 Mar 2002 19:54:18 +0000 From: John Poltorak Subject: Re: Make problem with Gettext 0.11 On Sun, Mar 10, 2002 at 06:37:35PM +0100, Andreas Buening wrote: > There's no separate 'install' target so everything will > be installed if you run "make", hardcoded paths are > /usr/..., install path seems to be emx/ (?). > However, it's currently not possible to compile this > gettext version as an included (static) gettext in other > packages like gawk. I was hoping that this app would provide me with a new INTL.DLL which was compatible both with Make 3.79.1 and gcc 3.0.3. I don't know which version should be used t the moment. > > 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 23 ==========================** Date: Sun, 10 Mar 2002 22:47:49 +0100 From: Andreas Buening Subject: Re: Make problem Stefan Neis wrote: > > On Sun, 10 Mar 2002, Andreas Buening wrote: > > > Most of the tools (at least the low level ones) don't really > > need that UNIXROOT stuff seriously, and if they need their own > > config files or libraries then they mostly have an env. var. > > (like AWKPATH) you can specify for that special case. > > More and more of the tools - even of the low level ones - start > to be requirinf that UNIXROOT variable - even if only for finding > it's message catalogues for localization. You've interest to "fix" > your boot disks if you intend to use any unix stuff from it... You don't really need support for spanish or chinese error or help messages if you're trying to fix your broken system. None of the basic GNU tools (shell/file/text utils, grep, sed, diff) requires any hardcoded path for normal usage. > > floppy it's not that problem, but if joe or vi (or whatever > > my textmode emergency editor is) refuse to work then > > I have a _real_ problem. > > Use 'tedit' or put ix.sys on your floppy - two easy working solutions > should be enough. Okay, then let's be a boot CD and I have no CD burner. tedit? You can use it for changing a single line in config.sys, but that's all. But how can you know that nobody will ever need a more sophisticated tool to fix his system? diff, a hex editor, GNU find to locate the last backup of the INI files? GNU info or a textmode viewer (lynx) for some documentation files? None of them would work, perhaps not even a single program that has been linked with LIBEMU. I'm not talking about configurering and compiling Gnome from a boot disk. I'm talking about simple file processing tools and simple text mode editors. If I need a emx-compiled diff for comparing the current versus the last backup directory or the old config.sys versus the current one then I don't need a LIBEMU compiled diff at all. > > Okay, then there will be some more bug reports, but this is no > > principle problem. The number of such locations is finite. ;-) > > Not really. Every new version of some software will/may add new > problems, so we'll never get to the simple 'configure/make/make install' > solution that all this stuff is aiming at.. I don't think that the number of locations where hardcoded paths are used are that many and will change that often. The software would have to be really illdesigned for that. One thing is obvious: in principle we need a maintainer for every package that should be incorporated into unixos2 even if it's only for compiling the latest versions because every time there can ba an incompatible change of any type. 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 24 ==========================** Date: Sun, 10 Mar 2002 23:09:38 +0100 (CET) From: Stefan Neis Subject: Re: Make problem On Sun, 10 Mar 2002, John Poltorak wrote: > > > bootdrive then people will be forced to maintain two copies of various > > > config files, > > > > Which ones? > > RESOLV > PASSWD > GROUP > TERMCAP > SERVICES > NAMED.CONF > NETRC > WGETRC > .NEWSRC I still don't understand... :-( Which of those would need to be in %ETC%, once the unix-ports are UnixOS/2 compliant? And if there is a short period over which those files would actually be needed in to locations (old one by ports that are not yet up-to-date and new location for the new stuff), why would that be a problem? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 25 ==========================** Date: Sun, 10 Mar 2002 23:15:41 +0100 (CET) From: Stefan Neis Subject: Re: Make problem On Sun, 10 Mar 2002, John Poltorak wrote: > > Use 'tedit' or put ix.sys on your floppy - two easy working solutions > > should be enough. > > I would expect IX.SYS to be fairly large... I don't. Look at how large xf86sup.sys is ... But that's just guessing, Holger might be able to tell how large it might get in the end. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 26 ==========================** Date: Sun, 10 Mar 2002 23:25:27 +0100 (CET) From: Stefan Neis Subject: Re: Make problem On Sun, 10 Mar 2002, Andreas Buening wrote: > > Use 'tedit' or put ix.sys on your floppy - two easy working solutions > > should be enough. > > Okay, then let's be a boot CD and I have no CD burner. Why does everybody think ix.sys is going to be that large? Why shouldn't it fit on a floppy? > tedit? You can use it for changing a single line in > config.sys, but that's all. That's what I was about to say about vi. ;-) (Give me emacs ....) > But how can you know that > nobody will ever need a more sophisticated tool to fix his > system? diff, a hex editor, GNU find to locate the last > backup of the INI files? GNU info or a textmode viewer > (lynx) for some documentation files? None of them would > work, perhaps not even a single program that has been linked > with LIBEMU. I'm not talking about configurering and compiling > Gnome from a boot disk. I'm talking about simple file processing > tools and simple text mode editors. If I need a emx-compiled > diff for comparing the current versus the last backup directory > or the old config.sys versus the current one then I don't need > a LIBEMU compiled diff at all. Try using Alt-F1 F2 which will boot with a working config.sys that's of course including ix.sys. I haven't been using boot floppies for years (at first because I wasn't able to boot my system from disks within my LS-120 drive, after I got this to work I noticed that I don't need it anyway. ;-) ) Sorry, I just don't see the problem with one driver more or less to be loaded by config.sys .... > I don't think that the number of locations where hardcoded > paths are used are that many and will change that often. > The software would have to be really illdesigned for that. Wishful thinking ... > One thing is obvious: in principle we need a maintainer > for every package that should be incorporated into unixos2 > even if it's only for compiling the latest versions because > every time there can ba an incompatible change of any type. One thing is obvious: There's no manpower for that kind of porting. That's why Holger is aiming for something as BSD-like as possible so every new version compiling on BSD compiles on OS/2 automatically. (And no, I don't really like that approach either, but I don't believe we can do much better...). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'.