From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 23 Jun 2002 04:28:25 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 251 ************************************************** Saturday 22 June 2002 Number 251 ************************************************** Subjects for today 1 Re: Gettext v0.11.2 : Andreas Buening 2 Re: Gettext v0.11.2 : John Poltorak 3 Re: Gettext v0.11.2 : Dave and Natalie" 4 Re: New Autoconf and Automake for OS/2 : Jeff Robinson 5 Fetchmail 5.9.13 : John Poltorak 6 Re: Re: Makedef.pl : John Poltorak 7 Re: Re: Makedef.pl : Henry Sobotka 8 OpenSSH Package : Adrian Gschwend" 9 Re: Gettext v0.11.2 : Andreas Buening 10 Re: Gettext v0.11.2 : Dave and Natalie" 11 New Autoconf and Automake for OS/2 : John Poltorak 12 Re: Gettext v0.11.2 : Dave and Natalie" 13 Re: packages in unixos2-current:SCRIPT function ... : Thomas Hoffmann 14 Re: Gettext v0.11.2 : Thomas Hoffmann 15 Re: packages in unixos2-current:SCRIPT function ... : John Poltorak 16 Shells honoring "extproc" : Thomas Hoffmann 17 Re: packages in unixos2-current:SCRIPT function ... : Adrian Gschwend" 18 Re: Re: Makedef.pl : Stefan Neis 19 Re: Re: Makedef.pl : John Poltorak 20 Re: Re: Makedef.pl : John Poltorak 21 UnixOS/2 environment : Lyn St George" 22 Automake patches : John Poltorak 23 Re: UnixOS/2 environment : John Poltorak 24 Re: Re: Makedef.pl : csaba.raduly at sophos.com 25 Re: Re: Makedef.pl : John Poltorak 26 Re: Re: Makedef.pl : Stefan Neis 27 Re: New Autoconf and Automake for OS/2 : Andreas Buening 28 Re: packages in unixos2-current:SCRIPT function ... : Andreas Buening 29 Re: Automake patches : Andreas Buening **= Email 1 ==========================** Date: Sun, 23 Jun 2002 01:16:14 +0200 From: Andreas Buening Subject: Re: Gettext v0.11.2 John Poltorak wrote: > > On Sat, Jun 22, 2002 at 06:46:27PM +0200, Andreas Buening wrote: > > John Poltorak wrote: > > > > [gettext] > > > > > BTW where did you get iconv.a ? > > > > > > It doesn't say this is required, but I seem to need it. > > > > You need that small iconv library for OS/2 (let's call > > it iconv/2) but don't ask me where to find it. > > I think we spent weeks going round this subject some time ago. > Does this contain what is required? :- > > http://195.131.97.220:9000/zap/os2/iconv%2d0.1.0.zip > > It contains iconv.{c,h} and makefile. Yes. But I remember that the Makefile didn't work correctly or something was broken. Btw. according to some comments in the GNU iconv package it is very unlikely that they will ever be willing to implement all OS/2 codepages and codepage names. Therefore you can forget this package for the UnixOS/2 base distribution. 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, 23 Jun 2002 09:25:00 +0100 From: John Poltorak Subject: Re: Gettext v0.11.2 On Sat, Jun 22, 2002 at 05:06:26PM -0800, Dave and Natalie wrote: > On Sat, 22 Jun 2002 20:53:26 +0100, John Poltorak wrote: > > >> Dave > >> ps now DLing libiconv-1.8 to try > > > > > >I just grabbed it, and it does appear to support OS/2, but it didn't build > >for me because I don't have a libcharset.h. > > libiconv-1.8 has a directory called libcharset. I ran configure --prefix=/usr, make, make install in this directory > and now have /usr/lib/charset.a /usr/lib/charset.dll and /usr/include/libcharset.h and a few other related files. Thanks, I gave this a try and did find a libcharset.h which was a copy of libcharset.h.in but make fell over here:- gcc -I. -I. -I.. -I./.. -g -O2 -DHAVE_CONFIG_H -DLIBDIR=\"/usrt/lib\" -c ./localcharset.c -DDLL_EXP ORT -DPIC -o .libs/localcharset.lo gcc -I. -I. -I.. -I./.. -g -O2 -DHAVE_CONFIG_H -DLIBDIR=\"/usrt/lib\" -c ./localcharset.c -o localcharset.o >/dev/null 2>&1 mv -f .libs/localcharset.lo localcharset.lo /bin/sh ../libtool --mode=link gcc -o libcharset.la -rpath /usrt/lib -version-info 1:0:0 -no-undefined localcharset.lo libtool: link: CURRENT `1:0:0' is not a nonnegative integer libtool: link: `1:0:0' is not valid version information make[2]: *** [libcharset.la] Error 1 make[2]: Leaving directory `C:/eval/libiconv/libiconv-1.8/libcharset/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `C:/eval/libiconv/libiconv-1.8/libcharset' make: *** [all] Error 2 Recognise any of this? Do I need gcc 3.0.3 or any other specific settings/tools? > Dave > -- John **= Email 3 ==========================** Date: Sun, 23 Jun 2002 10:03:08 -0800 From: "Dave and Natalie" Subject: Re: Gettext v0.11.2 On Sun, 23 Jun 2002 09:25:00 +0100, John Poltorak wrote: >On Sat, Jun 22, 2002 at 05:06:26PM -0800, Dave and Natalie wrote: .. >> libiconv-1.8 has a directory called libcharset. I ran configure --prefix=/usr, make, make install in this directory >> and now have /usr/lib/charset.a /usr/lib/charset.dll and /usr/include/libcharset.h and a few other related files. > >Thanks, I gave this a try and did find a libcharset.h which was a copy of >libcharset.h.in but make fell over here:- > > >gcc -I. -I. -I.. -I./.. -g -O2 -DHAVE_CONFIG_H -DLIBDIR=\"/usrt/lib\" -c >./localcharset.c -DDLL_EXP >ORT -DPIC -o .libs/localcharset.lo >gcc -I. -I. -I.. -I./.. -g -O2 -DHAVE_CONFIG_H -DLIBDIR=\"/usrt/lib\" -c >./localcharset.c -o localcharset.o >/dev/null 2>&1 >mv -f .libs/localcharset.lo localcharset.lo >/bin/sh ../libtool --mode=link gcc -o libcharset.la -rpath /usrt/lib >-version-info 1:0:0 -no-undefined localcharset.lo >libtool: link: CURRENT `1:0:0' is not a nonnegative integer >libtool: link: `1:0:0' is not valid version information >make[2]: *** [libcharset.la] Error 1 At this point I have gcc -I. -I. -I.. -I./.. -D__EMX__ -DOS2 -Zmtd -D__ST_MT_ERRNO__ -O2 -fomit-frame-pointer -march=k6 -DHAVE_CONFIG_H -DLIBDIR=\"/usr/lib\" -c ./localcharset.c -o localcharset.o >/dev/null 2>&1 mv -f .libs/localcharset.lo localcharset.lo f:/usr/bin/sh ../libtool --mode=link gcc -Zmtd -D__ST_MT_ERRNO__ -O2 -s -Zsysv-signals -Zstack 512 -o libcharset.la -rpath /usr/lib -version-info 1:0:0 -no-undefined localcharset.lo rm -fr .libs/libcharset.la .libs/charset.* .libs/charset.* f:/usr/bin/sh is sh.exe ³ 163844³02-01-02³ 3:03a which I think you said was from pdksh. Wish there was an easy way to figure out what sh is being used. Dave **= Email 4 ==========================** Date: Sun, 23 Jun 2002 10:45:58 -0500 From: Jeff Robinson Subject: Re: New Autoconf and Automake for OS/2 John Poltorak wrote: > There are new OS/2 versions of Autoconf and Automake at Hobbes:- > > > http://hobbes.nmsu.edu/pub/incoming/autoconf-2_53.zip > > > http://hobbes.nmsu.edu/pub/incoming/automake-1_6_2.zip > > > Great work Andreas! > > > The diffs in them look minimal. Are they likely to get incorporated into > the mainstream versions? > > I notice there is a warning about using PDKSH 5.2.14 with Autoconf. Has > this bug been reported to IlyaZ? > > I guess it would be useful to try and develop a bugtracking system... > > Which shells are known to be usable as /bin/sh ? > > I'm going to try building as many apps as possible with this new autoconf > and hopefully we can make a fresh start on the UnixOS/2 distro if > everything works OK. This time I hope to build as many apps as possible > from scratch rather than just re-assembling existing packages. > > One thing I would like to do which I'm hoping autoconf/automake can > facilitate is incorporation of a 'make PKG' target into a Makefile, so > that a UnixOS/2 PKG can be built automatically. I have no idea how that > could be done, but I hope some sort of M4 macro could be developed which > would be run as part of automake. That would allow PKGs to assembled > without user intervention. > > In wandering through Freshmeat.net I noticed a program called CheckInstall ( http://checkinstall.izto.org/ ) which is targetted at the likes of Slackware and a few other distributions. The idea of the program is that on your system when you do a ./configure and make, you then let CheckInstall run the 'make install' portion so that at the same time it catalogues where all the files go. (And at that time also creates an uninstall package that Slackware could use). I wonder if a concept similar to this would be useful for creating packages? I haven't looked too closely at the program yet, but the feedback on Freshmeat seems very positive. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 5 ==========================** Date: Sun, 23 Jun 2002 11:16:42 +0100 From: John Poltorak Subject: Fetchmail 5.9.13 Fetchmail v5.9.13 is now available here:- http://www.tuxedo.org/~esr/fetchmail/fetchmail-5.9.13.tar.gz Does anyone know if this will build under OS/2? I know there was a recent port for OS/2 but I don't know if any patches were sent to the fetchmail maintainer, in which it will be a matter of catch-up every time there is a new release. -- John **= Email 6 ==========================** Date: Sun, 23 Jun 2002 11:51:49 +0100 From: John Poltorak Subject: Re: Re: Makedef.pl On Sat, Jun 22, 2002 at 11:40:57AM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > Here is a reply I got from the perl5-porters list about the absence of > > 'malloc' in Perl 5.8.0. > > > > Can anyone help formulate a response? > > All I can say is that the Perl DLL used to export malloc, and what it's > supposed to export depends on the symbols in malloc.obj (output of > "emxexp malloc.obj"). Understanding the aliasing and New() Freespace() > option requires reading the src, which I won't have time for before > mid-July. I don't really understand too much about the problem here, but the problem only seems to manifest itself when running tests which involve db.lib, so it seems as though there is some sort of conflict involving calls to malloc between db.lib and Perl DLL. Is there any way of changing db.lib to be compliant? > h~ -- John **= Email 7 ==========================** Date: Sun, 23 Jun 2002 12:22:09 -0400 From: Henry Sobotka Subject: Re: Re: Makedef.pl John Poltorak wrote: > > I don't really understand too much about the problem here, but the problem > only seems to manifest itself when running tests which involve db.lib, so > it seems as though there is some sort of conflict involving calls to > malloc between db.lib and Perl DLL. The error message posted by you and Masaru, i.e. DB_FILHA->PERLB12E.malloc 127 clearly indicates that DB_FILHA.dll can't find malloc in PERLB12E.dll (127 = ERROR_PROC_NOT_FOUND). For all intents and purposes, db.lib is irrelevant to the problem; fiddling with it is comparable to tinkering with your printer because the connection between your computer and modem isn't working. Essentially, either PERLB12E.dll has to export malloc, or DB_FILHA.dll has to call Perl_malloc. Since we know the Perl 5.7.3 DLL exports malloc, reverting to that behaviour is the first solution to consider. h~ **= Email 8 ==========================** Date: Sun, 23 Jun 2002 13:04:16 +0200 (CDT) From: "Adrian Gschwend" Subject: OpenSSH Package Hi all, I guess I'm almost done with my OpenSSH Package which is unixos2 compilant. I got the slackware dir and tried to do it more or less like this, except the libexec dir which seems to be a bad idea. I also moved tnpipe.exe and user.exe into /usr/sbin because I think this is the place where those apps make sense IMHO (correct me when I'm wrong). the readme for tnpipe is now in /usr/doc/openssh-3.1p1/tnpipe.txt The only stuff which is missing are some *.0 files I found in the docs-dir of openssh. It looks like those files are like man pages but without man-format stuff in it. Where do they belong to? Would it be /usr/man/man0? Nickk: what about the etc-files I have to generate according to the manual of the OS/2 port, if I put them to /etc/ssh will OpenSSH for OS/2 find them? The question is if it takes care of %UNIXOS2% setting (I hope so :-) Would be nice if some people could look over the directory structure we have right now and let me know if there are problems in it. If everything is OK I will zip it and upload it to the server cu Adrian ---snip--- Directory of E:\temp\unixos2 23.06.02 12.18 0 etc 23.06.02 12.02 0 usr Directory of E:\temp\unixos2\etc 23.06.02 12.18 0 ssh Directory of E:\temp\unixos2\etc\ssh 26.02.02 20.49 2478 0 sshd_config 22.01.02 15.32 1144 0 ssh_config 15.05.02 16.27 2129 0 ssh_prng_cmds 2.03.01 11.26 951 0 ssh_term 21.08.01 17.14 6217 0 ssh_term.bsd 2.03.01 11.26 951 0 ssh_term.linux 24.08.00 16.18 5850 0 ssh_term.orig 24.08.00 16.17 1163 0 ssh_term.os2 19.01.01 9.11 1253 0 ssh_term.sun 23.01.01 15.11 1255 0 ssh_term.vt100 23.01.01 15.36 1378 0 ssh_term.vt220 20.08.00 22.28 3555 0 tnpipe_config Directory of E:\temp\unixos2\usr 23.06.02 12.23 0 bin 23.06.02 12.19 0 doc 23.06.02 12.25 0 man 23.06.02 12.23 0 sbin Directory of E:\temp\unixos2\usr\bin 22.05.02 21.55 56143 0 scp.exe 22.05.02 21.55 102351 0 sftp.exe 22.05.02 21.55 346356 0 ssh-add.exe 22.05.02 21.55 311034 0 ssh-agent.exe 22.05.02 21.55 349853 0 ssh-keygen.exe 22.05.02 21.55 282726 0 ssh-keyscan.exe 22.05.02 21.54 459373 0 ssh.exe Directory of E:\temp\unixos2\usr\doc 23.06.02 12.23 0 openssh-3.1p1 Directory of E:\temp\unixos2\usr\doc\openssh-3.1p1 23.05.02 11.25 434 0 ChangeLog.os2 7.03.02 5.04 311921 0 ChangeLog.txt 5.03.02 6.38 4864 0 CREDITS 28.12.01 1.57 7945 0 INSTALL 5.03.02 21.03 10696 0 LICENCE 23.05.02 11.23 6308 0 OpenSSH.ICO 25.09.01 6.55 6938 0 OVERVIEW 24.12.01 6.17 2861 0 README 15.05.02 16.40 557 0 readme.eng 23.05.02 11.13 399 0 README.OS2 15.05.02 16.38 575 0 readme.rus 25.09.01 4.21 1714 0 README.smartcard 6.11.00 4.39 72725 0 RFC.nroff 24.08.00 1.44 13451 0 TNPIPE.TXT 9.02.01 4.55 3763 0 WARNING.RNG Directory of E:\temp\unixos2\usr\man 23.06.02 12.34 0 man1 23.06.02 12.34 0 man8 Directory of E:\temp\unixos2\usr\man\man1 5.02.02 2.16 3261 0 scp.1 5.03.02 2.26 7129 0 sftp.1 5.02.02 2.27 4896 0 ssh-add.1 8.02.02 12.02 6315 0 ssh-agent.1 19.02.02 5.22 10081 0 ssh-keygen.1 19.02.02 5.19 3884 0 ssh-keyscan.1 19.02.02 5.27 46411 0 ssh.1 Directory of E:\temp\unixos2\usr\man\man8 25.06.01 6.45 2087 0 sftp-server.8 5.03.02 2.38 43100 0 sshd.8 Directory of E:\temp\unixos2\usr\sbin 22.05.02 21.55 78443 0 sftp-server.exe 22.05.02 21.55 456416 0 sshd.exe 22.08.00 2.02 3817 0 tnpipe.exe 20.08.00 21.53 14515 0 user.exe -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 9 ==========================** Date: Sun, 23 Jun 2002 13:35:23 +0200 From: Andreas Buening Subject: Re: Gettext v0.11.2 Dave and Natalie wrote: > > On Sat, 22 Jun 2002 18:46:27 +0200, Andreas Buening wrote: > > > > >You need that small iconv library for OS/2 (let's call > >it iconv/2) but don't ask me where to find it. > >GNU iconv (which you can get from ftp.gnu.org) doesn't > >know anything about OS/2 charset names. Therefore it's > >most likely completely useless for that purpose. > > Are you sure about this? I see a bunch of headers in lib like this > .. > cp1250.h > cp1251.h > cp1252.h > cp1253.h > cp1254.h > cp1255.h > cp1256.h > cp1257.h > cp1258.h > cp437.h > cp737.h > cp775.h > cp850.h > cp852.h > cp853.h > cp855.h > cp856.h > .. > These look familiar Okay, I can only talk about 1.7. There these header files are only used for DOS and AIX (this could be fixed, of course). I also have a lot more codepages in \LANGUAGE\CODEPAGE. At least the iso-8859-? codepages are missing. And the library is _huge_. I couldn't compile it but I got an 800 K object file (maybe including debug code). I had a bad feeling if I had to link that big thing to every executable. 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 10 ==========================** Date: Sun, 23 Jun 2002 15:04:35 -0800 From: "Dave and Natalie" Subject: Re: Gettext v0.11.2 On Sun, 23 Jun 2002 13:35:23 +0200, Andreas Buening wrote: >> cp855.h >> cp856.h >> .. >> These look familiar > >Okay, I can only talk about 1.7. There these header files >are only used for DOS and AIX (this could be fixed, of course). >I also have a lot more codepages in \LANGUAGE\CODEPAGE. >At least the iso-8859-? codepages are missing. And the library >is _huge_. I couldn't compile it but I got an 800 K object >file (maybe including debug code). I had a bad feeling >if I had to link that big thing to every executable. libiconv-1.8/lib has iso-8859-1 to 8859-16. The list I posted earlier was just a snippet. I ended up with an 800+ K dll with this error iconv.o(iconv.o) : error L2029: 'locale_charset' : unresolved external So I said to hell with makefile.os2 and did the configure and make routine and ended up with an error free build and a 931202 byte dll. About linking this huge thing. Doesn't OS/2 just load one instance of a dll and call whatever routines are needed? Is it that bad to have a huge dll? I don't know much about this. Also I wonder about backwards compatibility when building a dll with libtool. Dave **= Email 11 ==========================** Date: Sun, 23 Jun 2002 15:07:04 +0100 From: John Poltorak Subject: New Autoconf and Automake for OS/2 There are new OS/2 versions of Autoconf and Automake at Hobbes:- http://hobbes.nmsu.edu/pub/incoming/autoconf-2_53.zip http://hobbes.nmsu.edu/pub/incoming/automake-1_6_2.zip Great work Andreas! The diffs in them look minimal. Are they likely to get incorporated into the mainstream versions? I notice there is a warning about using PDKSH 5.2.14 with Autoconf. Has this bug been reported to IlyaZ? I guess it would be useful to try and develop a bugtracking system... Which shells are known to be usable as /bin/sh ? I'm going to try building as many apps as possible with this new autoconf and hopefully we can make a fresh start on the UnixOS/2 distro if everything works OK. This time I hope to build as many apps as possible from scratch rather than just re-assembling existing packages. One thing I would like to do which I'm hoping autoconf/automake can facilitate is incorporation of a 'make PKG' target into a Makefile, so that a UnixOS/2 PKG can be built automatically. I have no idea how that could be done, but I hope some sort of M4 macro could be developed which would be run as part of automake. That would allow PKGs to assembled without user intervention. -- John **= Email 12 ==========================** Date: Sun, 23 Jun 2002 15:18:12 -0800 From: "Dave and Natalie" Subject: Re: Gettext v0.11.2 On Sat, 22 Jun 2002 15:52:24 +0100, John Poltorak wrote: > >BTW where did you get iconv.a ? > >It doesn't say this is required, but I seem to need it. IRC I origanally build it from libiconv-1.7. I have now successfully (I think) build it from libiconv-1.8. I got fed up with makefile.os2 and just did sh configure --enable-extra-encodings --prefix=/usr make and ended up with iconv.a ³ 1546³06-23-02³ 2:48p iconv.def ³ 318³06-23-02³ 2:48p iconv.dll ³ 1026232³06-23-02³ 2:48p libiconv.la ³ 701³06-23-02³ 2:48p libiconv.lai ³ 702³06-23-02³ 2:48p Now according to the readme we have a circular dependency so we need to rebuild gettext then start all over with libiconv then maybe start over with gettext. See the readme for details. Dave **= Email 13 ==========================** Date: Sun, 23 Jun 2002 15:23:32 +0100 From: Thomas Hoffmann Subject: Re: packages in unixos2-current:SCRIPT function ... John Poltorak schrieb: > > On Tue, Jun 18, 2002 at 11:34:03PM +0100, Thomas Hoffmann wrote: > > Is there a reason that nearly in no package it was attempted to > > understand the install.sh file, translate it to REXX and introduce it > > into PKGINFO using a SCRIPT line? > > The packages are currently built to resemble the equivalent Slackware > package. No attempt has been made convert the install script to OS/2, > and it is simply there as a placeholder until more of the jigsaw is > available. This is not true for all packages: libemx.zip and bash.zip use REXX install scripts. And I think improving the existing packages is as important as adding new stuff. Maybe we can work out some transformation rules for those scripts (and for cleaning the doc directories from old and misleading OS/2 specific files). Can anybody explain how the symlink functions are supposed to work under UnixOs2? In the Unixos2 PKGINFO file a specific SYMLINK line has to be used for this (originally, symbolic links are established via calling ln in the doinst.sh scripts). > > Building up the distro is fairly time consuming and not everything can be > made available from the begining. John, the whole infastructure of UnixOS2 is not that clear to me and sometimes I am afraid this project will finally just "dry out" if there are no real maintainers of the packages. E.g. the bash package: In Unixos2, currently a repackaged version of v.2.03 is offered. Although it is one of the better examples (using doinst.cmd), the Readme files in the doc directory do not reflect the changes to the original package. Now, Jun Sawataishi has published a port of bash2.05: In a "non-Unixos2" structure again. Does he know about Unixos2? Certainly yes, because he mentions the UNIXROOT variable in the Readme. Wouldn't it be a good idea to persuade him to become the real maintainer of this package and to write full blown install scripts? Just an idea ... -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ... **= Email 14 ==========================** Date: Sun, 23 Jun 2002 15:35:24 +0100 From: Thomas Hoffmann Subject: Re: Gettext v0.11.2 John Poltorak schrieb: > Thanks, I gave this a try and did find a libcharset.h which was a copy of > libcharset.h.in but make fell over here:- > > gcc -I. -I. -I.. -I./.. -g -O2 -DHAVE_CONFIG_H -DLIBDIR=\"/usrt/lib\" -c > ./localcharset.c -DDLL_EXP > ORT -DPIC -o .libs/localcharset.lo > gcc -I. -I. -I.. -I./.. -g -O2 -DHAVE_CONFIG_H -DLIBDIR=\"/usrt/lib\" -c > ./localcharset.c -o localcharset.o >/dev/null 2>&1 > mv -f .libs/localcharset.lo localcharset.lo > /bin/sh ../libtool --mode=link gcc -o libcharset.la -rpath /usrt/lib > -version-info 1:0:0 -no-undefined localcharset.lo > libtool: link: CURRENT `1:0:0' is not a nonnegative integer > libtool: link: `1:0:0' is not valid version information > make[2]: *** [libcharset.la] Error 1 > make[2]: Leaving directory `C:/eval/libiconv/libiconv-1.8/libcharset/lib' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `C:/eval/libiconv/libiconv-1.8/libcharset' > make: *** [all] Error 2 There was some discussion about this problem recently. It seems that something goes wrong with parsing the version info (shell related problem?) In libtool the parsing and check happen here: # Parse the version information argument. IFS="${IFS= }"; save_ifs="$IFS"; IFS=':' set dummy $vinfo 0 0 0 IFS="$save_ifs" if test -n "$8"; then $echo "$modename: too many parameters to \`-version-info'" 1>&2 $echo "$help" 1>&2 exit 1 fi current="$2" revision="$3" age="$4" # Check that each of the things are valid numbers. case $current in 0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;; *) $echo "$modename: CURRENT \`$current' is not a nonnegative integer" 1>&2 $echo "$modename: \`$vinfo' is not valid version information" 1>&2 exit 1 ;; esac Now, "current" should hold "1" after parsing the current:revision:age string ... -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ... **= Email 15 ==========================** Date: Sun, 23 Jun 2002 15:37:13 +0100 From: John Poltorak Subject: Re: packages in unixos2-current:SCRIPT function ... On Sun, Jun 23, 2002 at 03:23:32PM +0100, Thomas Hoffmann wrote: > John Poltorak schrieb: > > > > On Tue, Jun 18, 2002 at 11:34:03PM +0100, Thomas Hoffmann wrote: > > > Is there a reason that nearly in no package it was attempted to > > > understand the install.sh file, translate it to REXX and introduce it > > > into PKGINFO using a SCRIPT line? > > > > The packages are currently built to resemble the equivalent Slackware > > package. No attempt has been made convert the install script to OS/2, > > and it is simply there as a placeholder until more of the jigsaw is > > available. > > This is not true for all packages: libemx.zip and bash.zip use REXX > install scripts. And I think improving the existing packages is as > important as adding new stuff. Maybe we can work out some transformation > rules for those scripts (and for cleaning the doc directories from old > and misleading OS/2 specific files). The first thing I wanted was to establish a single repository for OS/2 ports of Unix apps. Until now, there wasn't anything. You needed to try Hobbes, Leo and countless personal web sites to assemble a reasonable collection of apps, and there were often duplcates to consider. I think we now have the basis of a reasonable framework, although a number of key apps such as gcc, Perl, Python, Apache etc are still missing, but we know where to find them, and there is a placeholder in the UnixOS/2 distro. In the process of assembling these packages, things like FHS compliance, which is something we aspired to incorporate, has been set to one side for the sake of expediancy. I agree, that we should look at improving the existing packges and I'd like to think we are almost in a position to do so. What I'd like to start doing soon is rebuilding as many packages as possible from original source, and hopefully this will remove any rendundant files. > Can anybody explain how the symlink functions are supposed to work under > UnixOs2? In the Unixos2 PKGINFO file a specific SYMLINK line has to be > used for this (originally, symbolic links are established via calling ln > in the doinst.sh scripts). All the doinst.sh files are just placeholders. I would completely ignore them for the time being. > > > > Building up the distro is fairly time consuming and not everything can be > > made available from the begining. > > John, the whole infastructure of UnixOS2 is not that clear to me and > sometimes I am afraid this project will finally just "dry out" if there > are no real maintainers of the packages. One thing I have been suggesting for a long time is that it a bad idea to require OS/2 maintainers of specific pacakges. I would like to get as much of the OS/2 specific code integrated into the mainstream package itself if possible. This means that when a new release of something like LESS is released we ought to expect it to build on OS/2 without waiting for the OS/2 maintainer to do his bit. > E.g. the bash package: In Unixos2, currently a repackaged version of > v.2.03 is offered. Although it is one of the better examples (using > doinst.cmd), the Readme files in the doc directory do not reflect the > changes to the original package. That's right, nothing has been altered up until now as far as docs go. The main priority has been making packages available under UnixOS/2. > Now, Jun Sawataishi has published a > port of bash2.05: In a "non-Unixos2" structure again. Does he know about > Unixos2? Certainly yes, because he mentions the UNIXROOT variable in the > Readme. Wouldn't it be a good idea to persuade him to become the real > maintainer of this package and to write full blown install scripts? I don't think it necessary to ask any porter to provide an install script, that should be up to the UnixOS/2 maintainers. As for Bash v2.05, I can't help thinking that it is far too big, especially for something which is used for shell scripts. I tried it, but went back to 2.03 fairly soon for performance reasons. > Just an idea ... > > -- > Thomas Hoffmann Telephone: > 49-351-4598831 > thoffman at zappa.sax.de Dresden, > Germany > > ..sig under construction ... -- John **= Email 16 ==========================** Date: Sun, 23 Jun 2002 17:39:39 +0100 From: Thomas Hoffmann Subject: Shells honoring "extproc" I tried some scripts (from groff: nroff.cmd, ...) which use "extproc" in the first line to let a given shell process the script. Now I noticed that only ksh.exe "digests" the extproc line, the other shells I tried (bash, ash) all complain about extproc. A string search in the executables shows that ksh seems to contain code for handling this line (as perl does), but the other shells do not show traces of extproc handling. What do you think: Is it worthwile to add special code to, e.g., bash or can this have side effects? -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ... **= Email 17 ==========================** Date: Sun, 23 Jun 2002 18:13:46 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: packages in unixos2-current:SCRIPT function ... On Sun, 23 Jun 2002 15:37:13 +0100, John Poltorak wrote: >The first thing I wanted was to establish a single repository for OS/2 >ports of Unix apps. Until now, there wasn't anything. You needed to try >Hobbes, Leo and countless personal web sites to assemble a reasonable >collection of apps, and there were often duplcates to consider. yeah what you started to do is definitely great. >I think we now have the basis of a reasonable framework, although a number >of key apps such as gcc, Perl, Python, Apache etc are still missing, but >we know where to find them, and there is a placeholder in the UnixOS/2 >distro. About GCC, with Andy we have a great maintainer of the port so far but I wish he would release it FHS compilant in the future, that would make an install definitely easier. Same goes for all the other packages we need to compile stuff. I started to write c/c++ applications on linux now, mainly because I didn't had the time to set up all the stuff on OS/2. On linux I can run a make and everything I need is provided. Holger's LIBEMU will definitely help a lot about that but we still have to solve the problem of all the tools, you are right if you say that the packages should be repackaged according to the FHS. And even if Holger is not yet ready with LIBEMU we can work on the packages we have so far. >In the process of assembling these packages, things like FHS compliance, >which is something we aspired to incorporate, has been set to one side for >the sake of expediancy. I agree, that we should look at improving the >existing packges and I'd like to think we are almost in a position to do >so. What I'd like to start doing soon is rebuilding as many packages as >possible from original source, and hopefully this will remove any >rendundant files. sound very good, this is especially needed for the different revisions of libraries. >One thing I have been suggesting for a long time is that it a bad idea to >require OS/2 maintainers of specific pacakges. I would like to get as much >of the OS/2 specific code integrated into the mainstream package itself if >possible. This means that when a new release of something like LESS is >released we ought to expect it to build on OS/2 without waiting for the >OS/2 maintainer to do his bit. not possible without LIBEMU IMHO. At least not for most of the packages. So in my opinion we should define a set of packages people need to be able to compile applications. This includes stuff like gcc, automake, autoconf and so on. All those packages should be FHS compilant and use UNIXROOT as reference to config files and such stuff. If we have this it will be much easier to start other ports. Also LIBEMU will make much more sense if the developer tools are on a common level. What packages would we need to archive that? (sorry, developer newbie :-) cu Adrian PS Holger: Thanks for the hint about Steven's books, bought 5 of them so far, they are just excellent! I wish I would have more time to read & code examples... -- Adrian Gschwend at OS/2 Netlabs ICQ: 22419590 ktk at netlabs.org ------- The OS/2 OpenSource Project: http://www.netlabs.org **= Email 18 ==========================** Date: Sun, 23 Jun 2002 18:34:04 +0200 (CEST) From: Stefan Neis Subject: Re: Re: Makedef.pl On Sun, 23 Jun 2002, John Poltorak wrote: > I don't really understand too much about the problem here, but the problem > only seems to manifest itself when running tests which involve db.lib, so > it seems as though there is some sort of conflict involving calls to > malloc between db.lib and Perl DLL. If you don't mind some wild and simplistic guessing (I didn't look at any details), I'd try to summarize/explain the problem as follows: - (Old) perl includes it's own memory management routines, exported not only as Perl_malloc/Perl_free, but also as malloc/free. - Linking (old) perl carefully avoids to link in anything else defining malloc/free since that would result in multiple definitions. - Some libs (like db.lib) need to allocate/free memory for themselves and use the perl routines for this purpose when linked into a corresponding executable. - New perl no longer defines malloc/free (just Perl_malloc/Perl_free), but the unchanged linking command still avoids to link in any foreign definition of malloc/free, so libraries which require malloc/free no longer find a suitable definition for those functions and thus are unhappy. - Changing those libraries to use Perl_malloc/Perl_free is out of the question since that would mean they no longer work for anything but Perl. - Two possible soultions: * Export Perl_malloc/Perl_free as malloc/free as well (just as before). * Linking in some library from EMX which defines malloc/free as well might work as well. Possible drawback: If some memory gets allocated by Perl_malloc and freed by free or allocated by malloc and freed by Perl_free, you're likely to get (a) corrupted heap(s), leading to all kinds of runtime errors. Unfortunately, I don't know enough about Perl internals to determine whether this is something which might possibly happen or not, so to me, it looks like the first solution is preferable. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 19 ==========================** Date: Sun, 23 Jun 2002 19:12:58 +0100 From: John Poltorak Subject: Re: Re: Makedef.pl On Sun, Jun 23, 2002 at 12:22:09PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > I don't really understand too much about the problem here, but the problem > > only seems to manifest itself when running tests which involve db.lib, so > > it seems as though there is some sort of conflict involving calls to > > malloc between db.lib and Perl DLL. > > The error message posted by you and Masaru, i.e. > > DB_FILHA->PERLB12E.malloc > 127 > > clearly indicates that DB_FILHA.dll can't find malloc in PERLB12E.dll > (127 = ERROR_PROC_NOT_FOUND). For all intents and purposes, db.lib is > irrelevant to the problem; fiddling with it is comparable to tinkering > with your printer because the connection between your computer and modem > isn't working. If fiddling with my printer makes my modem work, I will fiddle. By looking at the printer you just may notice that it's connected to the serial porter and your modem is connected to the parallel port :-)... > Essentially, either PERLB12E.dll has to export malloc, or DB_FILHA.dll > has to call Perl_malloc. Since we know the Perl 5.7.3 DLL exports > malloc, reverting to that behaviour is the first solution to consider. I suspect that the problem is related to the compilation of malloc.obj... emxexp.exe malloc.obj ; From malloc.obj "Perl_malloced_size" "Perl_malloc" "Perl_mfree" "Perl_realloc" "Perl_calloc" "Perl_strdup" "Perl_putenv" "Perl_get_mstats" "Perl_dump_mstats" I've looked through the Perl Makefile to see where it is compiled, but it's a real monster and I don't have clue. Maybe I can define a different malloc.obj through Configure... > h~ -- John **= Email 20 ==========================** Date: Sun, 23 Jun 2002 19:35:02 +0100 From: John Poltorak Subject: Re: Re: Makedef.pl On Sun, Jun 23, 2002 at 06:34:04PM +0200, Stefan Neis wrote: > On Sun, 23 Jun 2002, John Poltorak wrote: > > > I don't really understand too much about the problem here, but the problem > > only seems to manifest itself when running tests which involve db.lib, so > > it seems as though there is some sort of conflict involving calls to > > malloc between db.lib and Perl DLL. > > If you don't mind some wild and simplistic guessing (I didn't look at any > details), I'd try to summarize/explain the problem as follows: > - (Old) perl The thing is, Perl 5.7.3 which is part of the developement branch which led to 5.8.0 did it the old way just a month or two ago. This change must have occurred very recently. > includes it's own memory management routines, exported not > only as Perl_malloc/Perl_free, but also as malloc/free. > - Linking (old) perl carefully avoids to link in anything else defining > malloc/free since that would result in multiple definitions. > - Some libs (like db.lib) need to allocate/free memory for themselves > and use the perl routines for this purpose when linked into a > corresponding executable. > - New perl no longer defines malloc/free (just Perl_malloc/Perl_free), > but the unchanged linking command still avoids to link in any > foreign definition of malloc/free, so libraries which require > malloc/free no longer find a suitable definition for those > functions and thus are unhappy. This really sounds like a major change, yet Perl does build OK, and only tests realted to one library are affected, which is very surprising since all of these have been removed:- Perl_malloc => "malloc" Perl_mfree => "free" Perl_realloc => "realloc" Perl_calloc => "calloc" > - Changing those libraries to use Perl_malloc/Perl_free is out of the > question since that would mean they no longer work for anything > but Perl. I wonder how this works on Windows... > - Two possible soultions: > * Export Perl_malloc/Perl_free as malloc/free as well (just as before). How? > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 21 ==========================** Date: Sun, 23 Jun 2002 20:17:31 +0000 From: "Lyn St George" Subject: UnixOS/2 environment Hi all I'm trying to rebuild my GNU/Unixos2 environment (as it was corrupted somehow) and am getting into a complete mess and wasting heaps of time getting nowhere. Does anyone have a list of tools, or a dir listing, of a working environment they could send me? (I have looked for such a list but can't find one) Many thanks in advance. - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 22 ==========================** Date: Sun, 23 Jun 2002 20:21:09 +0100 From: John Poltorak Subject: Automake patches The patches in Automake 1.6.2 do not include these two lines from tests\ansi3.test:- AC_OBJEXT AC_EXEEXT -- John **= Email 23 ==========================** Date: Sun, 23 Jun 2002 20:30:35 +0100 From: John Poltorak Subject: Re: UnixOS/2 environment On Sun, Jun 23, 2002 at 08:17:31PM +0000, Lyn St George wrote: > Hi all > > I'm trying to rebuild my GNU/Unixos2 environment (as > it was corrupted somehow) and am getting into a complete > mess and wasting heaps of time getting nowhere. > > Does anyone have a list of tools, or a dir listing, of > a working environment they could send me? > > (I have looked for such a list but can't find one) I think the closest thing you will find is this:- ftp://borneo.gmd.de/pub/misc/XFree86OS2/alpha/emxtree.zip You'll need lots of disk space and a fast connection to get it. > Many thanks in advance. > > - > Cheers > Lyn St George > +--------------------------------------------------------------------------------- > + http://www.zolotek.net .. eCommerce hosting, consulting > + http://www.os2docs.org .. some 'How To' stuff ... > +---------------------------------------------------------------------------------- > -- John **= Email 24 ==========================** Date: Sun, 23 Jun 2002 20:47:06 +0100 From: csaba.raduly at sophos.com Subject: Re: Re: Makedef.pl On 23/06/2002 19:35:02 owner-os2-unix wrote: [snip] > >This really sounds like a major change, yet Perl does build OK, and only >tests related to one library are affected, which is very surprising since >all of these have been removed:- > >Perl_malloc => "malloc" >Perl_mfree => "free" >Perl_realloc => "realloc" >Perl_calloc => "calloc" > [snip] > > >On Sun, Jun 23, 2002 at 06:34:04PM +0200, Stefan Neis wrote: >> - Two possible soultions: >> * Export Perl_malloc/Perl_free as malloc/free as well (just as before). > >How? > By re-adding the above lines to Makedef.pl in the appropriate place, perhaps. (Should be easy to spot where they need to go). -- 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 25 ==========================** Date: Sun, 23 Jun 2002 21:03:31 +0100 From: John Poltorak Subject: Re: Re: Makedef.pl On Sun, Jun 23, 2002 at 08:47:06PM +0100, csaba.raduly at sophos.com wrote: > > On 23/06/2002 19:35:02 owner-os2-unix wrote: > > [snip] > > > >This really sounds like a major change, yet Perl does build OK, and only > >tests related to one library are affected, which is very surprising since > >all of these have been removed:- > > > >Perl_malloc => "malloc" > >Perl_mfree => "free" > >Perl_realloc => "realloc" > >Perl_calloc => "calloc" > > > [snip] > > > > > >On Sun, Jun 23, 2002 at 06:34:04PM +0200, Stefan Neis wrote: > >> - Two possible soultions: > >> * Export Perl_malloc/Perl_free as malloc/free as well (just as > before). > > > >How? > > > > By re-adding the above lines to Makedef.pl in the appropriate place, > perhaps. > (Should be easy to spot where they need to go). Not as easy as you'd think... This whole section which was in 5.7.3 has disappeared:- my %bincompat5005 = ( Perl_call_atexit => "perl_atexit", Perl_eval_sv => "perl_eval_sv", Perl_eval_pv => "perl_eval_pv", Perl_call_argv => "perl_call_argv", Perl_call_method => "perl_call_method", Perl_call_pv => "perl_call_pv", Perl_call_sv => "perl_call_sv", Perl_get_av => "perl_get_av", Perl_get_cv => "perl_get_cv", Perl_get_hv => "perl_get_hv", Perl_get_sv => "perl_get_sv", Perl_init_i18nl10n => "perl_init_i18nl10n", Perl_init_i18nl14n => "perl_init_i18nl14n", Perl_new_collate => "perl_new_collate", Perl_new_ctype => "perl_new_ctype", Perl_new_numeric => "perl_new_numeric", Perl_require_pv => "perl_require_pv", Perl_safesyscalloc => "Perl_safecalloc", Perl_safesysfree => "Perl_safefree", Perl_safesysmalloc => "Perl_safemalloc", Perl_safesysrealloc => "Perl_saferealloc", Perl_set_numeric_local => "perl_set_numeric_local", Perl_set_numeric_standard => "perl_set_numeric_standard", Perl_malloc => "malloc", Perl_mfree => "free", Perl_realloc => "realloc", Perl_calloc => "calloc", ); my $bincompat5005 = join("|", keys %bincompat5005); Just putting it back in on the off chance that it may work, without knowing why it was removed in the first place is likely to cause some trouble. -- John **= Email 26 ==========================** Date: Sun, 23 Jun 2002 22:11:40 +0200 (CEST) From: Stefan Neis Subject: Re: Re: Makedef.pl On Sun, 23 Jun 2002, John Poltorak wrote: > This really sounds like a major change, yet Perl does build OK, and only > tests realted to one library are affected, which is very surprising since > all of these have been removed:- > > Perl_malloc => "malloc" > Perl_mfree => "free" > Perl_realloc => "realloc" > Perl_calloc => "calloc" Well, Henry's last post made me realize that I over-simplified since there's also a db_handle.dll which is involved.... So most of Perl's dlls seem to handle that change just fine, so there's probably some "typo" withing the code for the db_handle.dll. :-( > > - Two possible soultions: > > * Export Perl_malloc/Perl_free as malloc/free as well (just as before). > > How? Generally speaking: By readding those transformations you cited as removed above. But I really wonder if this shouldn't be handled by db_handle.dll... Anyway, I know strictly nothing about the technical details. :-( Regards, Stefan **= Email 27 ==========================** Date: Sun, 23 Jun 2002 23:02:02 +0200 From: Andreas Buening Subject: Re: New Autoconf and Automake for OS/2 John Poltorak wrote: > > There are new OS/2 versions of Autoconf and Automake at Hobbes:- > > http://hobbes.nmsu.edu/pub/incoming/autoconf-2_53.zip > > http://hobbes.nmsu.edu/pub/incoming/automake-1_6_2.zip > > Great work Andreas! > > The diffs in them look minimal. Are they likely to get incorporated into > the mainstream versions? We'll see. > I notice there is a warning about using PDKSH 5.2.14 with Autoconf. Has > this bug been reported to IlyaZ? Yes. But it's only the _install_ process, i.e. before you enter "make install" you should temporarily change to ash or bash. > I guess it would be useful to try and develop a bugtracking system... Okay. Who will do? > Which shells are known to be usable as /bin/sh ? I'm currently using ksh. Other shells might or might not work. It would take too much time to test them all. > I'm going to try building as many apps as possible with this new autoconf > and hopefully we can make a fresh start on the UnixOS/2 distro if > everything works OK. This time I hope to build as many apps as possible > from scratch rather than just re-assembling existing packages. > > One thing I would like to do which I'm hoping autoconf/automake can > facilitate is incorporation of a 'make PKG' target into a Makefile, so > that a UnixOS/2 PKG can be built automatically. I have no idea how that > could be done, but I hope some sort of M4 macro could be developed which > would be run as part of automake. That would allow PKGs to assembled > without user intervention. I don't like this approach because - make PKG will not be included into the "official" sources - Some packages may need some special treatment, i.e. a general "make PKG" might fail for them. We must keep the maintainance overhead as small as possible. I'd prefer to use "make install" for that. It's simple, it needs no additional effort once the specific package has been made OS/2 compatible. In the worst case you might have to add some minor enhancements like "emxomf foo.a" or renaming or removing one or two redundant files. A package description might then look like export CPPFLAGS="-D__ST_MT_ERRNO__" export CFLAGS="-O2 -Zmt -Zomf" export LDFLAGS="-s -Zcrtdll -Zlinker ..." export ac_executable_extensions=".exe" ./configure --prefix=x:/usr --disable-blurb --with-bla" make make install # maybe some additional command, that checkinstall tool # sounds interesting. The *FLAGS should be standardized in most cases. Then run zip or whatever and you have your binary package. Then we need a simple and failure safe install script which installs the files, another script that updates your installation (info index files, compressing man pages, whatever). And perhaps a final overall check script that tests for your build environment. 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 28 ==========================** Date: Sun, 23 Jun 2002 23:02:13 +0200 From: Andreas Buening Subject: Re: packages in unixos2-current:SCRIPT function ... John Poltorak wrote: > > On Sun, Jun 23, 2002 at 03:23:32PM +0100, Thomas Hoffmann wrote: [snip] > > John, the whole infastructure of UnixOS2 is not that clear to me and > > sometimes I am afraid this project will finally just "dry out" if there > > are no real maintainers of the packages. > > One thing I have been suggesting for a long time is that it a bad idea to > require OS/2 maintainers of specific pacakges. I would like to get as much > of the OS/2 specific code integrated into the mainstream package itself if > possible. This means that when a new release of something like LESS is > released we ought to expect it to build on OS/2 without waiting for the > OS/2 maintainer to do his bit. Having an "official" maintainer is not a bad idea. Somebody who is on the package specific mailing list and tries to download and compile every inofficial test release. Then there wouldn't be any surprising official releases that don't work with OS/2 because of one or two newly introduced incompatibilities. This needn't be an experienced programmer, in principle everybody who has a working build environment can do the job. Any volunteers? ;-) It's just to make sure that no new incompatibilities/bugs are introduced into the specific package. [snip] > > Now, Jun Sawataishi has published a > > port of bash2.05: In a "non-Unixos2" structure again. Does he know about > > Unixos2? Certainly yes, because he mentions the UNIXROOT variable in the > > Readme. Wouldn't it be a good idea to persuade him to become the real > > maintainer of this package and to write full blown install scripts? > > I don't think it necessary to ask any porter to provide an install script, > that should be up to the UnixOS/2 maintainers. That's true. It's not necessary that the person who makes a package running on OS/2 has also to be the person who makes the package ready for UnixOS/2. Nevertheless you need a "hardcore" team of at least 4-5 people who are willing to work on packaging. [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 29 ==========================** Date: Sun, 23 Jun 2002 23:15:28 +0200 From: Andreas Buening Subject: Re: Automake patches John Poltorak wrote: > > The patches in Automake 1.6.2 do not include these two lines from > tests\ansi3.test:- > > AC_OBJEXT > AC_EXEEXT Man, John, you're fast! :-) I played around with the testsuite and I forgot that file. But it doesn't matter. I don't know why so many of the tests fail. If you run the commands "by hand" it seems to work. The testsuite is so incredibly slow that I decided there are better possibilities to waste my time. ;-) 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.