From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 12 Jun 2002 04:27:39 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 240 ************************************************** Tuesday 11 June 2002 Number 240 ************************************************** Subjects for today 1 Re: Everything is broken! : Ken Ames 2 Re: library numbers : Steve Wendt" 3 Re: Everything is broken! : James Cannon 4 Re: Everything is broken! : Mentore Siesto 5 Re: library numbers : Mentore Siesto 6 Re: Everything is broken! : John Poltorak 7 Re: Everything is broken! : John Poltorak 8 Re: Wrong compiler flags : Henry Sobotka 9 Re: Wrong compiler flags : Henry Sobotka 10 Re: Everything is broken! : Stefan Neis 11 Re: Everything is broken! : Stefan Neis 12 Re: Everything is broken! : John Poltorak 13 Re: Wrong compiler flags : Henry Sobotka 14 Re: Everything is broken! : John Poltorak 15 libtool and -version-info : paul-biz" 16 Wrong compiler flags : John Poltorak 17 Re: Wrong compiler flags : John Poltorak 18 Re: libtool and -version-info : Henry Sobotka **= Email 1 ==========================** Date: Wed, 12 Jun 2002 00:11:59 -0400 (EDT) From: Ken Ames Subject: Re: Everything is broken! <-SNIP-> hi guys, I for one was hoping that would be the primary goal. Getting a developement env that is broad and stable should be the first priority. I hope Dr. Veit is about ready to release his lib soon. we need it as bad as a standard gcc. Ken > >John could you come up with a guideline? I would think everything should >be ported using UnixOS/2's dependancies as a guideline. Seems everyone >has a favorite library. If you use the ports from os2.ru you need their >dll's. Zlib, tiff, gtk/glib, and png are good examples for gui apps. >There's HU's, UnixOS2, Warpzilla, etc. Graphic libs and what development >environment like EMX 0.9D or PGCC with 2.95 dll's should be recommended. >I think EMX runtimes should be for old ports and legacy apps only. >Everything now should depend on 2.95.3 or newer. We should draw the line >now. We need a standard now that everyone, Warpzilla etc. follows. Maybe >getting together with Henry is a good idea too. > >-- >Ted Sikora >tsikora at unixos2.com >http://unixos2.com > **= Email 2 ==========================** Date: Wed, 12 Jun 2002 01:44:49 -0700 (PDT) From: "Steve Wendt" Subject: Re: library numbers On Wed, 12 Jun 2002 10:52:28 +0200 (CEST), Mentore Siesto wrote: >TS >We should implement a numbering convention either like the Linux >TS >libz.so.1.1.4 or FreeBSD aka libz.so.4 That way we can still use >TS >multiple libraries and not resort to patchwork like renaming them. > >Do you mean numbering the library files or the compressed packages? >If we number the library files, how can a program refer to the correct >library without rewriting it? Where is that nice symlink hack when we need it? ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 3 ==========================** Date: Wed, 12 Jun 2002 07:30:30 -0700 (PDT) From: James Cannon Subject: Re: Everything is broken! --- Ken Ames wrote: > <-SNIP-> > > hi guys, > I for one was hoping that would be the primary > goal. Getting a developement env that > is broad and stable should be the first priority. I > hope Dr. Veit is about ready to release > his lib soon. we need it as bad as a standard gcc. > > Ken > Excellent. I would like to see that. Maybe on the front page (or a link there) have a HOWTO on setting up and configuring. It could even be a tutorial. Then, as updates occur, it could be blog-like or updated. Have one idea in one location would suit me. It needs to be done by the visionary, perhaps the one who started this. Build it and they will come. ===== Sincerely, James Cannon Using OS/2 Warp in the beautiful Wine Country of Northern California! __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com **= Email 4 ==========================** Date: Wed, 12 Jun 2002 10:46:55 +0200 (CEST) From: Mentore Siesto Subject: Re: Everything is broken! On Tue, 11 Jun 2002, Ted Sikora wrote: TS >Andreas Buening wrote: TS >> TS >> John Poltorak wrote: TS >> > TS >> > On Tue, Jun 11, 2002 at 12:27:22PM +0400, Andrew Zabolotny wrote: TS >> > > On Mon, 10 Jun 2002 19:32:01 -0400, Ted Sikora wrote: TS >> > > TS >> > > >Beat you to it.... got it working. We *have* to standardize everything. TS >> > > >What a mess! No wonder everyone runs from OS/2. TS >> > > >Anyone with sense or no ambition. TS >> > > Exactly. When I've rised this question about half of year ago, nobody listened. TS >> > > I believe nobody will do it this time as well. TS >> > TS >> > Erm... I've been trying to get everything standardised for a long time. TS >> > That was one of the main aims of this list. It is hard going, but I think TS >> > we have made some progress. We have had quite a lot of updated programs TS >> > including your gcc updates which are great to have, but one of the TS >> > problems is that every developer still insists on using his own toolset TS >> > which often results in no one else being able to rebuild a particular app, TS >> > or even if it is rebuild it is not possible to provide precise TS >> > instructions because there may be some depedency on an obsure version of TS >> > make or a very specific shell which needs to be used. TS >> TS >> You seem to be the main package distributor. Then _define_ TS >> how packages have to be build before they can be included TS >> into UO/2. You will never get an agreement on this list TS >> (or whereever) which tools to use. Consider a solution TS >> that is as simple as possible and as complex as necessary TS >> to maximize flexibility and minimize effort for maintaining TS >> and then make a decision. Put it onto a web page so that TS >> everybody can read it every day without producing endless TS >> threads. Either enough people will follow you or there TS >> will never be a real organized UO/2 release. TS > TS >John could you come up with a guideline? I would think everything should TS >be ported using UnixOS/2's dependancies as a guideline. Seems everyone TS >has a favorite library. If you use the ports from os2.ru you need their TS >dll's. Zlib, tiff, gtk/glib, and png are good examples for gui apps. I agree. TS >There's HU's, UnixOS2, Warpzilla, etc. Graphic libs and what development TS >environment like EMX 0.9D or PGCC with 2.95 dll's should be recommended. What about GCC 3.03? Is it still too young? TS >I think EMX runtimes should be for old ports and legacy apps only. Agree on this... Libemu? -- Mentore Siesto Team OS/2 Italy **= Email 5 ==========================** Date: Wed, 12 Jun 2002 10:52:28 +0200 (CEST) From: Mentore Siesto Subject: Re: library numbers On Tue, 11 Jun 2002, Ted Sikora wrote: TS >We should implement a numbering convention either like the Linux TS >libz.so.1.1.4 or FreeBSD aka libz.so.4 That way we can still use TS >multiple libraries and not resort to patchwork like renaming them. Do you mean numbering the library files or the compressed packages? If we number the library files, how can a program refer to the correct library without rewriting it? Bye, -- Mentore Siesto Team OS/2 Italy **= Email 6 ==========================** Date: Wed, 12 Jun 2002 10:54:48 +0100 From: John Poltorak Subject: Re: Everything is broken! On Tue, Jun 11, 2002 at 10:56:29PM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > > On Tue, Jun 11, 2002 at 12:27:22PM +0400, Andrew Zabolotny wrote: > > > On Mon, 10 Jun 2002 19:32:01 -0400, Ted Sikora wrote: > > > > > > >Beat you to it.... got it working. We *have* to standardize everything. > > > >What a mess! No wonder everyone runs from OS/2. > > > >Anyone with sense or no ambition. > > > Exactly. When I've rised this question about half of year ago, nobody listened. > > > I believe nobody will do it this time as well. > > > > Erm... I've been trying to get everything standardised for a long time. > > That was one of the main aims of this list. It is hard going, but I think > > we have made some progress. We have had quite a lot of updated programs > > including your gcc updates which are great to have, but one of the > > problems is that every developer still insists on using his own toolset > > which often results in no one else being able to rebuild a particular app, > > or even if it is rebuild it is not possible to provide precise > > instructions because there may be some depedency on an obsure version of > > make or a very specific shell which needs to be used. > > You seem to be the main package distributor. Then _define_ > how packages have to be build before they can be included > into UO/2. You will never get an agreement on this list > (or whereever) which tools to use. Consider a solution > that is as simple as possible and as complex as necessary > to maximize flexibility and minimize effort for maintaining > and then make a decision. Put it onto a web page so that > everybody can read it every day without producing endless > threads. Either enough people will follow you or there > will never be a real organized UO/2 release. I would like to develop build scripts for every package so that packages can be built very easily, but I don't think we are in a position to do this until the basic standard toolset is available. I'd suggest the toolset consists of gcc, Perl, autoconf, automake, m4 gnufu, gnushu, gnutu, sed, grep, awk, make, tar, gzip, patch, pdksh, bash and maybe one or two others along with a package of standard headers and libs, and DLLs. Much of this is already in place in one form or another, but it isn't quite cohesive. I can't manage to build any of these apps myself at the moment unless I use multiple versions of autoconf, gcc, sh etc. Is it possible to build something like m4 with the latest standard autoconf for example? I can't. I'm not really sure how to make any progress either... > > bye, > Andreas > > -- -- John **= Email 7 ==========================** Date: Wed, 12 Jun 2002 12:17:59 +0100 From: John Poltorak Subject: Re: Everything is broken! On Wed, Jun 12, 2002 at 10:46:55AM +0200, Mentore Siesto wrote: > On Tue, 11 Jun 2002, Ted Sikora wrote: > > TS >There's HU's, UnixOS2, Warpzilla, etc. Graphic libs and what development > TS >environment like EMX 0.9D or PGCC with 2.95 dll's should be recommended. > > What about GCC 3.03? Is it still too young? I'm still using gcc 2.8.1 and would like to move to v3.0.3 since I'd prefer skipping pgcc 2.95, but I have some problems with it, and there are some reports about the code it produces not being as good as older versions. This relates to gcc itself rather than the OS/2 port, BTW. I don't know if those issues have been addressed in v3.1.0 or whether we can expect an OS/2 port of that some time... > -- > Mentore Siesto > Team OS/2 Italy > -- John **= Email 8 ==========================** Date: Wed, 12 Jun 2002 16:54:59 -0400 From: Henry Sobotka Subject: Re: Wrong compiler flags John Poltorak wrote: > > on the new system the programs get compiled as *.o instead of *.obj... > > Could this be due to the use of gcc 3.0.3 instead of 2.8.1 ? Yes. > If so, what can I do about it? Add "-o $ at " to the rules for blocksort.obj, huffman.obj etc. or create an O_SUFFIX variable, set it to "o" and replace all occurrences of "obj" with $(O_SUFFIX). h~ **= Email 9 ==========================** Date: Wed, 12 Jun 2002 17:43:25 -0400 From: Henry Sobotka Subject: Re: Wrong compiler flags John Poltorak wrote: > > Does this mean different Makefiles for gcc 2.8.1 and 3.0.3? Not if you do both things I suggested; that'll keep pre-3.x gcc from spitting out *.obj files by default with -Zomf. > Sounds like a real minefield for anyone wanting to migrate to 3.0.3... Except Andy's documentation clearly maps all the known mines. h~ **= Email 10 ==========================** Date: Wed, 12 Jun 2002 17:44:25 +0200 (CEST) From: Stefan Neis Subject: Re: Everything is broken! On Tue, 11 Jun 2002, Ted Sikora wrote: > Everything now should depend on 2.95.3 or newer. I'd rather make that gcc-3.0.3 or newer. With the change in name mangling scheme, any C++ code compiled with gcc-3 or newer is incompatible with any older stuff (and vice versa), so do the switch with introducing UnixOS/2 to avoid having to draw a new line "real soon" again. Even though gcc-3.0.x has some deficiencies, those should be fixed over time und upgrading gcc to gcc-3.1.x or even gcc-3.2.x when they come into existance shouldn't be much of a problem, whereas the step from gcc-2.x to gcc-3.x definitely is a problem. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 11 ==========================** Date: Wed, 12 Jun 2002 18:00:37 +0200 (CEST) From: Stefan Neis Subject: Re: Everything is broken! On Wed, 12 Jun 2002, John Poltorak wrote: > Is it possible to build something like m4 with the latest standard > autoconf for example? I can't. I'm not sure it's currently possible even on Linux ... > I'm not really sure how to make any progress either... There are some problems with the bunch of new not really backward compatible versions of existing software where I don't think it's UnixOS2's task to solve them. Wait for other people to solve them for Unix first... If we have some binaries which can't be built with the current toolset then so be it. Preferably tell people that they might need to downgrade autoconf to be able to build m4, but even if you don't it should be clear by the file dates in the source code, that m4 might require an older version. This kind of problem should be solved at some time by e.g. an updated m4 release. There is a reason, why Linux people are currently typically distributing both old and new autoconf. :-( There also are reasons why they are distributing two gcc versions (kernel code making use of version specific bugs/features, backward compatibility of C++ shared objects), but at least those don't apply for us... ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 12 ==========================** Date: Wed, 12 Jun 2002 19:42:17 +0100 From: John Poltorak Subject: Re: Everything is broken! On Wed, Jun 12, 2002 at 06:00:37PM +0200, Stefan Neis wrote: > On Wed, 12 Jun 2002, John Poltorak wrote: > > > Is it possible to build something like m4 with the latest standard > > autoconf for example? I can't. > > I'm not sure it's currently possible even on Linux ... > > > I'm not really sure how to make any progress either... > > There are some problems with the bunch of new not really backward > compatible versions of existing software where I don't think it's > UnixOS2's task to solve them. Wait for other people to solve them for > Unix first... > > If we have some binaries which can't be built with the current toolset > then so be it. Preferably tell people that they might need to downgrade > autoconf to be able to build m4, but even if you don't it should be clear > by the file dates in the source code, that m4 might require an older > version. This kind of problem should be solved at some time by e.g. an > updated m4 release. M4 hasn't been updated for a very long time. What I'd like to have is an updated autoconf which will build it. The OS/2 port of v2.50 worked, but the newer version which incorporates a number of the OS/2 features doesn't. I'm not sure why and I don't know if it is something simple which just needs a little tweaking... Maybe it does work for some people. > There is a reason, why Linux people are currently typically distributing > both old and new autoconf. :-( > There also are reasons why they are distributing two gcc versions (kernel > code making use of version specific bugs/features, backward compatibility > of C++ shared objects), but at least those don't apply for us... ;-) I'm sure the Linux people are creating a quagmire for themselves. At least we don't need to concern ourselves with a kernel hacking toolset in addition to a standard development toolset. > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 13 ==========================** Date: Wed, 12 Jun 2002 19:52:08 -0400 From: Henry Sobotka Subject: Re: Wrong compiler flags Andreas Buening wrote: > > But what was the reason for this change? I see no real > reason for this. Getting .obj files when using -Zomf has > been a well documented (and also widely used) behaviour > for years. If anybody really really needs .o files why not > add a -Zsuffix=o option? This wouldn't have broken a lot of > Makefiles. How should a program (like libtool, for example) > find out, whether it has to start ar or emxomfar or whether > it needs a .lib or a .a import library for that dll? > With the old distinction .obj <-> .lib and .o <-> .a this > was no problem. IIRC what Andy said a few months ago, changes in the gcc code made that feature not worth the effort of maintaining, particularly in relation to other priorities (e.g. weak symbols, ELF etc.) The important thing is that -Zomf still produces OMF, not the extension which in most cases can easily be manipulated in a makefile. Since the -Zomf flag is still intact, why it can't serve as the switch for libtool and the like? h~ **= Email 14 ==========================** Date: Wed, 12 Jun 2002 20:16:50 +0100 From: John Poltorak Subject: Re: Everything is broken! On Wed, Jun 12, 2002 at 12:11:59AM -0400, Ken Ames wrote: > <-SNIP-> > > hi guys, > I for one was hoping that would be the primary goal. Getting a developement env that > is broad and stable should be the first priority. I hope Dr. Veit is about ready to release > his lib soon. we need it as bad as a standard gcc. We need a standard toolset so that behaviour is predictable and results reproducible by others. There are many different versions of Make around. The same goes for SHELLs in use as well as common DLLs such as REGEX and INTL. I tried to establish a standard INTL.DLL based on GETTEXT v0.10.38, but couldn't get one built after that, so it is out of date. Some apps need to be rebuilt to use the standard INTL.DLL rather than a specific version. Having said that we are much closer to having a standard toolset with common DLLs through the sterling efforts of Andreas Buening among others. Now, if only everyone can start using his latest port of Make v3.79.1, we will be an important step nearer a standard development environment. I really thing we need to get the basic infrastucture right before libemu comes along. > Ken > > > > >John could you come up with a guideline? I would think everything should > >be ported using UnixOS/2's dependancies as a guideline. Seems everyone > >has a favorite library. If you use the ports from os2.ru you need their > >dll's. Zlib, tiff, gtk/glib, and png are good examples for gui apps. > >There's HU's, UnixOS2, Warpzilla, etc. Graphic libs and what development > >environment like EMX 0.9D or PGCC with 2.95 dll's should be recommended. > >I think EMX runtimes should be for old ports and legacy apps only. > >Everything now should depend on 2.95.3 or newer. We should draw the line > >now. We need a standard now that everyone, Warpzilla etc. follows. Maybe > >getting together with Henry is a good idea too. > > > >-- > >Ted Sikora > >tsikora at unixos2.com > >http://unixos2.com > > > > -- John **= Email 15 ==========================** Date: Wed, 12 Jun 2002 20:50:13 -0500 (CDT) From: "paul-biz" Subject: libtool and -version-info Hi, I get this error all the time when trying to configure & make stuff. It's trying to set a version number from libtool and it never likes it... If I remove it, everything "seems" to be OK, but I'd like to find out if it's just me or if it's normal... In this case I'm using GCC 3.0.3 example of error: libtool: link: CURRENT `0:28:0' is not a nonnegative integer libtool: link: `0:28:0' is not valid version information Thanks, Paul **= Email 16 ==========================** Date: Wed, 12 Jun 2002 21:18:01 +0100 From: John Poltorak Subject: Wrong compiler flags I have just copied my developement environment to a new machine and in the process of running a test build of BZIP2 it fails because of the wrong compile options. I'm using the same Makefile:- SHELL=sh # To assist in cross-compiling CC=gcc AR=emxomfar LDFLAGS=-s -Zomf # Suitably paranoid flags to avoid bugs in gcc-2.7 #BIGFILES=-D_FILE_OFFSET_BITS=64 CFLAGS=-Wall -Winline -O3 -fomit-frame-pointer -fno-strength-reduce -Zomf -Zmtd $(BIGFILES) # Where you want it installed when you do 'make install' PREFIX=/usr OBJS= blocksort.obj \ huffman.obj \ crctable.obj \ randtable.obj \ compress.obj \ decompress.obj \ bzlib.obj all: bz2.lib bzip2.exe bzip2recover.exe test bzip2.exe: bz2.dll bz2.lib bzip2.obj $(CC) $(CFLAGS) $(LDFLAGS) -o $ at bzip2.obj -L. -lbz2 bzip2recover.exe: bzip2recover.obj $(CC) $(CFLAGS) $(LDFLAGS) -o $ at bzip2recover.obj bz2.lib: bz2.def rm -f bz2.lib emximp -o $ at $< bz2.def: $(OBJS) echo "LIBRARY $* INITINSTANCE" > $ at echo "DATA NONSHARED" >> $ at echo "EXPORTS" >> $ at emxexp $(OBJS) >> $ at bz2.dll: $(OBJS) bz2.def $(CC) $(CFLAGS) $(LDFLAGS) -Zdll -o $ at $(OBJS) bz2.def check: test test: bzip2.exe at cat words1 ./bzip2.exe -1 < sample1.ref > sample1.rb2 ./bzip2.exe -2 < sample2.ref > sample2.rb2 ./bzip2.exe -3 < sample3.ref > sample3.rb2 ./bzip2.exe -d < sample1.bz2 > sample1.tst ./bzip2.exe -d < sample2.bz2 > sample2.tst ./bzip2 -ds < sample3.bz2 > sample3.tst cmp sample1.bz2 sample1.rb2 cmp sample2.bz2 sample2.rb2 cmp sample3.bz2 sample3.rb2 cmp sample1.tst sample1.ref cmp sample2.tst sample2.ref cmp sample3.tst sample3.ref at cat words3 install: bzip2 bzip2recover if ( test ! -d $(PREFIX)/bin ) ; then mkdir -p $(PREFIX)/bin ; fi if ( test ! -d $(PREFIX)/lib ) ; then mkdir -p $(PREFIX)/lib ; fi if ( test ! -d $(PREFIX)/man ) ; then mkdir -p $(PREFIX)/man ; fi if ( test ! -d $(PREFIX)/man/man1 ) ; then mkdir -p $(PREFIX)/man/man1 ; fi if ( test ! -d $(PREFIX)/include ) ; then mkdir -p $(PREFIX)/include ; fi cp -f bzip2 $(PREFIX)/bin/bzip2 cp -f bzip2 $(PREFIX)/bin/bunzip2 cp -f bzip2 $(PREFIX)/bin/bzcat cp -f bzip2recover $(PREFIX)/bin/bzip2recover chmod a+x $(PREFIX)/bin/bzip2 chmod a+x $(PREFIX)/bin/bunzip2 chmod a+x $(PREFIX)/bin/bzcat chmod a+x $(PREFIX)/bin/bzip2recover cp -f bzip2.1 $(PREFIX)/man/man1 chmod a+r $(PREFIX)/man/man1/bzip2.1 cp -f bzlib.h $(PREFIX)/include chmod a+r $(PREFIX)/include/bzlib.h cp -f bz2.lib $(PREFIX)/lib chmod a+r $(PREFIX)/lib/bz2.lib cp -f bzgrep $(PREFIX)/bin/bzgrep ln $(PREFIX)/bin/bzgrep $(PREFIX)/bin/bzegrep ln $(PREFIX)/bin/bzgrep $(PREFIX)/bin/bzfgrep chmod a+x $(PREFIX)/bin/bzgrep cp -f bzmore $(PREFIX)/bin/bzmore ln $(PREFIX)/bin/bzmore $(PREFIX)/bin/bzless chmod a+x $(PREFIX)/bin/bzmore cp -f bzdiff $(PREFIX)/bin/bzdiff ln $(PREFIX)/bin/bzdiff $(PREFIX)/bin/bzcmp chmod a+x $(PREFIX)/bin/bzdiff cp -f bzgrep.1 bzmore.1 bzdiff.1 $(PREFIX)/man/man1 chmod a+r $(PREFIX)/man/man1/bzgrep.1 chmod a+r $(PREFIX)/man/man1/bzmore.1 chmod a+r $(PREFIX)/man/man1/bzdiff.1 echo ".so man1/bzgrep.1" > $(PREFIX)/man/man1/bzegrep.1 echo ".so man1/bzgrep.1" > $(PREFIX)/man/man1/bzfgrep.1 echo ".so man1/bzmore.1" > $(PREFIX)/man/man1/bzless.1 echo ".so man1/bzdiff.1" > $(PREFIX)/man/man1/bzcmp.1 distclean: clean clean: rm -f *.exe *.dll *.obj bz2.lib bz2.def \ sample1.rb2 sample2.rb2 sample3.rb2 \ sample1.tst sample2.tst sample3.tst blocksort.obj: blocksort.c at cat words0 $(CC) $(CFLAGS) -c blocksort.c huffman.obj: huffman.c $(CC) $(CFLAGS) -c huffman.c crctable.obj: crctable.c $(CC) $(CFLAGS) -c crctable.c randtable.obj: randtable.c $(CC) $(CFLAGS) -c randtable.c compress.obj: compress.c $(CC) $(CFLAGS) -c compress.c decompress.obj: decompress.c $(CC) $(CFLAGS) -c decompress.c bzlib.obj: bzlib.c $(CC) $(CFLAGS) -c bzlib.c bzip2.obj: bzip2.c $(CC) $(CFLAGS) -c bzip2.c bzip2recover.obj: bzip2recover.c $(CC) $(CFLAGS) -c bzip2recover.c DISTNAME=bzip2-1.0.2 tarfile: rm -f $(DISTNAME) ln -sf . $(DISTNAME) tar cvf $(DISTNAME).tar \ $(DISTNAME)/blocksort.c \ $(DISTNAME)/huffman.c \ $(DISTNAME)/crctable.c \ $(DISTNAME)/randtable.c \ $(DISTNAME)/compress.c \ $(DISTNAME)/decompress.c \ $(DISTNAME)/bzlib.c \ $(DISTNAME)/bzip2.c \ $(DISTNAME)/bzip2recover.c \ $(DISTNAME)/bzlib.h \ $(DISTNAME)/bzlib_private.h \ $(DISTNAME)/Makefile \ $(DISTNAME)/manual.texi \ $(DISTNAME)/manual.ps \ $(DISTNAME)/manual.pdf \ $(DISTNAME)/LICENSE \ $(DISTNAME)/bzip2.1 \ $(DISTNAME)/bzip2.1.preformatted \ $(DISTNAME)/bzip2.txt \ $(DISTNAME)/words0 \ $(DISTNAME)/words1 \ $(DISTNAME)/words2 \ $(DISTNAME)/words3 \ $(DISTNAME)/sample1.ref \ $(DISTNAME)/sample2.ref \ $(DISTNAME)/sample3.ref \ $(DISTNAME)/sample1.bz2 \ $(DISTNAME)/sample2.bz2 \ $(DISTNAME)/sample3.bz2 \ $(DISTNAME)/dlltest.c \ $(DISTNAME)/*.html \ $(DISTNAME)/README \ $(DISTNAME)/README.COMPILATION.PROBLEMS \ $(DISTNAME)/CHANGES \ $(DISTNAME)/libbz2.def \ $(DISTNAME)/libbz2.dsp \ $(DISTNAME)/dlltest.dsp \ $(DISTNAME)/makefile.msc \ $(DISTNAME)/Y2K_INFO \ $(DISTNAME)/unzcrash.c \ $(DISTNAME)/spewG.c \ $(DISTNAME)/mk251.c \ $(DISTNAME)/bzdiff \ $(DISTNAME)/bzdiff.1 \ $(DISTNAME)/bzmore \ $(DISTNAME)/bzmore.1 \ $(DISTNAME)/bzgrep \ $(DISTNAME)/bzgrep.1 \ $(DISTNAME)/Makefile-libbz2_so gzip -v $(DISTNAME).tar # For rebuilding the manual from sources on my RedHat 7.2 box manual: manual.ps manual.pdf manual.html manual.ps: manual.texi tex manual.texi dvips -o manual.ps manual.dvi manual.pdf: manual.ps ps2pdf manual.ps manual.html: manual.texi texi2html -split_chapter manual.texi but on the new system the programs get compiled as *.o instead of *.obj... Could this be due to the use of gcc 3.0.3 instead of 2.8.1 ? If so, what can I do about it? -- John **= Email 17 ==========================** Date: Wed, 12 Jun 2002 22:13:16 +0100 From: John Poltorak Subject: Re: Wrong compiler flags On Wed, Jun 12, 2002 at 04:54:59PM -0400, Henry Sobotka wrote: > John Poltorak wrote: > > > > on the new system the programs get compiled as *.o instead of *.obj... > > > > Could this be due to the use of gcc 3.0.3 instead of 2.8.1 ? > > Yes. Hmmm.... I spent hours today trying to figure out what I had missed :-(... > > If so, what can I do about it? > > Add "-o $ at " to the rules for blocksort.obj, huffman.obj etc. or create > an O_SUFFIX variable, set it to "o" and replace all occurrences of "obj" > with $(O_SUFFIX). Does this mean different Makefiles for gcc 2.8.1 and 3.0.3? Sounds like a real minefield for anyone wanting to migrate to 3.0.3... > h~ -- John **= Email 18 ==========================** Date: Wed, 12 Jun 2002 22:16:54 -0400 From: Henry Sobotka Subject: Re: libtool and -version-info paul-biz wrote: > > I get this error all the time when trying to configure & make stuff. > It's trying to set a version number from libtool and it never likes > it... If I remove it, everything "seems" to be OK, but I'd like to find > out if it's just me or if it's normal... In this case I'm using GCC > 3.0.3 > > example of error: > > libtool: link: CURRENT `0:28:0' is not a nonnegative integer > libtool: link: `0:28:0' is not valid version information Also usually happens here with libtool. I routinely delete everything from [compile|link]-mode to the real flags just to avoid that recurrent failure as well as keep every src file from getting fed to gcc twice. h~