From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 4 Jul 2002 04:31:26 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 262 ************************************************** Wednesday 03 July 2002 Number 262 ************************************************** Subjects for today 1 Re: GREP - LDFLAGS : John Poltorak 2 Re: MOZTOOLS : John Poltorak 3 Re: GREP - LDFLAGS : csaba.raduly at sophos.com 4 Re: Gettext / libiconv : John Poltorak 5 Re: GREP - LDFLAGS : John Poltorak 6 Gettext / libiconv : Franz Bakan" 7 Re: Gettext / libiconv : John Poltorak 8 Re: Gettext / libiconv : Franz Bakan" 9 Re: Gettext / libiconv : John Poltorak 10 Re: Gettext / libiconv : Franz Bakan" 11 Re: Gettext / libiconv : Franz Bakan" 12 Re: Gettext / libiconv : John Poltorak 13 Re: Gettext / libiconv : Franz Bakan" 14 Build GREP with new Autoconf : John Poltorak 15 Re: Wget build bug ? : Dave and Natalie" 16 Re: Wget build bug ? : Dave and Natalie" 17 SED script : John Poltorak 18 Re: GREP - LDFLAGS : John Poltorak 19 Re: GREP - LDFLAGS : Andreas Buening **= Email 1 ==========================** Date: Thu, 4 Jul 2002 08:19:10 +0100 From: John Poltorak Subject: Re: GREP - LDFLAGS On Wed, Jul 03, 2002 at 11:15:11PM +0200, Stefan Neis wrote: > On Wed, 3 Jul 2002, John Poltorak wrote: > > > > > #line 990 "configure" > > #include "confdefs.h" > > > > main(){return(0);} > > The content of confdefs.h might be broken somehow, otherwise I don't see, > why compilation should fail (i.e. that sample program sure compiles for > me with the given flags). No, this is a red herring. I have just noticed that the original configure script is being run, so it looks as though autoconf must have failed for some reason... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 2 ==========================** Date: Thu, 4 Jul 2002 08:34:24 +0100 From: John Poltorak Subject: Re: MOZTOOLS On Wed, Jul 03, 2002 at 08:43:30PM -0500, Jeff Robinson wrote: > The fine Mozilla folks have made a list of the specific tools that are > needed for the build, as well as the archives that they come from ( > http://www.mozilla.org/ports/os2/setup.html ). Yes, I realise it's a nightmare trying to collect the required apps individually. > Some of these tools have > also been specifically modified for the building of Mozilla, such as the > included version of gmake 3.76.1 with an additional file-handle fix. Does the new release of Make (3.79.1) work equally well? BTW does it make any difference if it is called gmake or make? > All these tools are then put into a single directory called MozTools > which is usually only added to the path when one is doing a build of > Mozilla, using the setmozenv.cmd. Hopefully this won't interfere with > anything in the UnixOS2 project. > > If the new tools compiled for UnixOS2 work with building Mozilla then I > don't think there'd be too much trouble incorporating them into the > package, or removing said tool from the MozTools package and directing > folks to use the UnixOS2 ones. It would be useful to see if any UnixOS/2 versions are suitable replacement so that a common set of tools could emerge at some point. Also, if any notices that UnixOS/2 versions fail in some way, could this be reported? > Anyways, I am hoping that the way the archive is made that it will be > reasonably clear that it is specifically for building Mozilla. I've got > no problems ammending the description if you think it should be > clarified more, though I do see this archive having a role for people > that want to try building Mozilla. I've never tried building Mozilla myself, maybe I should do so... > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- -- John **= Email 3 ==========================** Date: Thu, 4 Jul 2002 09:33:54 +0100 From: csaba.raduly at sophos.com Subject: Re: GREP - LDFLAGS On 03/07/2002 20:58:17 owner-os2-unix wrote: [snip] >I just can't seem to create a usable configure script for GREP from the >GNU source. > >This is what I do once the original source has been extracted:- > >patch -p2 grep-patches > >mv m4/init.m4 m4/init.m4.old >touch m4/init.m4 >mv m4/header.m4 m4/header.m4.old >touch m4/header.m4 >cp -p $BUILDROOT/lib/progtest.m4 m4 > >cat m4/*.m4 > acinclude.m4 >aclocal -I m4 >automake >autoconf >autoheader > [snip, there were some errors] >./configure --without-included-regex --without-included-gettext >loading site script c:/unixos2/lib/config.site >creating cache ./config.cache >checking for a BSD compatible install... ./install-sh -c >checking whether build environment is sane... yes >checking whether make sets ${MAKE}... yes >checking for working aclocal... found >checking for working autoconf... found >checking for working automake... found >checking for working autoheader... found >checking for working makeinfo... found >checking host system type... i386-pc-os2-emx >checking for mawk... awk >checking for gcc... gcc The above suggests that path checking worked >checking whether the C compiler (gcc -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ >-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio) works... no >configure: error: installation or configuration problem: C compiler cannot >create executables. > > > >I'm at a bit of a loss as to what has gone wrong here... > You might have needed -Zexe in your LDFLAGS, but -Zomf takes care of that. Check the end of config.log, it might reveal more information. Failing that, run sh -x configure --without-included-regex --without-included-gettext Be sure to redirect the (copious) output ! -- 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 4 ==========================** Date: Thu, 4 Jul 2002 09:43:56 +0100 From: John Poltorak Subject: Re: Gettext / libiconv On Thu, Jul 04, 2002 at 10:22:42AM +0200, Franz Bakan wrote: > Hi, > > I also tried to rebuild gettext-0.11.2 > > It worked (the non-masochistic way) after changing > > VERSION = $(shell sed ../configure.in -ne "/AM_INIT_AUTOMAKE/{" -e "s/.*(gettext, *\\(.*\\))/\\1/" -e "p" -e "}") > to > VERSION = 0.11.2 > > in os2/Makefile Was this a required change? > (and after first getting libiconv-0.1.0 and compiling it) The latest libiconv is 1.8, which some people have used successfully. > I used gcc 2.8.1 and the new ld.exe and emxbind.exe as suggested. > > The produced intl.dll works for displaying localized messages for me, but > > when I use msgmerge (the version of 0.11.2) (to build SANE) > it fails with SIGSEV. Not sure if this would be relevant but do you have several INTL.DLLs around? Maybe there is some conflict... Also, if you are using an old libiconv there may be some incompatiblities with the new gettext.. > Regards, > Franz -- John **= Email 5 ==========================** Date: Thu, 4 Jul 2002 09:57:40 +0100 From: John Poltorak Subject: Re: GREP - LDFLAGS On Thu, Jul 04, 2002 at 09:33:54AM +0100, csaba.raduly at sophos.com wrote: > > On 03/07/2002 20:58:17 owner-os2-unix wrote: > > The above suggests that path checking worked > > >checking whether the C compiler (gcc -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ > >-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio) works... no > >configure: error: installation or configuration problem: C compiler cannot > > >create executables. > > > > > > > >I'm at a bit of a loss as to what has gone wrong here... > > > > You might have needed -Zexe in your LDFLAGS, but -Zomf takes care of that. > Check the end of config.log, it might reveal more information. > Failing that, run > > sh -x configure --without-included-regex --without-included-gettext The problem here is due to autoconf not running successfully. I'm using the original configure script by mistake rather than a newly created one. BTW it isn't an RO attribute which has been set, although I have come unstuck because of things like that in the past. Just wondered if there is any way to ensure something like 'attrib -r *' whilst running 'tar zxf'... > Be sure to redirect the (copious) output ! My build system automatically creates a complete log of the whole build process, which is always handy to have. -- John **= Email 6 ==========================** Date: Thu, 04 Jul 2002 10:22:42 +0200 (MSZ) From: "Franz Bakan" Subject: Gettext / libiconv Hi, I also tried to rebuild gettext-0.11.2 It worked (the non-masochistic way) after changing VERSION = $(shell sed ../configure.in -ne "/AM_INIT_AUTOMAKE/{" -e "s/.*(gettext, *\\(.*\\))/\\1/" -e "p" -e "}") to VERSION = 0.11.2 in os2/Makefile (and after first getting libiconv-0.1.0 and compiling it) I used gcc 2.8.1 and the new ld.exe and emxbind.exe as suggested. The produced intl.dll works for displaying localized messages for me, but when I use msgmerge (the version of 0.11.2) (to build SANE) it fails with SIGSEV. The complete commandline producing the SIGSEV was: msgmerge epson.de.po.old epson.pot -o epson.de.po I have used pmgdb to debug and found out that the msgmerge crashes at line 1441 in gettext-0.11.2\lib\linebreak.c size_t res = iconv (cd, NULL, NULL, &outptr, &outsize); I tried to mail this bug to Andrew Z. but his mailbox is full... What to do? Regards, Franz **= Email 7 ==========================** Date: Thu, 4 Jul 2002 11:31:45 +0100 From: John Poltorak Subject: Re: Gettext / libiconv On Thu, Jul 04, 2002 at 11:37:53AM +0200, Franz Bakan wrote: > On Thu, 4 Jul 2002 09:43:56 +0100, John Poltorak wrote: > > >> I also tried to rebuild gettext-0.11.2 > >> > >> It worked (the non-masochistic way) after changing > >> > >> VERSION = $(shell sed ../configure.in -ne "/AM_INIT_AUTOMAKE/{" -e > "s/.*(gettext, *\\(.*\\))/\\1/" -e "p" -e "}") > >> to > >> VERSION = 0.11.2 > >> > >> in os2/Makefile > > > > > >Was this a required change? > > What do you mean? > > It was required to build for my environement. > Perhaps with another incarnation of 'shell' or > another 'sed' the original Makefile would have worked. I always have problems trying to build gettext and end up with a number of strange directories in os2:- -p .exe 0.11.2) emx out This supposedly 'easy method' never works for me. Maybe the change you made might fix it for me too... What problem occurred before you made the change to VERSION? > >The latest libiconv is 1.8, which some people have used successfully. > > 0.1.0 is a wrapper for OS/2 unicode-API. It has nothing to do > with the gnu version-numbering. Do you have a URL for this? > But nevertheless I could try 1.8. > Is there a compiled version of 1.8 somewhere available? Some people have managed to get it built straight out of the box just using 'configure & make'... > Regards, > Franz -- John **= Email 8 ==========================** Date: Thu, 04 Jul 2002 11:37:53 +0200 (MSZ) From: "Franz Bakan" Subject: Re: Gettext / libiconv On Thu, 4 Jul 2002 09:43:56 +0100, John Poltorak wrote: >> I also tried to rebuild gettext-0.11.2 >> >> It worked (the non-masochistic way) after changing >> >> VERSION = $(shell sed ../configure.in -ne "/AM_INIT_AUTOMAKE/{" -e "s/.*(gettext, *\\(.*\\))/\\1/" -e "p" -e "}") >> to >> VERSION = 0.11.2 >> >> in os2/Makefile > > >Was this a required change? What do you mean? It was required to build for my environement. Perhaps with another incarnation of 'shell' or another 'sed' the original Makefile would have worked. >The latest libiconv is 1.8, which some people have used successfully. 0.1.0 is a wrapper for OS/2 unicode-API. It has nothing to do with the gnu version-numbering. But nevertheless I could try 1.8. Is there a compiled version of 1.8 somewhere available? >Not sure if this would be relevant but do you have several INTL.DLLs >around? not relevant >Maybe there is some conflict... Also, if you are using an old libiconv >there may be some incompatiblities with the new gettext.. No Regards, Franz **= Email 9 ==========================** Date: Thu, 4 Jul 2002 13:53:27 +0100 From: John Poltorak Subject: Re: Gettext / libiconv On Thu, Jul 04, 2002 at 01:53:51PM +0200, Franz Bakan wrote: > On Thu, 4 Jul 2002 11:31:45 +0100, John Poltorak wrote: > > >I always have problems trying to build gettext and end up with a number > >of strange directories in os2:- > > > >-p > >.exe > >0.11.2) > >emx > >out > > you won't have these strange directories after replacing > > VERSION = $(shell sed ../configure.in..... > with > VERSION = 0.11.2 Thanks, that works OK now. Any idea what is wrong with the original? Presumably it does work for some people. Maybe it depends on having a specific shell... I still only get as far as this stumbling block:- ********************************************************* *** YOU CAN SAFELY IGNORE WARNINGS FROM EMXBIND BELOW *** ********************************************************* gcc -Zmt -Zcrtdll -Zdll -s -o out/release/intl.dll out/release/intl/intl-compat.o out/release/intl/bindtextdom.o out/release/intl/dcgettext.o out/release/intl/dgettext.o out/release/intl/gettext.o out/release/intl/finddomain.o out/release/intl/loadmsgcat.o out/release/intl/localealias.o out/release/intl/textdomain.o out/release/intl/l10nflist.o out/release/intl/explodename.o out/release/intl/dcigettext.o out/release/intl/dcngettext.o out/release/intl/dngettext.o out/release/intl/ngettext.o out/release/intl/plural.o out/release/intl/plural-exp.o out/release/intl/localcharset.o out/release/intl/localename.o out/release/intl/osdep.o out/release/intl.def -liconv -liberty -lgcc emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 emxbind: gettext multiply exported (warning) emxbind: dgettext multiply exported (warning) emxbind: dcgettext multiply exported (warning) emxbind: textdomain multiply exported (warning) emxbind: bindtextdomain multiply exported (warning) emxbind: bindtextdomain__ multiply exported (warning) emxbind: dcgettext__ multiply exported (warning) emxbind: dgettext__ multiply exported (warning) emxbind: gettext__ multiply exported (warning) emxbind: _nl_msg_cat_cntr multiply exported (warning) emxbind: textdomain__ multiply exported (warning) C:\EMX\BIN\ld.exe: emxbind failed make: *** [out/release/intl.dll] Error 1 I don't know if gcc 3.0.3 is required for this to work This '_nl_msg_cat_cntr' msg has been haunting me for months. > >> >The latest libiconv is 1.8, which some people have used successfully. > >> > >> 0.1.0 is a wrapper for OS/2 unicode-API. It has nothing to do > >> with the gnu version-numbering. > > > >Do you have a URL for this? > > http://ais.gmd.de/~veit/os2/mailinglist4/7674.html That points to:- http://195.131.97.220:9000/zap/os2/iconv-0.1.0.zip which I am familiar with, but the archive appears incomplete. > Regards, > Franz -- John **= Email 10 ==========================** Date: Thu, 04 Jul 2002 13:53:51 +0200 (MSZ) From: "Franz Bakan" Subject: Re: Gettext / libiconv On Thu, 4 Jul 2002 11:31:45 +0100, John Poltorak wrote: >I always have problems trying to build gettext and end up with a number >of strange directories in os2:- > >-p >.exe >0.11.2) >emx >out you won't have these strange directories after replacing VERSION = $(shell sed ../configure.in..... with VERSION = 0.11.2 >> >The latest libiconv is 1.8, which some people have used successfully. >> >> 0.1.0 is a wrapper for OS/2 unicode-API. It has nothing to do >> with the gnu version-numbering. > >Do you have a URL for this? http://ais.gmd.de/~veit/os2/mailinglist4/7674.html Regards, Franz **= Email 11 ==========================** Date: Thu, 04 Jul 2002 15:36:49 +0200 (MSZ) From: "Franz Bakan" Subject: Re: Gettext / libiconv On Thu, 4 Jul 2002 13:53:27 +0100, John Poltorak wrote: >> with >> VERSION = 0.11.2 > >Thanks, that works OK now. > >Any idea what is wrong with the original? Presumably it does work for some >people. Maybe it depends on having a specific shell... no >emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 ... >This '_nl_msg_cat_cntr' msg has been haunting me for months. Why don't you try to use the new ld.exe and emxbind.exe as suggested in the readme ?? >http://195.131.97.220:9000/zap/os2/iconv-0.1.0.zip > >which I am familiar with, but the archive appears incomplete. It's complete, but you have to run make Regards, Franz **= Email 12 ==========================** Date: Thu, 4 Jul 2002 16:54:51 +0100 From: John Poltorak Subject: Re: Gettext / libiconv On Thu, Jul 04, 2002 at 03:36:49PM +0200, Franz Bakan wrote: > On Thu, 4 Jul 2002 13:53:27 +0100, John Poltorak wrote: > >emxbind: cannot export symbol _nl_msg_cat_cntr of type 9 > ... > >This '_nl_msg_cat_cntr' msg has been haunting me for months. > > Why don't you try to use the new ld.exe and emxbind.exe > as suggested in the readme ?? I had used these two programs at one point, but reverted back to the originals at some point when some unexpected errors occurred, but I just used them now and it does resolve the error abaove, but the fails here:- emxbind: textdomain__ multiply exported (warning) lxlite out/release/intl.dll make: $(COMSPEC): Shell program not found make: spawn: No such file or directory make: *** Deleting file `out/release/intl.dll' gcc -c -Wall -Zmt -I. -I../ -I../intl -I../src -I../lib -I../libuniname -DHAVE_CONFIG_H -DLIBDIR=\"/usr/lib\" -DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DGETTEXTDATADIR=\"/usr/share/gettext\" -DPROJECTSDIR=\"/usr/share/gettext/projects\" -DGETTEXTJAR=\"/usr/share/gettext/gettext.jar\" -s -O2 -o out/release/src/dir-list.o ../src/dir-list.c In file included from ../src/dir-list.c:26: ../src/dir-list.h:28: parse error before `PARAMS' ../src/dir-list.h:31: parse error before `PARAMS' In file included from ../src/dir-list.c:30: ../src/str-list.h:40: parse error before `PARAMS' ../src/str-list.h:43: parse error before `PARAMS' ../src/str-list.h:46: parse error before `PARAMS' ../src/str-list.h:50: parse error before `PARAMS' ../src/str-list.h:54: parse error before `PARAMS' ../src/str-list.h:57: parse error before `PARAMS' ../src/str-list.h:61: parse error before `PARAMS' ../src/str-list.h:65: parse error before `PARAMS' ../src/str-list.h:69: parse error before `PARAMS' ../src/str-list.h:72: parse error before `PARAMS' ../src/dir-list.c: In function `dir_list_append': ../src/dir-list.c:41: warning: implicit declaration of function `string_list_alloc' ../src/dir-list.c:41: warning: assignment makes pointer from integer without a cast ../src/dir-list.c:42: warning: implicit declaration of function `string_list_append_unique' make: *** [out/release/src/dir-list.o] Error 1 I have no idea why the $(COMSPEC) errors occurs. It is defined and valid. > >http://195.131.97.220:9000/zap/os2/iconv-0.1.0.zip > > > >which I am familiar with, but the archive appears incomplete. > > It's complete, but you have to run make Again, I have problems with $(COMSPEC) Which SHELL do you use? > Regards, > Franz > > -- John **= Email 13 ==========================** Date: Thu, 04 Jul 2002 19:35:31 +0200 (CEST) From: "Franz Bakan" Subject: Re: Gettext / libiconv On Thu, 4 Jul 2002 16:54:51 +0100, John Poltorak wrote: >In file included from ../src/dir-list.c:26: >../src/dir-list.h:28: parse error before `PARAMS' >../src/dir-list.h:31: parse error before `PARAMS' ... Now I'm not shure, It's possible that you have a corrupt os2/config.h created before applying the VERSION = ... change Try make clean and then again make 2 times. The other possibility is that perhaps some include-files are missing in your emx/include dirs that come with GCC 3.0.3 Did you install GCC 3.0.3? If not do this (but use GCC 2.8.1) for compiling gettext. Regards, Franz **= Email 14 ==========================** Date: Thu, 4 Jul 2002 19:39:46 +0100 From: John Poltorak Subject: Build GREP with new Autoconf I'm trying to build GREP 2.4.2 from the GNU source using the latest Autoconf, but can't get a new configure script built. README.OS2 from the GREP port mentions:- You may get an error message like ./aclocal.m4:470: error: m4_defn: undefined: _m4_divert_diversion acoldnames.m4:86: AM_PROG_INSTALL is expanded from... ./aclocal.m4:470: the top level If there is a file acinclude.m4 edit this file, otherwise edit aclocal.m4. Search for a line similar to "AC_DEFUN(AM_PROG_INSTALL,". Simply insert the line "undefine([AM_PROG_INSTALL])" before it and run autoconf again. so, I followed these instructions, only to get:- aclocal.m4:573: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/specific.m4:199: AC_SYS_LARGEFILE is expanded from... aclocal.m4:573: the top level WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. aclocal.m4:573: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/specific.m4:199: AC_SYS_LARGEFILE is expanded from... aclocal.m4:573: the top level autoheader: autom4te failed with exit status: 1 at c:/usr/local/bin/autoheader line 163 I can build GREP using the configure script supplied in the ported package, but can't get the hang of re-creating the configure script properly. Has anyone else tried/succeeded? -- John **= Email 15 ==========================** Date: Thu, 04 Jul 2002 19:40:45 -0800 From: "Dave and Natalie" Subject: Re: Wget build bug ? --_=_=_=IMA.BOUNDARY.GYR0FW138764=_=_=_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I didn't run autoconf and the build worked fine besides needing the > above patch. I'm trying to build every app using the same build framework which involves running autoconf and configure. Is this even possible given the changes that autoconf etc have gone thru? Debians solution is to include both versions and a simple means to change between them. This is due to some apps needing the older autoconf. > Dave > ps I do have a config.site (available on request) which seems to work with most configure scripts out of the box I'd like to have a look at it. Sure here it is. Change Paths as needed. Change or remove the -march=k2 flag. Its also possible that something in my config.sys helps. Most all configure scripts run fine here without autoconf Dave --_=_=_=IMA.BOUNDARY.GYR0FW138764=_=_=_ Content-Type: application/octet-stream; name="config.site" Content-Transfer-Encoding: base64 IyFzaA0KIyBjb25maWcuc2l0ZQ0KIyAgICAgICAgICBzZXQgIENPTkZJR19TSVRFPXg6L2Zvby9j b25maWcuc2l0ZQ0KDQpDT05GSUdfU0hFTEw9c2gNCmV4cG9ydCBDT05GSUdfU0hFTEwNCg0KIyBP cHRpbWl6YXRpb24gKEdOVSBtYWtlIDMuNzQgY2Fubm90IGJlIGxvYWRlZCA6LSgpOg0KZW14bG9h ZCAtbSAzMCBzaC5leGUgbHMuZXhlIHRyLmV4ZSBpZC5leGUgc2VkLmV4ZSAjIG1ha2UuZXhlDQpl bXhsb2FkIC1tIDMwIGdyZXAuZXhlIGVncmVwLmV4ZSBmZ3JlcC5leGUgY2F0LmV4ZSBybS5leGUg bXYuZXhlIGNwLmV4ZQ0KZW14bG9hZCAtbSAzMCB1bmlxLmV4ZSBiYXNlbmFtZS5leGUgc29ydC5l eGUgZ2F3ay5leGUNCg0KIyBhY19jdl9ob3N0PWkzODYtcGMtZW14DQpTSEVMTD1zaA0KUEFUSD1g Y21kLmV4ZSAvYyAiZWNobyAlUEFUSCUiIHwgc2VkIC1lICdzQFxcXFxAL0BnJ2ANCklOU1RBTEw9 YHR5cGUgaW5zdGFsbC5leGV8c2VkIC1lICdzQFxcXFxAL0BnJyAtZSAnc0AuKiBAQCdgDQphY19j dl9wYXRoX2luc3RhbGw9JHtJTlNUQUxMfQ0KTUFLRT1tYWtlDQpDQz1nY2MNCkNYWD1nY2MNCkFX Sz1nYXdrDQpMRVg9ZmxleA0KUkFOTElCPWVjaG8NCllBQ0M9J2Jpc29uIC15Jw0KVEFSPWU6XGVt eFxiaW5cdGFyLmV4ZQ0KQk1UWVBFPWludA0KQk1CWVRFUz00DQpQUklOVEFCTEVfT1NfTkFNRT1P Uy8yDQpDRkxBR1M9Jy1EX19FTVhfXyAtRE9TMiAtWm10ZCAtRF9fU1RfTVRfRVJSTk9fXyAgLU8y IC1mb21pdC1mcmFtZS1wb2ludGVyIC1tYXJjaD1rNiAtWmV4ZScNCkNYWEZMQUdTPSctRF9fRU1Y X18gLURPUzIgLVptdGQgLURfX1NUX01UX0VSUk5PX18gLU8yIC1mb21pdC1mcmFtZS1wb2ludGVy IC1tYXJjaD1rNicNCkxERkxBR1M9Jy1abXRkIC1EX19TVF9NVF9FUlJOT19fIC1PMiAtcyAtWnN5 c3Ytc2lnbmFscyAtWnN0YWNrIDUxMicNCmFjX2V4ZWV4dD0uZXhlDQphY19jdl9leGVleHQ9LmV4 ZQ0KYWNfY3ZfcGF0aF9fX0NIR1JQPWVjaG8NCmFjX2N2X3BhdGhfX19DSE9XTj1lY2hvDQphY19j dl9wYXRoX19fUlNIPWVjaG8NCg0KIyBteSBhZGRpdGlvbnMNCk00PWY6L3Vzci9iaW4vbTQuZXhl DQpJTlRMQklTT049ZTovZW14L2Jpbi9iaXNvbi5leGUNClBFUkw9ZTovZW14L2Jpbi9wZXJsLmV4 ZQ0KRVhQUj1mOi91c3IvYmluL2V4cHIuZXhlDQpTRUQ9ZjovdXNyL2Jpbi9zZWQuZXhlDQphY19l eGVjdXRhYmxlX2V4dGVuc2lvbnM9Ii5leGUiDQpHNzc9ZTpcZW14XGJpblxnNzcuZXhlDQpMRD1l OlxlbXhcYmluXGxkLmV4ZQ0KDQojIGZvciBzcGVlZCB1bmNvbW1lbnQgdGhpcw0KIyBDRkxBR1M9 Jy1EX19FTVhfXyAgLVptdGQgLURfX1NUX01UX0VSUk5PX18gIC1PMiAtRFJFQUxfSVNfRkxPQVQg LUROT1hGRVJNRU0gLURPUzIgLVdhbGwgLU8yIC1tNDg2IC1mb21pdC1mcmFtZS1wb2ludGVyIC1m dW5yb2xsLWFsbC1sb29wcyAtZmlubGluZS1mdW5jdGlvbnMgLWZmYXN0LW1hdGgnIA0KIyBleHBv cnQgQ0ZMQUdTDQoNCmZ1bmN0aW9uIHRlc3QNCnsNCiAgaWYgWyAgIiQxIiA9ICIteCIgXSA7IHRo ZW4NCiAgICBzaGlmdA0KICAgIGlmIFsgLWYgIiQxIiBdIDsgdGhlbiByZXR1cm4gOyBmaQ0KICAg IGlmIHR5cGUgJDEuY21kIDE+bnVsIDI+JjEgIDsgdGhlbiAgcmV0dXJuIDsgZmkNCiAgICBpZiB0 eXBlICQxLmV4ZSAxPm51bCAyPiYxICA7IHRoZW4gIHJldHVybiA7IGZpDQogICAgeD1gdHlwZSAk KiB8ICBzZWQgLWUgJ3NAXi4qIEBAJyAtZSAnc0BcXFxcQC9AZycgLWUgJ3NAXFwuJEBAJ2ANCiAg ICBncmVwICdeXCgjIVx8WyBcdF0qZXh0cHJvY1wpJyAkeCA+bnVsIDI+JjENCiAgZWxzZQ0KICAg IGJ1aWx0aW4gdGVzdCAiJEAiDQogIGZpIDtcDQp9DQojIyMgRU9GICMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyM= --_=_=_=IMA.BOUNDARY.GYR0FW138764=_=_=_-- **= Email 16 ==========================** Date: Thu, 04 Jul 2002 19:40:56 -0800 From: "Dave and Natalie" Subject: Re: Wget build bug ? On Wed, 3 Jul 2002 23:09:00 +0200 (CEST), Stefan Neis wrote: >On Wed, 3 Jul 2002, Dave and Natalie wrote: > >> Oh one other thing. Due to what looks like a bug in gcc 3.03 it won't build with gcc 3.03. >(snipp) >> This seems to be a bug where GCC 3.03 can't handle a source file that does nothing. > >Actually, that's common compiler behaviour, not something I'd call a bug. >I'd rather consider it a bug if a compiler accepts such things without >at least giving a warning. There almost certainly is something wrong >(such as a missing define or similar), if a source file compiles to >nothing at all... Well what if a sourcefile only compiles to something on some systems? eg #ifndef __EMX__ do lots of stuff #endif #else return Or in this case This file is NOT part of Wget, but is used by Wget on the systems where vsnprintf() is not defined. Also this compiles and links fine with all other versions of gcc. Dave ps with gcc 2.95.3 I get an object file of 93 bytes and with gcc 3.03 the object file is 32 bytes. The error is ld: failure reading string table size of snprintf.o **= Email 17 ==========================** Date: Thu, 4 Jul 2002 21:34:56 +0100 From: John Poltorak Subject: SED script Can someone explain how this SED script is supposed to work? :- VERSION = $(shell sed ../configure.in -ne "/AM_INIT_AUTOMAKE/{" -e "s/.*(gettext, *\\(.*\\))/\\1/" -e "p" -e "}") In particular, I don't understand the significance of '{' and '}'. I would guess that the file ../configure.in is searched for a line containing 'AM_INIT_AUTOMAKE' and this line is changed from:- AM_INIT_AUTOMAKE(gettext, 0.11.2) to:- 0.11.2 but I don't understand the steps involved, or why there are so many '-e's... In any case it doesn't seem to work correctly when building gettext. -- John **= Email 18 ==========================** Date: Thu, 4 Jul 2002 22:15:26 +0100 From: John Poltorak Subject: Re: GREP - LDFLAGS On Thu, Jul 04, 2002 at 10:16:05PM +0200, Andreas Buening wrote: > Sorry for the late response. The following commands are > missing (see INSTALL.OS2): > > mv m4/install.m4 m4/install.m4.old > mv m4/largefile.m4 m4/largefile.m4.old > touch m4/install.m4 > touch m4/largefile.m4 This is much more promising, I get a new configure script now. Does the same also apply to GNU textutils ? Unfortunately I get a few errors which are probably GETTEXT related:- make all-recursive make[1]: Entering directory `C:/unixos2/workdir/grep-2.4.2' Making all in intl make[2]: Entering directory `C:/unixos2/workdir/grep-2.4.2/intl' gcc -c -DLOCALEDIR=\"c:/usr/local/share/locale\" -DGNULOCALEDIR=\"c:/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"c:/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../intl -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ intl-compat.c ... gcc -c -DLOCALEDIR=\"c:/usr/local/share/locale\" -DGNULOCALEDIR=\"c:/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"c:/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../intl -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ explodename.c rm -f libintl.a emxomfar cru libintl.a intl-compat.o bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o l10nflist.o explodename.o emxomfar: libintl.a(intl-compat.o): No such file or directory make[2]: *** [libintl.a] Error 2 make[2]: Leaving directory `C:/unixos2/workdir/grep-2.4.2/intl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `C:/unixos2/workdir/grep-2.4.2' make: *** [all] Error 2 Making install in intl make[1]: Entering directory `C:/unixos2/workdir/grep-2.4.2/intl' gcc -c -DLOCALEDIR=\"c:/usr/local/share/locale\" -DGNULOCALEDIR=\"c:/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"c:/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../intl -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ intl-compat.c ... gcc -c -DLOCALEDIR=\"c:/usr/local/share/locale\" -DGNULOCALEDIR=\"c:/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"c:/usr/local/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I../intl -I../lib -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ explodename.c rm -f libintl.a ar cru libintl.a intl-compat.o bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o l10nflist.o explodename.o ar: intl-compat.o: No such file or directory make[1]: *** [libintl.a] Error 1 make[1]: Leaving directory `C:/unixos2/workdir/grep-2.4.2/intl' make: *** [install-recursive] Error 1 I'm not sure if this is related to *FLAGS or whether I have an incompatible libintl. I'm using these options:- CFLAGS = -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ LDFLAGS = -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio ./configure --without-included-regex --without-included-gettext make AR=emxomfar > > 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 19 ==========================** Date: Thu, 04 Jul 2002 22:16:05 +0200 From: Andreas Buening Subject: Re: GREP - LDFLAGS John Poltorak wrote: > [grep] > I just can't seem to create a usable configure script for GREP from the > GNU source. > > This is what I do once the original source has been extracted:- > > patch -p2 grep-patches > > mv m4/init.m4 m4/init.m4.old > touch m4/init.m4 > mv m4/header.m4 m4/header.m4.old > touch m4/header.m4 > cp -p $BUILDROOT/lib/progtest.m4 m4 > > cat m4/*.m4 > acinclude.m4 > aclocal -I m4 > automake > autoconf > autoheader [errors] Sorry for the late response. The following commands are missing (see INSTALL.OS2): mv m4/install.m4 m4/install.m4.old mv m4/largefile.m4 m4/largefile.m4.old touch m4/install.m4 touch m4/largefile.m4 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.