From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 3 Jul 2002 04:31:23 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 261 ************************************************** Tuesday 02 July 2002 Number 261 ************************************************** Subjects for today 1 Re: GREP - LDFLAGS : Andreas Buening 2 Re: Wget build bug ? : Dave and Natalie" 3 Re: BLDLEVEL info in SED : John Poltorak 4 Re: GREP - LDFLAGS : John Poltorak 5 Re: BLDLEVEL info in SED : csaba.raduly at sophos.com 6 Re: GREP - LDFLAGS : Stefan Neis 7 Re: Odd things happening in Makefile : Stefan Neis 8 Re: Wget build bug ? : John Poltorak 9 Re: libtool : John Poltorak 10 Re: GREP - LDFLAGS : Stefan Neis 11 Re: BLDLEVEL info in SED : Stefan Neis 12 Re: Wget build bug ? : Patrick Ash 13 Re: MOZTOOLS : Henry Sobotka 14 MOZTOOLS : John Poltorak 15 Re: GREP - LDFLAGS : Henry Sobotka 16 Re: libiconv : John Poltorak 17 Re: C/C++ compiling for those that do not know : John Poltorak 18 Re: MOZTOOLS : Jeff Robinson 19 Re: GREP - LDFLAGS : John Poltorak 20 Re: MOZTOOLS : John Poltorak 21 Re: GREP - LDFLAGS : John Poltorak 22 Re: Wget build bug ? : Stefan Neis 23 Re: GREP - LDFLAGS : Stefan Neis 24 Re: MOZTOOLS : Henry Sobotka **= Email 1 ==========================** Date: Wed, 03 Jul 2002 00:45:39 +0200 From: Andreas Buening Subject: Re: GREP - LDFLAGS John Poltorak wrote: > > Are these the correct LDFLAGS for a small, dynamically linked GREP? :- > > LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" > > This is mentioned in README.OS2, but INSTALL.OS2 adds '-Zmt -s' which I > suspect is not necessary. Yes, that's redundant. > Also, do I really need to run :- > > cat m4/* > acinclude.n4 > > as part of the build? cat m4/*.m4 > acinclude.m4 (That's a huge difference!) Please, don't ask me why. > init.m4 and header.m4 remain at 0 bytes. Is this correct? Yes, unless you want to fix Makefile.am. These files contained redundant, outdated and superfluous standard macros. You've just renamed the files yourself. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Redmond where the Shadows lie. **= Email 2 ==========================** Date: Wed, 03 Jul 2002 08:13:22 -0800 From: "Dave and Natalie" Subject: Re: Wget build bug ? On Tue, 02 Jul 2002 22:12:17 -0800, Dave and Natalie wrote: >Running >sh configure --prefix=/usr >make >works fine here. You do need to add this to src/utils.c >#ifdef __EMX__ >#define setsid() (0) >#endif Oh one other thing. Due to what looks like a bug in gcc 3.03 it won't build with gcc 3.03. ld: failure reading string table size of snprintf.o make[1]: *** [wget] Error 1 Directory of X:\usr\src\wget-1.8.2\src 7-03-02 7:56a 32 0 snprintf.o 1 file(s) 32 bytes used 0 bytes free Where as with pgcc2.95.3 Directory of X:\usr\src\wget-1.8.2\src 7-03-02 8:10a 93 0 snprintf.o 1 file(s) 93 bytes used 0 bytes free This seems to be a bug where GCC 3.03 can't handle a source file that does nothing. Dave **= Email 3 ==========================** Date: Wed, 3 Jul 2002 09:14:34 +0100 From: John Poltorak Subject: Re: BLDLEVEL info in SED On Tue, Jul 02, 2002 at 02:48:53PM +0100, csaba.raduly at sophos.com wrote: > > On 02/07/2002 09:36:02 owner-os2-unix wrote: > > >I would like to incorporate some BLDLEVEL info into SED.EXE. > > > >Can anyone tell me how to do it? > > > >I guess I need something like a SED.DEF which includes :- > > > > > >DESCRIPTION ' at #UX2:3.02.80.0# at REGEX -GNU Sed v3.02.80 for OS/2' > > > >How would I incorporate this into a compile? > > > > > > Just give the def file to the link step, like this: > (GNU Make syntax!) > > sed.exe : $(OBJS) sed.def > gcc $(CFLAGS) -o $ at $^ $(LIBRARIES) > > ld understands def files (at least the original EMX version does). > gcc doesn't, so it passes the def file to ld This doesn't exactly correspond, although it does have the desired effect:- sed$(EXEEXT): $(sed_OBJECTS) $(sed_DEPENDENCIES) at rm -f sed$(EXEEXT) $(LINK) $(sed_LDFLAGS) $(sed_OBJECTS) $(sed_LDADD) $(LIBS) sed.def I get the DESCRIPTION information included, but the executable won't run. That's probably because of the other line included in the DEF file. Are DEF files described anywhere? I don't really know what can go in them. -- John **= Email 4 ==========================** Date: Wed, 3 Jul 2002 09:38:58 +0100 From: John Poltorak Subject: Re: GREP - LDFLAGS On Wed, Jul 03, 2002 at 10:00:59AM +0200, Stefan Neis wrote: > On Wed, 3 Jul 2002, Andreas Buening wrote: > > > > Are these the correct LDFLAGS for a small, dynamically linked GREP? :- > > > > > > This is mentioned in README.OS2, but INSTALL.OS2 adds '-Zmt -s' which I > > > suspect is not necessary. > > > > Yes, that's redundant. > > Care to explain? at least "-s" for stripping debug information and symbol > names seems rather useful for obtaining small executables, doesn't it? There is an '-s' in CFLAGS. I guess it has the desired effect in creating OBJ files... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 5 ==========================** Date: Wed, 3 Jul 2002 09:57:46 +0100 From: csaba.raduly at sophos.com Subject: Re: BLDLEVEL info in SED On 03/07/2002 09:14:34 owner-os2-unix wrote: [snip] > >sed$(EXEEXT): $(sed_OBJECTS) $(sed_DEPENDENCIES) > at rm -f sed$(EXEEXT) >$(LINK) $(sed_LDFLAGS) $(sed_OBJECTS) $(sed_LDADD) $(LIBS) sed.def > You need to add sed.def to the dependency list (probably not $(sed_DEPENDENCIES), because those aren't supplied to the link command). > >I get the DESCRIPTION information included, but the executable won't run. >That's probably because of the other line included in the DEF file. > You need something like this: -------->8-------- NAME sed WINDOWCOMPAT NEWFILES <--- "NAME" says it's an EXE, not DLL DESCRIPTION ....the bldlevel stuff here.... PROTMODE STACKSIZE 49152 <---- example ! HEAPSIZE 0x4000 <---- example ! -------->8-------- GNU apps usually have a version number defined somewhere. If it's available for the makefile, you can generate the def file during build to always have the "right" version number. >Are DEF files described anywhere? I don't really know what can go in them. > If you have VisualAge 3.0x, open "VisaulAge User's Guide and Reference" Expand "Linking your program" and go to "Creating module definition files". -- 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 6 ==========================** Date: Wed, 3 Jul 2002 10:00:59 +0200 (CEST) From: Stefan Neis Subject: Re: GREP - LDFLAGS On Wed, 3 Jul 2002, Andreas Buening wrote: > > Are these the correct LDFLAGS for a small, dynamically linked GREP? :- > > > > This is mentioned in README.OS2, but INSTALL.OS2 adds '-Zmt -s' which I > > suspect is not necessary. > > Yes, that's redundant. Care to explain? at least "-s" for stripping debug information and symbol names seems rather useful for obtaining small executables, doesn't it? Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 7 ==========================** Date: Wed, 3 Jul 2002 10:11:44 +0200 (CEST) From: Stefan Neis Subject: Re: Odd things happening in Makefile On Mon, 1 Jul 2002, John Poltorak wrote: > $(srcdir)/stamp-vti: sed.texi $(top_srcdir)/configure.in > at (set `$(SHELL) $(srcdir)/mdate-sh $(srcdir)/sed.texi`; \ > echo " at set UPDATED $$1 $$2 $$3"; \ > echo " at set UPDATED-MONTH $$2 $$3"; \ > echo " at set EDITION $(VERSION)"; \ > echo " at set VERSION $(VERSION)") > vti.tmp > at cmp -s vti.tmp $(srcdir)/version.texi \ > || (echo "Updating $(srcdir)/version.texi"; \ > cp vti.tmp $(srcdir)/version.texi) > - at rm -f vti.tmp > at cp $(srcdir)/version.texi $ at > > Afterwards, the current environment, as output by SET, is prepended to > these lines. > > I'm sure this isn't supposed to occur. Can anyone see what is causing it? My usual wild guesses: It looks like `$(SHELL) $(srcdir)/mdate-sh $(srcdir)/sed.texi` is evaluated to something wrong, maybe empty, so the first line evaluates just to "set" which outputs the current environment... Maybe try to add at echo $(SHELL) at echo `$(SHELL) $(srcdir)/mdate-sh $(srcdir)/sed.texi` in front of that line to get an idea what's going on ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 8 ==========================** Date: Wed, 3 Jul 2002 10:17:18 +0100 From: John Poltorak Subject: Re: Wget build bug ? On Tue, Jul 02, 2002 at 10:12:17PM -0800, Dave and Natalie wrote: > On Mon, 1 Jul 2002 11:15:04 +0100, John Poltorak wrote: > > >Also, WGET is the only app where the check:- > > > >checking for a BSD-compatible install > > > >results in:- > > > >./install-sh -c > > > >everything else finds:- > > > >c:/usr/bin/install.exe -c > > > > > >Does anyone know why this happens? Why should WGET act differently to > >everything else? > > Running > sh configure --prefix=/usr > make > works fine here. You do need to add this to src/utils.c > #ifdef __EMX__ > #define setsid() (0) > #endif Can we get this incorported into the source? > I'd say your problems are coming from autoconf. Perhaps wget uses an older autoconf. It looks as though there are some bugs introduced through autoconf. Wonder if it would make any difference if aclocal.m4 was generated from aclocal > 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. > 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. > pps wget.exe seems to work fine -- John **= Email 9 ==========================** Date: Wed, 3 Jul 2002 10:27:37 +0100 From: John Poltorak Subject: Re: libtool On Tue, Jul 02, 2002 at 08:12:29PM -0800, Dave and Natalie wrote: > On Sat, 29 Jun 2002 10:31:28 +0100, John Poltorak wrote: > > > > > > >Has anyone managed to install the latest libtool? > > > >What did you need to do? How can you tell whether it is installed > >correctly? > > Do you need to build libtool? I don't know anything about libtool, I just grabbed it and when through the normal configure n' make routine. > I see it included in packages and configure always seems to anounce that > it created it. So is it something which developers include in there own apps? I assumed it was a standalone tool like autoconf and automake. > Libiconv builds dlls straight out of the box It won't here. > whereas gettext only builds static libraries even though both libtools > are version > X:\usr\src\libiconv-1.8>sh libtool --version > ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) > > Dave > -- John **= Email 10 ==========================** Date: Wed, 3 Jul 2002 10:56:48 +0200 (CEST) From: Stefan Neis Subject: Re: GREP - LDFLAGS On Wed, 3 Jul 2002, John Poltorak wrote: > There is an '-s' in CFLAGS. I guess it has the desired effect in creating > OBJ files... I see. But I'd rather suppose that "-s" is ignored in CFLAGS as it doesn't make sense to remove the symbolic function names from the individual object files - the linker wouldn't be able to resolve the dependencies any more. On the other hand, you now longer need them in the executable.... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 11 ==========================** Date: Wed, 3 Jul 2002 11:03:16 +0200 (CEST) From: Stefan Neis Subject: Re: BLDLEVEL info in SED On Wed, 3 Jul 2002, John Poltorak wrote: > > Are DEF files described anywhere? I don't really know what can go in them. Have a look at EMX documentation, emxdev.inf. Chapter 2.7 "Module definition files" should help. Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 12 ==========================** Date: Wed, 03 Jul 2002 11:47:48 +0000 From: Patrick Ash Subject: Re: Wget build bug ? On Wed, 03 Jul 2002 08:13:22 -0800, Dave and Natalie wrote: >>works fine here. You do need to add this to src/utils.c >>#ifdef __EMX__ >>#define setsid() (0) >>#endif > >Oh one other thing. Due to what looks like a bug in gcc 3.03 it won't build with gcc 3.03. >ld: failure reading string table size of snprintf.o >make[1]: *** [wget] Error 1 I built it with 3.0.3 here. No problems like this, but I get this same message (with a different .o file) when trying to build lynx 2.8.5 with gcc 3.0.3. Still haven't been able to track it down. >Directory of X:\usr\src\wget-1.8.2\src > > 7-03-02 7:56a 32 0 snprintf.o > 1 file(s) 32 bytes used > 0 bytes free > >Where as with pgcc2.95.3 >Directory of X:\usr\src\wget-1.8.2\src > > 7-03-02 8:10a 93 0 snprintf.o > 1 file(s) 93 bytes used > 0 bytes free > >This seems to be a bug where GCC 3.03 can't handle a source file that does nothing. 7-03-02 5:34a 131 0 snprintf.o 1 file(s) 131 bytes used 13318888 K bytes free Not sure what this all means. Pat -- Patrick Ash patash at comcast.net This OS/2 system uptime is 26 days, 04:29 hours and 32 seconds **= Email 13 ==========================** Date: Wed, 03 Jul 2002 12:00:50 -0400 From: Henry Sobotka Subject: Re: MOZTOOLS John Poltorak wrote: > > Has anyone come across MOZTOOLS? > > It seems to be another package of Unix tools - this time specifically for > building Mozilla. > > How does it differ from GNUPACK? Probably in that the versions are older and they're just the utilities you need for Mozilla. The list for OS/2 is on http://www.mozilla.org/ports/os2/setup.html. No idea what's in GNUPACK or MOZTOOL packages for other platforms. > I can't help feeling that we have another incompatible set of tools which > won't necessarily work with everything else. They exist because 98% of the problems people have building Mozilla (on OS/2 at least) are tool-related, i.e. something missing, "wrong" version (i.e. behaves differently from what the build system expects), not properly installed etc. They're not intended to work with anything else, but generally do unless a newer version of a particular tool is required, and that newer version may or may not work with Mozilla. Also, Mozilla tries to be buildable on as many platforms as possible, and so tends towards a lowest-common-denominator approach to tools rather than forcing upgrades every time a new version of a particular tool is released. h~ **= Email 14 ==========================** Date: Wed, 3 Jul 2002 15:03:59 +0100 From: John Poltorak Subject: MOZTOOLS Has anyone come across MOZTOOLS? It seems to be another package of Unix tools - this time specifically for building Mozilla. How does it differ from GNUPACK? I can't help feeling that we have another incompatible set of tools which won't necessarily work with everything else. -- John **= Email 15 ==========================** Date: Wed, 03 Jul 2002 16:15:02 -0400 From: Henry Sobotka Subject: Re: GREP - LDFLAGS John Poltorak wrote: > > 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... > > Any hints would be appreciated? Have you looked at the error output in config.log? h~ **= Email 16 ==========================** Date: Wed, 3 Jul 2002 16:34:48 +0100 From: John Poltorak Subject: Re: libiconv On Tue, Jul 02, 2002 at 08:30:10PM -0800, Dave and Natalie wrote: > On Sat, 29 Jun 2002 10:59:16 +0100, John Poltorak wrote: > > > > >If anyone has managed to build and install libiconv, can you give me some > >instructions and as well as a list of prerequisites such as software, > >headers, libs etc? > > For me it build just with > sh configure --prefix=/usr > make > make install I just tried it without autoconf and it seemed to work OK, although I did get some errors with the supplied mkinstalldirs so I replaced it with another one, but I'm not sure which files should actually get installed. Is there a list anywhere? > This is using my config.site script which I'll gladly send you if you'd like to try it. > As far as I can see this is just using standard headers, libs etc though there must be a difference in our build enviroments as you can build perl and I can't, I can build gettext and you can't > Makefile.os2 in the test subdirectory needs to be adjusted to run the tests which I haven't had time to do. > Dave > ps gcc ver 3.03 newest make newest ksh I have left gcc 3.0.3 for the time being as I have what appears to be an unsurmountable problem building Perl. Since I can't build Perl, I thought I would stick with 2.8.1 to build everything for the time being. -- John **= Email 17 ==========================** Date: Wed, 3 Jul 2002 17:02:18 +0100 From: John Poltorak Subject: Re: C/C++ compiling for those that do not know On Tue, Jul 02, 2002 at 10:30:43AM -0300, spigol wrote: > I was thinking here. How about build some minicourses/howtos > for those that do not know how to compile C/C++ in OS/2? This would probably be a good idea, however, not for the reasons you suggest... > With this knowledge would be possible get anything for > Unix/Linux & only compile it. I like command line tools. > Would be very interesting compile my own CLI tools. No knowledge of C/C++ is required for compiling CLI tools. The are usually built by running 'configure and make', and I doubt whether you want to develop your own tools from scratch. The problem on OS/2 is generally related to getting the correct build environment set up in the first place. One of the things I'm attempting to do is devise a build framework which will eventually define the standard toolset. At the moment there is no such thing, just hotch-potch of apps which various people use in different combinations, each combination of which is unique and more than likely incompatible with everyone else's to a greater or lesser degree. That's why so many of us have difficulty being able to reproduce someone else's results. But things are getting better, and I'd like to think a proper set will be in place within a few weeks. > Rodrigo Cesar -- John **= Email 18 ==========================** Date: Wed, 03 Jul 2002 20:43:30 -0500 From: Jeff Robinson Subject: Re: MOZTOOLS John Poltorak wrote: > On Wed, Jul 03, 2002 at 12:00:50PM -0400, Henry Sobotka wrote: > >>John Poltorak wrote: >> >>>Has anyone come across MOZTOOLS? >>> >>>It seems to be another package of Unix tools - this time specifically for >>>building Mozilla. >>> >>>How does it differ from GNUPACK? >> >>Probably in that the versions are older and they're just the utilities >>you need for Mozilla. The list for OS/2 is on >>http://www.mozilla.org/ports/os2/setup.html. No idea what's in GNUPACK >>or MOZTOOL packages for other platforms. > > > > I've just compared MOZTOOLS with GNUPACK and it is an almost complete > subset with a couple of minor differences along with the addition of > something called NSINSTALL.EXE which I guess must be related to > Netscape... > > >>>I can't help feeling that we have another incompatible set of tools which >>>won't necessarily work with everything else. >> >>They exist because 98% of the problems people have building Mozilla (on >>OS/2 at least) are tool-related, i.e. something missing, "wrong" version >>(i.e. behaves differently from what the build system expects), not >>properly installed etc. They're not intended to work with anything else, >>but generally do unless a newer version of a particular tool is >>required, and that newer version may or may not work with Mozilla. Also, >>Mozilla tries to be buildable on as many platforms as possible, and so >>tends towards a lowest-common-denominator approach to tools rather than >>forcing upgrades every time a new version of a particular tool is >>released. > > > I can see the value in having a handy collection of tools in a single > package, but having two very similar packages is sure to create some > confusion. > > >>h~ > > > Hi John, Certainly my intention of creating the MozTools package wasn't to try and complicate the issue any more than perhaps it already is. And this is one thing that folks who have tried to build Mozilla can attest to, that there are a *lot* of different versions of the GNU tools floating around and not all of them will work properly to build the browser. One of the instances that comes to mind is the various versions of 'pwd' out there; one returns the path such as /foo/bar where the other one includes the drive letter c:/foo/bar. One will build Mozilla, and the other breaks the build. Inadvertantly installing entire GNU packages that exist on hobbes can overwrite one version of the "proper" tool with the "wrong" one, as some archives double-up on existing tools. 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 ). 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. 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. 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. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 19 ==========================** Date: Wed, 3 Jul 2002 20:58:17 +0100 From: John Poltorak Subject: Re: GREP - LDFLAGS On Wed, Jul 03, 2002 at 12:45:39AM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > > Are these the correct LDFLAGS for a small, dynamically linked GREP? :- > > > > LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" > > > > This is mentioned in README.OS2, but INSTALL.OS2 adds '-Zmt -s' which I > > suspect is not necessary. > > Yes, that's redundant. > > > > Also, do I really need to run :- > > > > cat m4/* > acinclude.n4 > > > > as part of the build? > > cat m4/*.m4 > acinclude.m4 (That's a huge difference!) > Please, don't ask me why. That was actually typo on my part. 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 This is accoding to your last instructions along with the docs in your GREP port, but it looks as though something has been missed out. Here's a log of what happens:- patching file configure.in patching file m4/progtest.m4 patching file m4/regex.m4 patching file src/grep.c patching file src/system.h aclocal.m4:417: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/oldnames.m4:113: AM_PROG_INSTALL is expanded from... aclocal.m4:417: 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:417: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/oldnames.m4:113: AM_PROG_INSTALL is expanded from... aclocal.m4:417: the top level autoheader: autom4te failed with exit status: 1 at c:/usr/local/bin/autoheader line 163 ./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 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... Any hints would be appreciated? > > 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 20 ==========================** Date: Wed, 3 Jul 2002 21:39:34 +0100 From: John Poltorak Subject: Re: MOZTOOLS On Wed, Jul 03, 2002 at 12:00:50PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > Has anyone come across MOZTOOLS? > > > > It seems to be another package of Unix tools - this time specifically for > > building Mozilla. > > > > How does it differ from GNUPACK? > > Probably in that the versions are older and they're just the utilities > you need for Mozilla. The list for OS/2 is on > http://www.mozilla.org/ports/os2/setup.html. No idea what's in GNUPACK > or MOZTOOL packages for other platforms. I've just compared MOZTOOLS with GNUPACK and it is an almost complete subset with a couple of minor differences along with the addition of something called NSINSTALL.EXE which I guess must be related to Netscape... > > I can't help feeling that we have another incompatible set of tools which > > won't necessarily work with everything else. > > They exist because 98% of the problems people have building Mozilla (on > OS/2 at least) are tool-related, i.e. something missing, "wrong" version > (i.e. behaves differently from what the build system expects), not > properly installed etc. They're not intended to work with anything else, > but generally do unless a newer version of a particular tool is > required, and that newer version may or may not work with Mozilla. Also, > Mozilla tries to be buildable on as many platforms as possible, and so > tends towards a lowest-common-denominator approach to tools rather than > forcing upgrades every time a new version of a particular tool is > released. I can see the value in having a handy collection of tools in a single package, but having two very similar packages is sure to create some confusion. > > h~ -- John **= Email 21 ==========================** Date: Wed, 3 Jul 2002 21:52:08 +0100 From: John Poltorak Subject: Re: GREP - LDFLAGS On Wed, Jul 03, 2002 at 04:15:02PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > 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... > > > > Any hints would be appreciated? > > Have you looked at the error output in config.log? There's something messed up in the creation of configure... My usual config.logs have a very standard format at the begining such as this for SED:- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.53. Invocation command line was $ configure --with-regex=-lregex ## --------- ## ## Platform. ## ## --------- ## hostname = tp600 uname -m = i386 uname -r = 2 uname -s = OS/2 uname -v = 2.45 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: c:/usr/bin PATH: c:/emx/bin PATH: c:/usr/local/bin PATH: c:/os2 PATH: . But the one for GREP consists of this:- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:577: checking for a BSD compatible install configure:630: checking whether build environment is sane configure:687: checking whether make sets ${MAKE} configure:733: checking for working aclocal configure:746: checking for working autoconf configure:759: checking for working automake configure:772: checking for working autoheader configure:785: checking for working makeinfo configure:809: checking host system type configure:834: checking for mawk configure:866: checking for gcc configure:979: checking whether the C compiler (gcc -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio) works configure:995: gcc -o conftest -Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio conftest.c 1>&5 configure: failed program was: #line 990 "configure" #include "confdefs.h" main(){return(0);} > h~ -- John **= Email 22 ==========================** Date: Wed, 3 Jul 2002 23:09:00 +0200 (CEST) From: Stefan Neis Subject: Re: Wget build bug ? 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... Regards, Stefan **= Email 23 ==========================** Date: Wed, 3 Jul 2002 23:15:11 +0200 (CEST) From: Stefan Neis Subject: Re: GREP - LDFLAGS 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). Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 24 ==========================** Date: Wed, 03 Jul 2002 23:18:01 -0400 From: Henry Sobotka Subject: Re: MOZTOOLS John Poltorak wrote: > > I've just compared MOZTOOLS with GNUPACK and it is an almost complete > subset with a couple of minor differences along with the addition of > something called NSINSTALL.EXE which I guess must be related to > Netscape... Yes, nsinstall is one of the first things that get built and then used to copy (on OS/2 and Win32) or symlink headers, libraries and executables to the /dist tree. It's essentially a BSD-compatible install, so I have a copy of it in my path and INSTALL set to it to keep autoconf tests happy. > I can see the value in having a handy collection of tools in a single > package, but having two very similar packages is sure to create some > confusion. gnupack may very well work out-of-the-box as a replacement for moztools, but human nature being what it is, someone will invariably start bitching about having to download all the extra stuff in gnupack that doesn't get used, at which point if moztools no longer exists, someone will (re)create it. If anything's confusing, it's not moztools, whose purpose is very clear and specific, but rather gnupack: is it a collection of the latest version of each tool it contains? Is there a new gnupack every time a tool comes up with a new release? Also, if a project build is suddenly broken after installing gnupack, it could be much harder to track down which tool or tools are to blame, Same principle as not installing a slew of drivers at once so that you don't end up having to figure out which one is causing the boot lockup or some other problem. h~