From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 27 May 2002 04:26:11 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 225 ************************************************** Sunday 26 May 2002 Number 225 ************************************************** Subjects for today 1 Re: make 3.79.1 and compiling emacs : Andreas Buening 2 Re: Re: compiling emacs : Andreas Buening 3 Re: Re: compiling emacs : John Poltorak 4 Deja vu: perl_, xs module and coredump : Edwin =?iso-8859-1?Q?G=FCnthner?= 5 Perl testers wanted : John Poltorak **= Email 1 ==========================** Date: Mon, 27 May 2002 00:55:28 +0200 From: Andreas Buening Subject: Re: make 3.79.1 and compiling emacs John Poltorak wrote: > > On Tue, May 21, 2002 at 08:07:03AM -0400, Arnstein.Prytz at jcu.edu.au wrote: > > > > AFAICR, I had problems trying to compile EMACS with the previous release. > > > > Do you think it should work now? > > > > > > It should. But I haven't tested this special case. > > > > Does this mean someone may be able to update emacs for us (says > > he hopefully, with little experience of his own)? I am using > > 20.6.1 by Jeremy Bowen, but this has some serious bugs when > > spawning processes to send mail and such. > > I was referring to v20.7... > > There were some instructions on the list a couple of months ago about how > to build emacs v20.7 provided by Masaru Nomiya. > > I'll repost them here for anyone who missed them the first time:- [60 lines] > That's all. ;-) > It took me a couple of attempts, but I did manage to build it eventually, > although I did have a problem with a previous release of Make 3.79.1. You have to set MAKESHELL=/bin/sh because cmd cannot handle things like "\"some_text\"". Older make ports use some voodoo to handle these quotes. However, using gcc 2.95 I cannot compile emacs because of: gcc: Internal compiler error: program ld got fatal signal 11 Using 2.8.1 it fails somewhat later: Cannot open load file: ../lisp/international/titdic-cnv But these are no make 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. **= Email 2 ==========================** Date: Mon, 27 May 2002 00:55:34 +0200 From: Andreas Buening Subject: Re: Re: compiling emacs John Poltorak wrote: [compiling emacs] > Installing emx and all the gnu stuff is still a real pain. I was hoping > that the situation would have become much more straightforward by now, but > its actually more confusing than it was a year ago, because it may be > necessary to use one of three different versions of gcc to build any > particular app. Having said that, we are, IMV, catching up with the > mainstream open source apps. I guess, to get an out of the box working UO/2 distribution you need more organization. ;-) Currently if you have three OS/2 developers they will go into four different directions. In my opinion you need some kind of standard that defines how a UO/2 package is supposed to behave. I'm not talking about 1000 pages of specification but simple statements like - All packages have to behave the same way on OS/2 like they do on Linux which means they have to support the same env. vars and the same options unless otherwise stated. Exceptions from this rule are only allowed if caused by limitations of the operating system or the system API itself. or - All packages have to work without any OS/2 specific env. var. unless otherwise stated. The only exceptions are $UNIXROOT and $TMPDIR. A package may support an additional option/env. var. like GNU_MY_FUNNY_VAR but nevertheless it has to work without using this option/env. var. - To maintain compatibility the behaviour of programs according to command line options/env. vars. must never be changed unless - the maintainer at gnu.org (or whereever) does so and the changes are already incorporated into the main source tree. - it is really a bug - it is currently a misdesigned feature that causes lots of trouble _and_ it can be assumed that changing this behaviour to a new incompatible but consistent behaviour will most likely reduce the amount of trouble. - the new option/env. var. is an OS/2-specific extension like support for EA and is _really_ useful. This especially means that changes of any package that do not comply with these rules must not be incorporated into UO/2 so that we don't have 3 different make, 4 gcc and 6 shells which is a hell of maintenance. Nobody will be caused to program according to these rules. In the worst case you have - a developer who may be not related to UO/2 and ports his GNU foo 1.2 to OS/2 in a non UO/2 compliant way. - a UO/2 developer who makes the package ready for UO/2 and uploads it to ftp.unixos2.com/unixos2/source/foo - a distribution maintainer who compiles this package according to the UO/2 package guidelines (compiler flags, directory structure, package-specific options) and uploads it to ftp.unixos2.com/unixos2/distro/d1. Btw: Please make a simpler directory structure on the ftp server. It's really hard to find anything. Using d1/foo.zip for the binary package is okay as this directory structure may be intended to be burnt on CD. But /pub/os2/unixos2/packages/unixos2/d1 for the current binary and /pub/os2/somewhere/ is really hard to memorize. What about /unixos2/source for sources, /unixos2/stable for the last stable release and /unixos2/current for the latest betas? Just a few thoughts. 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: Mon, 27 May 2002 15:06:09 +0100 From: John Poltorak Subject: Re: Re: compiling emacs On Mon, May 27, 2002 at 12:55:34AM +0200, Andreas Buening wrote: > John Poltorak wrote: > > [compiling emacs] > > > Installing emx and all the gnu stuff is still a real pain. I was hoping > > that the situation would have become much more straightforward by now, but > > its actually more confusing than it was a year ago, because it may be > > necessary to use one of three different versions of gcc to build any > > particular app. Having said that, we are, IMV, catching up with the > > mainstream open source apps. > > I guess, to get an out of the box working UO/2 distribution > you need more organization. ;-) Sure, that's what we have been aiming at over the last two years, but OS/2 users don't really like someone organising them :-)... > Currently if you have three OS/2 developers they will > go into four different directions. In my opinion > you need some kind of standard that defines how a UO/2 > package is supposed to behave. I'm not talking about > 1000 pages of specification but simple statements like > > - All packages have to behave the same way on OS/2 like > they do on Linux which means they have to support the same > env. vars and the same options unless otherwise stated. > Exceptions from this rule are only allowed if caused > by limitations of the operating system or the system API > itself. As a starting point, we adopted a typical Linux distro, ie Slackware about a year ago, just to provide a guiding framework for UnixOS/2. Firstly to bring all existing ports into a common directory structure without endless arguments about creating a new directory structure. This has been a useful exercise and now many of the common archives are available in that framework. > or > > - All packages have to work without any OS/2 specific > env. var. unless otherwise stated. The only exceptions > are $UNIXROOT and $TMPDIR. A package may support an > additional option/env. var. like GNU_MY_FUNNY_VAR > but nevertheless it has to work without using this > option/env. var. > > - To maintain compatibility the behaviour of programs > according to command line options/env. vars. must never > be changed unless > - the maintainer at gnu.org (or whereever) does so and > the changes are already incorporated into the main > source tree. > - it is really a bug > - it is currently a misdesigned feature that causes > lots of trouble _and_ it can be assumed that changing > this behaviour to a new incompatible but consistent > behaviour will most likely reduce the amount of trouble. > - the new option/env. var. is an OS/2-specific extension > like support for EA and is _really_ useful. > > This especially means that changes of any package that > do not comply with these rules must not be incorporated > into UO/2 so that we don't have 3 different make, 4 gcc > and 6 shells which is a hell of maintenance. Nobody will > be caused to program according to these rules. > In the worst case you have > - a developer who may be not related to UO/2 and ports > his GNU foo 1.2 to OS/2 in a non UO/2 compliant way. > - a UO/2 developer who makes the package ready for UO/2 > and uploads it to ftp.unixos2.com/unixos2/source/foo > - a distribution maintainer who compiles this package > according to the UO/2 package guidelines (compiler > flags, directory structure, package-specific options) > and uploads it to ftp.unixos2.com/unixos2/distro/d1. I don't really think we need to be concerned with whether a developer/porter produces apps for the UnixOS/2 distro, it's up to the distro maintainers to package those apps into a compliant format. The only thing I would want from a developer is some instructions on how to rebuild an app from scratch, so that it could easily be made to fit in with the rest of the distro. There is no need for the porters of Apache or MySQL, for example, to try and make a UnixOS/2 package. It's great of them to put as much effort as they do into producing an OS/2 version, and there should be no requirement for someone who wants to use one of those packages to need a UnixOS/2 distro. UnixOS/2 should provide a homogenous environment for users to run Unix-like apps on OS/2, so it should be easier to install and maintain apps in that environment. Until now the main focus has been assembling all the existing apps and putting them into a standard archive format. This has been a long job and still isn't complete. I was hoping that we could have come up with the nucleus of a UnixOS/2 distro by now which would include all the basic GNU utils along with SED, GREP, AWK etc and a standard set of DLLs, but INTL seems to be a moving target and there are still too many versions around. Also, I don't know the current status of Autoconf and Automake on OS/2... If we can resolve this small number of issues, we could be close to something which could be a usable distro. It isn't at the moment. It's more a collection of seperate apps. > Btw: Please make a simpler directory structure on the > ftp server. It's really hard to find anything. > Using d1/foo.zip for the binary package is okay as this > directory structure may be intended to be burnt on CD. > But /pub/os2/unixos2/packages/unixos2/d1 for the current > binary and /pub/os2/somewhere/ is really hard to memorize. > What about /unixos2/source for sources, /unixos2/stable for > the last stable release and /unixos2/current for the latest > betas? The unixos2 directory structure which was agreed on a long time ago has been arbitrarily abandoned after I spent many months and hundreds of postings in various forums giving people URLs for specific archives. These are now no longer valid. As far as getting the UnixOS/2 distro developed in a structured and managed way, I have long thought that having a Sourceforge project would be the best way, but I never managed to get approval for such a project. A UnixOS/2 project would provide an excellent repository for both source and binaries and should allow changes to get documented automatically. If anyone knows how and wants to help, then please let me know. > Just a few thoughts. > > bye, > Andreas > > -- -- John **= Email 4 ==========================** Date: Mon, 27 May 2002 15:36:53 +0200 From: Edwin =?iso-8859-1?Q?G=FCnthner?= Subject: Deja vu: perl_, xs module and coredump hi there, you might remember that I asked about a forking perl and about compiling Perl extensions some time ago. I got several peaces that were all working, and now I wanted to put them together. I have * perl 5.6.1 on my machine + the latest perl_.exe that allows forking * pgcc based on gcc 2.9.5 * my own perl xs module My problem is that: I can compile my module and install it to my perl package on my OS/2 machine. I can run my module with perl.exe. When I try to run the same script with perl_, I get a core dump right when I say "use myModule;" I thought: maybe that is caused because I used perl.exe to compile the module; thus I renamed perl_.exe to perl.exe ... but this doesnt work (using perl_ it tells me that it cand find a lib file that I need for compiling - and that is THERE). Strange; I really thought I was beyond this problem ... **= Email 5 ==========================** Date: Mon, 27 May 2002 21:57:22 +0100 From: John Poltorak Subject: Perl testers wanted Can anyone give this latest Perl snapshot a try? :- ftp://ftp.funet.fi/pub/languages/perl/snap/perl at 16816.tgz v5.8.0 RC1 is due out next week, so it would be good to get any OS/2 problems reported beforehand. -- John