From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 13 Jun 2002 04:27:42 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 241 ************************************************** Wednesday 12 June 2002 Number 241 ************************************************** Subjects for today 1 Re: library numbers : Andreas Buening 2 Re: Everything is broken! : Andreas Buening 3 Re: Wrong compiler flags : Andreas Buening 4 Re: Wrong compiler flags : csaba.raduly at sophos.com 5 Re: Wrong compiler flags : csaba.raduly at sophos.com 6 Re: Everything is broken! : Mentore Siesto 7 BZIP2 Makefile : John Poltorak 8 Re: Everything is broken! : John Poltorak 9 Re: Everything is broken! : John Poltorak 10 Re: Everything is broken! : Stefan Neis 11 Re: BZIP2 Makefile : Brian Havard" 12 Perl 5.8.0 - no progress : John Poltorak **= Email 1 ==========================** Date: Thu, 13 Jun 2002 00:37:46 +0200 From: Andreas Buening Subject: Re: library numbers Steve Wendt wrote: > > 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? Okay, now another "library naming scheme" thread has started. I guess, we won't get to a conclusion. :-( OS/2 has this 8 byte name limit so we have to deal with it. Some people want long names like intl-0_11_1.dll and have to wait for LIBEMU, some peoble want names like intl0111.dll to handle different versions others don't care and prefer simple names like intl.dll (not to mention the "lib" prefix discussion). In my opinion most system libraries like gettext haven't seriously changed for years so that a single name without any numbering scheme should be okay. If any special application really needs a special version it has to be linked statically. But that's only my opinion. However, the only way to get a job done is to _do_ the job. I don't know when LIBEMU will be released or how long it will take to make it usable in production environments but we need a standard now. If John says the gettext dll has to be intl.dll and version 0.11.1 has to be used for it then it has to be intl.dll and not libintl.dll or intl1.dll or intl0111.dll or libintl0111.dll or libintl-0_11_1.dll or libintl-0_11_1.so or whatever. And if he says gcc 2.8.1 has to be used for the binary package with the -Zomf option then gcc 2.8.1 has to be used and not 2.95 or 3.x and intl.dll has to be in the OMF format and not a.out, elf or whatever. Period. End of Discussion. Of course, the aim of the UnixOS/2 project also is to provide source packages that can be easily compiled. If anybody really thinks that 0.11.3 must be used or libintl.dll is the only true name or gcc 2.95 or the a.out format has to be used then he is free to compile his own version on his own hard disk. And everybody is free to start his own project. But we have to make a standard to get finally rid of this rising chaos. 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: Thu, 13 Jun 2002 00:38:05 +0200 From: Andreas Buening Subject: Re: Everything is broken! John Poltorak wrote: [snip] > 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. This sounds reasonably. However, maybe gcc needn't be part of the first release. It's a huge package and may have large side effects. > 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 think this will be most likely a simple problem. autoconf 2.50 and 2.5x are quite similar. However, if we once have a working configure there is no need to update it to every new autoconf release except for testing purposes. The original m4 package hasn't changed since 1995 (?). > I'm not really sure how to make any progress either... 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 3 ==========================** Date: Thu, 13 Jun 2002 00:52:29 +0200 From: Andreas Buening Subject: Re: Wrong compiler flags Henry Sobotka wrote: > > 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. 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. 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 4 ==========================** Date: Thu, 13 Jun 2002 09:47:31 +0100 From: csaba.raduly at sophos.com Subject: Re: Wrong compiler flags On 12/06/2002 22:13:16 owner-os2-unix wrote: >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 :-(... > > Reading every readme for gcc 3.0.x :-) >> > If so, what can I do about it? >> perl -i~ -pwle "s/\.obj/\.o/" makefile > >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... > Actually, it was 2.8.1 (and 2.95 IIRC) which was a bit of a pain (especially until GNU make added default rules for .obj) -- 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 5 ==========================** Date: Thu, 13 Jun 2002 09:55:56 +0100 From: csaba.raduly at sophos.com Subject: Re: Wrong compiler flags On 12/06/2002 23:52:29 owner-os2-unix wrote: >Henry Sobotka wrote: >> >> 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. > >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. EMX is one of the very very few gcc ports which does output object files with .obj extension. >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? Surely ar can be made to recognize an a.out vs OMF file (be it object or library) and launch emxomfar as needed (or even link386, in effect merging ar and emxomfar). -- 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: Thu, 13 Jun 2002 10:16:02 +0200 (CEST) From: Mentore Siesto Subject: Re: Everything is broken! On Wed, 12 Jun 2002, John Poltorak wrote: JP >On Wed, Jun 12, 2002 at 10:46:55AM +0200, Mentore Siesto wrote: JP >> On Tue, 11 Jun 2002, Ted Sikora wrote: JP >> JP >> TS >There's HU's, UnixOS2, Warpzilla, etc. Graphic libs and what development JP >> TS >environment like EMX 0.9D or PGCC with 2.95 dll's should be recommended. JP >> JP >> What about GCC 3.03? Is it still too young? JP > JP >I'm still using gcc 2.8.1 and would like to move to v3.0.3 since I'd JP >prefer skipping pgcc 2.95, but I have some problems with it, and there are JP >some reports about the code it produces not being as good as older JP >versions. This relates to gcc itself rather than the OS/2 port, BTW. I JP >don't know if those issues have been addressed in v3.1.0 or whether we can JP >expect an OS/2 port of that some time... Got the point. So what about 2.95? Is it "the best" for now? I will try and work with it asap, trying to port UQLX (still, no spare time, too many things to study at university :(() -- Mentore Siesto Karate Shotokan, Ju Jitsu WJJF, Tai Chi Chuan Yang "Volevo vivere in un sogno dal quale non svegliarmi mai... Ma poi, mi sono svegliato." **= Email 7 ==========================** Date: Thu, 13 Jun 2002 10:33:28 +0100 From: John Poltorak Subject: BZIP2 Makefile In view of the changes to compile options in gcc 3.0.3, Makefile.os2 supplied here:- http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2-src.zip does not work with gcc 3.0.3. Can anyone make the required changes? The changes were described in an earlier thread about 'Compiler flags', but I couldn't work out how they could be applied in this case. -- John **= Email 8 ==========================** Date: Thu, 13 Jun 2002 11:05:16 +0100 From: John Poltorak Subject: Re: Everything is broken! On Thu, Jun 13, 2002 at 12:38:05AM +0200, Andreas Buening wrote: > John Poltorak wrote: > > [snip] > > > 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. > > This sounds reasonably. However, maybe gcc needn't be part > of the first release. It's a huge package and may have large > side effects. Yes, gcc is a large, complicated package, and I would like to split it up into two or more packages, one of which would be libemx - a package of standard headers and libs, based on EMX 0.9d with a few minor changes and additions. Hopefully this would be replaced by libemu in due course. > > 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 think this will be most likely a simple problem. > autoconf 2.50 and 2.5x are quite similar. However, > if we once have a working configure there is no need > to update it to every new autoconf release except for > testing purposes. The original m4 package hasn't changed > since 1995 (?). I think autoconf 2.53 was a very significant release because it purports to provide support for non-Unix systems and should, in theory provide everything we need, and I hoped I could use that instead of your OS/2 port of 2.50, but I can't. This means I need to keep *four* seperate versions of autoconf to build UnixOS/2 apps. Such a situation is always liable to cause problems. > 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 9 ==========================** Date: Thu, 13 Jun 2002 13:54:04 +0100 From: John Poltorak Subject: Re: Everything is broken! On Thu, Jun 13, 2002 at 02:25:21PM +0200, Stefan Neis wrote: > On Thu, 13 Jun 2002, Mentore Siesto wrote: > > > Got the point. > > So what about 2.95? Is it "the best" for now? > > I will try and work with it asap, trying to port UQLX (still, no spare > > time, too many things to study at university :(() > > In my experience, the switch from gcc-2.8 to gcc-2.95 also wasn't quite > trivial, so I'd suggest to either stay with gcc-2.8.1 or go for gcc-3.x > immediately. I suspect that quite a lot of Makefiles would need changing to accomodate going straight to 3.x... I think standardising on 2.95 at this time would not be worth the effort, but since there is nothing currently established as a standard, maybe we should aim at using 3.x and gear up for doing so in the near future. > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 10 ==========================** Date: Thu, 13 Jun 2002 14:25:21 +0200 (CEST) From: Stefan Neis Subject: Re: Everything is broken! On Thu, 13 Jun 2002, Mentore Siesto wrote: > Got the point. > So what about 2.95? Is it "the best" for now? > I will try and work with it asap, trying to port UQLX (still, no spare > time, too many things to study at university :(() In my experience, the switch from gcc-2.8 to gcc-2.95 also wasn't quite trivial, so I'd suggest to either stay with gcc-2.8.1 or go for gcc-3.x immediately. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 11 ==========================** Date: Thu, 13 Jun 2002 22:32:11 +1000 (EST) From: "Brian Havard" Subject: Re: BZIP2 Makefile On Thu, 13 Jun 2002 10:33:28 +0100, John Poltorak wrote: > > >In view of the changes to compile options in gcc 3.0.3, Makefile.os2 >supplied here:- > >http://silk.apana.org.au/pub/unixos2/bzip2-1.0.2-os2-src.zip > >does not work with gcc 3.0.3. > >Can anyone make the required changes? > >The changes were described in an earlier thread about 'Compiler flags', >but I couldn't work out how they could be applied in this case. Pretty easy really. I've just modified the above zip, or you can just get http://silk.apana.org.au/pub/unixos2/BZip2.Makefile.os2 if you already have the rest. -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------ **= Email 12 ==========================** Date: Thu, 13 Jun 2002 22:46:33 +0100 From: John Poltorak Subject: Perl 5.8.0 - no progress I still haven't managed a clean compile of Perl 5.8.0. There's definitely something missing from my db.lib. Has anyone else tried building it? In case anyone hasn't seen this before:- The announcement for Perl 5.8.0 RC1 is available here:- http://www.iki.fi/jhi/5.8.0-RC1-anno I'm told that I should expect to get a 100% pass rate for the test scripts, since this is normal for most platforms, so, please let me know what sort of problems you do get, or even better report them directly to the perl5-porters mailing list:- -- John