Date: Thu, 10 Apr 2003 02:40:49 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 130 ************************************************** Wednesday 09 April 2003 Number 130 ************************************************** Subjects for today 1 Re: GOCR : Henry Sobotka 2 Re: GOCR : John Poltorak 3 Re: M4 build problem : John Poltorak 4 Re: UX2BS review : John Poltorak 5 Re: UX2BS review : John Poltorak 6 Re: M4 build problem : sma at sohnen-moe.com 7 Re: M4 build problem : Sohnen-Moe Associates, Inc" 8 Re: M4 build problem : sma at sohnen-moe.com 9 Re: UX2BS review : sma at sohnen-moe.com 10 Is there a ux2 "ln"? : sma at sohnen-moe.com 11 Re: M4 build problem : John Poltorak 12 Re: GOCR : Andreas Buening 13 Re: UX2BS review : John Poltorak 14 Re: M4 build problem : John Poltorak 15 Re: Is there a ux2 "ln"? : sma at sohnen-moe.com 16 Re: Is there a ux2 "ln"? : Henry Sobotka 17 Re: UX2BS review : Sebastian (Ginko)" 18 Re: M4 build problem : Andreas Buening 19 Re: UX2BS review : Andreas Buening **= Email 1 ==========================** Date: Thu, 10 Apr 2003 00:24:43 -0400 From: Henry Sobotka Subject: Re: GOCR The easiest way to get it to use the .exe suffix is by adding -Zexe to the linkage flags. But if the build process has ac_executable_suffix, the focus should be on nailing the cause of the failure. Possibly a missing $(BIN_SUFFIX) or some such variable appended to the target(s). Modifying Makefile.in's is easy. All the Makefile.in->Makefile process does is substitute anything in form %foo% for the value of foo as determined by configure; if undefined, it normally outputs %foo%. You don't want to modify configure, because it's generated from configure.in and the process involves macro expansion within a shell script, so it's not that simple. The first thing I would suggest is tracking down where the value assigned to ac_executable_suffix dies, i.e. does it get passed on to the makefiles? If not, it's a configure.in problem. If so, it's a makefile bug. h~ _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Thu, 10 Apr 2003 09:29:41 +0100 From: John Poltorak Subject: Re: GOCR On Wed, Apr 09, 2003 at 10:16:39PM -0700, sma at sohnen-moe.com wrote: > I tried that by adding "-Zexe" to the LDFLAGS section in build.table. > It apparently does not propogate the additional flag(s) far enough to be > useful. > The solution to the two problems is to use pre- and post-process > scripts. The pre-process deletes the make.bat; the post-process calls > emxbind to convert the aout to exe. These pre- and post-process scripts are essentially kludges to make things work when the correct solution cannot be arrived at for some reason. It sounds as though we ought to be able to obviate a need for a gocr post-process script in this case... > >Modifying Makefile.in's is easy. All the Makefile.in->Makefile process > >does is substitute anything in form %foo% for the value of foo as > >determined by configure; if undefined, it normally outputs %foo%. > > > Well, the Makefile.in is half the problem. It assigns PROGRAM = gocr, > not PROGRAM = gocr.exe. There is no at exeext at (or equivalent) to finesse. > And configure itself does not make the exe variable available even if it > were possible in Makefile.in. :-( Maybe amending Makefile.in is the wrong place to make changes. How about changing Makefile.am and recreating Makefile.in. I'm not exactly sure about how this processing is done... -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Thu, 10 Apr 2003 09:39:19 +0100 From: John Poltorak Subject: Re: M4 build problem On Wed, Apr 09, 2003 at 05:28:58PM -0700, sma at sohnen-moe.com wrote: > Hello, > The build pre-process modifications for m4 seem incomplete. I decided > to rebuld it for some reason and it did not proceed smoothly. > The particular problem is the definition of "ar" in lib/Makefile.in: > it is AR = ar. Even though the top level make is given "AR=emxomfar", > this is not relevant in lib since AR is hardcoded to "ar". I have m4 building correctly now. The only problem left is that INFODIR cannot be defined when running configure. A few things specific to m4 which seem to be required are that regex needs to be built first, m4 should be in p2_exc.lst, and autoconf v2.50 is used to create the configure script for m4 - that's done via a short pre-process script. Can you post any errors from the m4 build log? -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 4 ==========================** Date: Thu, 10 Apr 2003 09:57:47 +0100 From: John Poltorak Subject: Re: UX2BS review On Wed, Apr 09, 2003 at 11:06:47PM -0700, sma at sohnen-moe.com wrote: > > > >Are there any major apps which won't build? > > > Oh, yeah... make 3.79.1. The build stops with this really long error: Yes, the way Make builds is really ugly, but does actually build... > > [... a lot of stuff not shown ...] > Making install in glob > make[1]: Entering directory `/unixos2/workdir/make-3.79.1/glob' cd .. && > automake --foreign --include-deps glob/Makefile > cd .. \ > && CONFIG_FILES=glob/Makefile CONFIG_HEADERS= /bin/sh ./config.status > config.status: creating glob/Makefile > make[1]: Leaving directory `/unixos2/workdir/make-3.79.1/glob' make[1]: > Entering directory `/unixos2/workdir/make-3.79.1/glob' gcc > -DHAVE_CONFIG_H -I. -I. -I.. -c glob.c make: *** > [install-recursive] Error 1 > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -c fnmatch.c > rm -f libglob.a > ar cru libglob.a glob.o fnmatch.o > ..Compiler version is: 2.8.1 > Wed Apr 9 23:05:13 MST 2003 > > > ===> This is the end of build.sh! It looks like make spawned and the > child dragged its ass. It continues with... > Entering directory `/unixos2/workdir/make-3.79.1/i18n' make[2]: Nothing > to be done for `all'. > make[2]: Leaving directory `/unixos2/workdir/make-3.79.1/i18n' make[1]: > *** [all-recursive] Error 1 > make[1]: Leaving directory `/unixos2/workdir/make-3.79.1' > make: *** [all-recursive-am] Error 2 > > > An unhappy end. Then by changing to the make-3.79.1 directory and > issuing "make install", it finishes. Grr. Argh. I would like to get this cleaned up, but don't really have a clue about what is missing. -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 5 ==========================** Date: Thu, 10 Apr 2003 10:01:59 +0100 From: John Poltorak Subject: Re: UX2BS review On Wed, Apr 09, 2003 at 11:56:42PM +0100, Bart van Leeuwen wrote: > >If they were added, some thought would need to be made about how they were > >added. I think there is quite a bit of overlap with Posix/2 and/or EMX, > >although I doubt whether any maintenance will be done, but I would expect > >Posix/2 to be brought up to date at some point. > > as said as this statement is. I think we should merge the missing parts of > the OS/2 headers. this is rather safe to do since its not likely that they > will change anytime soon. > but where to do that ?? how to coordinate that ?? I've did it localu by > editing the heardes and add a define and create a .a for some functions. > > the way to do it is not in question.. how to coordinate is... it needs to > be tested etc. Can you clarify, in your view, the extent of any merging required? I'm not familiar with the OS/2 Toolkit. > Bart -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 6 ==========================** Date: Thu, 10 Apr 2003 11:33:21 -0700 From: sma at sohnen-moe.com Subject: Re: M4 build problem > >Can you post any errors from the m4 build log? > This is the actual attempt to link m4.exe: gcc -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zcrtdll -Zmt -s -Zlinker /exepack:2 -Zlinker /pmtype:vio -o m4.exe m4.obj builtin.obj debug.obj eval.obj format.obj freeze.obj input.obj macro.obj output.obj path.obj symtab.obj ../lib/libm4.a LINK386 : fatal error L1104: ..\lib\libm4.a : not valid library make[1]: *** [m4] Error 1 make[1]: Leaving directory `/unixos2/workdir/m4-1.4/src' make: *** [install] Error 1 Here is the library build command that resulted in a bogus libm4.a: making install in lib make[1]: Entering directory `/unixos2/workdir/m4-1.4/lib' gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ getopt.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ getopt1.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ error.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ obstack.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ xmalloc.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ xstrdup.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ regex.c rm -f libm4.a ar cru libm4.a getopt.obj getopt1.obj error.obj obstack.obj xmalloc.obj xstrdup.obj regex.obj Note the "ar" instead of "emxomfar". Here is an excerpt from lib/Makefile.in that created the makefile: AR = ar CC = at CC at CFLAGS = at CFLAGS at AR is hard-coded. It is difficult to work around this one without creating a post-autoconf patch. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 7 ==========================** Date: Thu, 10 Apr 2003 12:35:14 -0700 (MST) From: "Sohnen-Moe Associates, Inc" Subject: Re: M4 build problem -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 10 Apr 2003 20:22:01 +0100, John Poltorak wrote: > >Can you just check to see if an m4.exe actually did get built? > No, it does not. >I suspect you have an out of date build.sh and his failure is a result of >'make install' rather than 'make'. > build.sh is based on the version I acquired a couple of days ago. I have added a few additional error checks, but nothing that would effect make. I will, however, use the untouched version as a sanity check. The failure definitely occurs during "make", not "make install". If I manually modify lib/Makefile.in to have AR = emxomfar before starting build.cmd, the build proceeds correctly from start to finish. James M Moe Sohnen-Moe Associates, Inc. http://www.sohnen-moe.com -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0 OS/2 for non-commercial use Comment: PGP 5.0 for OS/2 Charset: cp850 wj8DBQE+lcdy5z5shEq8TYMRAgZNAJ0QGjZ3p/sEN0m6n/WslXmgH4gOHQCgrf3f QknfI9BXf15xVK0OA4IVsko= =eLiH -----END PGP SIGNATURE----- _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 8 ==========================** Date: Thu, 10 Apr 2003 15:35:22 -0700 From: sma at sohnen-moe.com Subject: Re: M4 build problem > build.sh is based on the version I acquired a couple of days ago. I >have added a few additional error checks, but nothing that would effect >make. I will, however, use the untouched version as a sanity check. > Dang! I was so wrong. It was the build.sh I "improved." The final "make install" was not getting the MAKEPARM data. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 9 ==========================** Date: Thu, 10 Apr 2003 16:20:13 -0700 From: sma at sohnen-moe.com Subject: Re: UX2BS review >If it's the same problem as for texinfo 4.5 then there is >a AC_CHECK_LIB line in configure.in that is not quoted >accordingly. > (re: gnupg v1.3.1 build) I went through configure.ac (there is no configure.in) and quoted every AC_CHECK_LIB parameter. The same error occurred only on a different line. Maybe other paramters need quoting? (shudder) _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 10 ==========================** Date: Thu, 10 Apr 2003 16:21:03 -0700 From: sma at sohnen-moe.com Subject: Is there a ux2 "ln"? Hello, Is there a special ln.exe for ux2? Having one that operates like "cp -p" would be most excellent. I keep running into configure scripts that do not use ${LN} in place of ln. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 11 ==========================** Date: Thu, 10 Apr 2003 20:22:01 +0100 From: John Poltorak Subject: Re: M4 build problem On Thu, Apr 10, 2003 at 11:33:21AM -0700, sma at sohnen-moe.com wrote: > > > >Can you post any errors from the m4 build log? > > > This is the actual attempt to link m4.exe: > gcc -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zcrtdll -Zmt -s -Zlinker > /exepack:2 -Zlinker /pmtype:vio -o m4.exe m4.obj builtin.obj debug.obj > eval.obj format.obj freeze.obj input.obj macro.obj output.obj path.obj > symtab.obj ../lib/libm4.a > > LINK386 : fatal error L1104: ..\lib\libm4.a : not valid library > make[1]: *** [m4] Error 1 > make[1]: Leaving directory `/unixos2/workdir/m4-1.4/src' > make: *** [install] Error 1 > > > Here is the library build command that resulted in a bogus libm4.a: > making install in lib > make[1]: Entering directory `/unixos2/workdir/m4-1.4/lib' > gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ > getopt.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt > -D__ST_MT_ERRNO__ getopt1.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 > -s -Zmt -D__ST_MT_ERRNO__ error.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf > -O2 -s -Zmt -D__ST_MT_ERRNO__ obstack.c gcc -c -DHAVE_CONFIG_H -I.. -I. > -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ xmalloc.c gcc -c -DHAVE_CONFIG_H > -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ xstrdup.c gcc -c > -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ regex.c rm > -f libm4.a > ar cru libm4.a getopt.obj getopt1.obj error.obj obstack.obj xmalloc.obj > xstrdup.obj regex.obj > > Note the "ar" instead of "emxomfar". This is what I have:- making install in lib make[1]: Entering directory `U:/unixos2/workdir/m4-1.4/lib' gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ getopt.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ getopt1.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ error.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ obstack.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ xmalloc.c gcc -c -DHAVE_CONFIG_H -I.. -I. -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ xstrdup.c rm -f libm4.a emxomfar cru libm4.a getopt.obj getopt1.obj error.obj obstack.obj xmalloc.obj xstrdup.obj echo libm4.a libm4.a > Here is an excerpt from lib/Makefile.in that created the makefile: AR > = ar > CC = at CC at > CFLAGS = at CFLAGS at I have the same. > AR is hard-coded. It is difficult to work around this one without > creating a post-autoconf patch. Can you just check to see if an m4.exe actually did get built? I suspect you have an out of date build.sh and his failure is a result of 'make install' rather than 'make'. -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 12 ==========================** Date: Thu, 10 Apr 2003 20:35:11 +0200 From: Andreas Buening Subject: Re: GOCR sma at sohnen-moe.com wrote: [snip] > >But if the build process has ac_executable_suffix, the focus should be > >on nailing the cause of the failure. Possibly a missing $(BIN_SUFFIX) > >or some such variable appended to the target(s). > > > I have a hard time plowing through configure scripts so I missed how > it was done when I first reported the results. ac_executable_suffix is > not used anywhere. The script uses a test developed for Cygwin that > results with .exe as the suffix for running configure tests but does not > carry that to Makefile creation. Do you mean ac_executable_extensions? [snip] > Well, the Makefile.in is half the problem. It assigns PROGRAM = gocr, > not PROGRAM = gocr.exe. There is no at exeext at (or equivalent) to finesse. > And configure itself does not make the exe variable available even if it > were possible in Makefile.in. :-( PROGRAM = gocr$(EXEEXT) should do the job in Makefile.am (there might be also other occurrences of "gocr"). Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 13 ==========================** Date: Thu, 10 Apr 2003 20:46:52 +0100 From: John Poltorak Subject: Re: UX2BS review On Wed, Apr 09, 2003 at 11:01:24PM -0700, sma at sohnen-moe.com wrote: > > >Are there any major apps which won't build? > > > I have tried gnupg (GNU Privacy Guard) v1.3.1 with no success: I guess that is a typo. The latest I could find was v1.2.1... > checking for gethostbyname... no > .\CONFIGURE.[5112]: syntax error: `done' unexpected > ..configure failed. > > It's that "done" problem again. Has anyone figured out what is > happening with that? This appears to be a problem with Autoconf. If you run the supplied configure script it works fine. To omit running autoconf you need to create a zero length file called gnupg in scripts\pre-conf. The build doesn't actually work. It fails with a missing windows.h... BTW when I ran it initially without any changes, I got:- checking for _ prefix in compiled symbols... no checking for gethostbyname... yes ./configure[4962]: syntax error: `done' unexpected I don't see why it should be different to your result, especially this difference:- .\CONFIGURE.[5112]: syntax error: `done' unexpected ./configure[4962]: syntax error: `done' unexpected -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 14 ==========================** Date: Thu, 10 Apr 2003 20:53:59 +0100 From: John Poltorak Subject: Re: M4 build problem On Thu, Apr 10, 2003 at 12:35:14PM -0700, Sohnen-Moe Associates, Inc wrote: > build.sh is based on the version I acquired a couple of days ago. I have > added a few additional error checks, but nothing that would effect make. I > will, however, use the untouched version as a sanity check. The other things which may have a bearing on the result may depend on building regex, including m4 in p2_exc.lst, and having scripts\pre-process\m4 which forces the use of autoconf v2.50. There is also a patch for m4. > James M Moe > Sohnen-Moe Associates, Inc. > http://www.sohnen-moe.com -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 15 ==========================** Date: Thu, 10 Apr 2003 22:15:31 -0700 From: sma at sohnen-moe.com Subject: Re: Is there a ux2 "ln"? >> I keep running into configure scripts that do not use ${LN} in place >> of ln. > >There's an ln.cmd (from Holger?): > I considered something like that. It is not a perfect solution since CMD files sometimes have to be "called": call ln -s file.1 file.2 _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 16 ==========================** Date: Thu, 10 Apr 2003 22:35:42 -0400 From: Henry Sobotka Subject: Re: Is there a ux2 "ln"? sma at sohnen-moe.com wrote: > > Is there a special ln.exe for ux2? Having one that operates like "cp > -p" would be most excellent. > I keep running into configure scripts that do not use ${LN} in place > of ln. There's an ln.cmd (from Holger?): /* Poor man's ln command */ ' at echo off' parse arg src dest if src = '-s' then parse arg dummy src dest 'copy 'translate(src,'\','/') translate(dest,'\','/')' 2>&1 >nul' exit 0 h~ _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 17 ==========================** Date: Thu, 10 Apr 2003 22:37:49 +0200 From: "Sebastian (Ginko)" Subject: Re: UX2BS review Guten Tag John Poltorak, am Donnerstag, 10. April 2003 um 21:46 schrieben Sie: JP> On Wed, Apr 09, 2003 at 11:01:24PM -0700, sma at sohnen-moe.com wrote: >> I have tried gnupg (GNU Privacy Guard) v1.3.1 with no success: JP> I guess that is a typo. The latest I could find was v1.2.1... It don't think it's a typo; see here: http://ftp.gnupg.org/gcrypt/alpha/gnupg/ JP> I don't see why it should be different to your result, especially this JP> difference:- JP> .\CONFIGURE.[5112]: syntax error: `done' unexpected JP> ./configure[4962]: syntax error: `done' unexpected Also, because of other version of gnupg used. Sebastian _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 18 ==========================** Date: Thu, 10 Apr 2003 22:43:05 +0200 From: Andreas Buening Subject: Re: M4 build problem sma at sohnen-moe.com wrote: [snip] > Here is an excerpt from lib/Makefile.in that created the makefile: AR > = ar > CC = at CC at > CFLAGS = at CFLAGS at > > AR is hard-coded. It is difficult to work around this one without > creating a post-autoconf patch. You can use "make AR=emxomfar". Variables on the make command line overwrite those from the Makefiles. Or you can set AR = at AR at in your Makefile.in. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 19 ==========================** Date: Thu, 10 Apr 2003 22:43:18 +0200 From: Andreas Buening Subject: Re: UX2BS review John Poltorak wrote: > > On Wed, Apr 09, 2003 at 11:01:24PM -0700, sma at sohnen-moe.com wrote: [snip] > > checking for gethostbyname... no > > .\CONFIGURE.[5112]: syntax error: `done' unexpected > > ..configure failed. > > > > It's that "done" problem again. Has anyone figured out what is > > happening with that? > > This appears to be a problem with Autoconf. If you run the supplied > configure script it works fine. To omit running autoconf you need to > create a zero length file called gnupg in scripts\pre-conf. If it's the same problem as for texinfo 4.5 then there is a AC_CHECK_LIB line in configure.in that is not quoted accordingly. [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 Mordor where the Shadows lie. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs