From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 19 Jun 2003 14:07:09 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 132 ************************************************** Wednesday 18 June 2003 Number 132 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Holger Veit 2 Re: [EMX] Re: libc : Andreas Buening 3 Re: libc : T.Sikora" 4 Re: libc : Dave and Natalie" 5 Re: libc : Steve Wendt" **= Email 1 ==========================** Date: Thu, 19 Jun 2003 13:43:39 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc On Wed, Jun 18, 2003 at 07:48:49PM +0200, Andreas Buening wrote: > Holger Veit wrote: > > [snip] > > > We only have to preserve compatibility in that we need some fseek() and > > fseek_64() at all, not with binary compatibility with existing code > > (this can still access the old EMX DLLs and will be happy). > > I can understand why you'd like to break binary compatibility. Sure? I am curious... To be precise: there are several definitions of binary (in-)compatibility, so it is important to negotiate what we are talking about. One is the question of ELF vs. a.out. Another is ordinals vs. named DLL entries. A third is g++ 2.8.x vs. 2.95 vs. 3.x. The fourth is about API compatibility, as above the example of whether off_t is 32 bit or 64 bit. A fifth is the question whether some EMX successor should preserve all older entry points. And there are probably more stumbling blocks in the way that make the compatibility issue a minefield. Each of the above has the potential to break something old. The real question behind the "binary compatibility" killer argument is: Do we really want an improvement of the free OS/2 libc (call it EMX or different)? If the answer is yes, then we *must* break something in order to build something better, faster,more powerful (whatever the design goal is). This is the unavoidable price to pay. If the answer is no...well, German proverb tells us the problem: Wash my fur, but don't make it wet. It is impossible, and then there is no use in any further discussion on the topic (which is almost as old as the whole UnixOS2 movement). > However, I have a bad feeling about doing this. Some libraries > do this sometimes and this leads to a set of incompatible > binary files which can become quite nasty. I'd like to keep also > binary compatibility. So, I'll put up the clear question above again: Do you want an improvement? YES or NO? Holger **= Email 2 ==========================** Date: Thu, 19 Jun 2003 17:15:08 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Holger Veit wrote: > > On Wed, Jun 18, 2003 at 07:48:49PM +0200, Andreas Buening wrote: > > Holger Veit wrote: > > > > [snip] > > > > > We only have to preserve compatibility in that we need some fseek() and > > > fseek_64() at all, not with binary compatibility with existing code > > > (this can still access the old EMX DLLs and will be happy). > > > > I can understand why you'd like to break binary compatibility. > > Sure? I am curious... > > To be precise: there are several definitions of binary (in-)compatibility, > so it is important to negotiate what we are talking about. > > One is the question of ELF vs. a.out. > Another is ordinals vs. named DLL entries. > A third is g++ 2.8.x vs. 2.95 vs. 3.x. > The fourth is about API compatibility, as above the example of whether > off_t is 32 bit or 64 bit. > A fifth is the question whether some EMX successor should preserve all > older entry points. Binary compatibility means for me you can replace a DLL and your programs still work. This includes API compatibility and the preservation of the ordinal numbers (if you've ever used them). C++ is another story. We can't do anything about the fact that the g++ people change name mangling with every release (and that's the reason why C is used for the libc and why the libc is called lib_C_). [snip] > Do we really want an improvement of the free OS/2 libc (call it EMX or > different)? Yes. > If the answer is yes, then we *must* break something in order to > build something better, faster,more powerful (whatever the design goal > is). This is the unavoidable price to pay. This is the point I'm not totally convinced of. I agree that you have much more knowlegde of the emx and OS/2 internals than me and, most likely, than most people on this list. I do not say we must not do an incompatible change but I'm very sceptical about it. Sometimes I get the impression (I'm not talking about you, I'm just generally speaking) that some people are going through the world wearing a huge axe and taking no care of compatibility problems other people might have. Nobody ever needs this feature so let's kill it. Switching arguments of function foo() or adding some members to structure bar would perform much better so let's change it. xyz is a much better solution to that problem so let's remove that option. If people really need it they can easily modify their bla files. Who cares? This solution is much more beautyful. And, if in doubt, they recompile everything. Result? A huge bunch of incompatible stuff. If we have to introduce an incompatibility into emx then we may do it only once and never(*) again. And if anybody thinks six months or a year later that xyz could be solved better by foo or nobody needs option bar then the answer must be: Keep compatibility! Otherwise we'll just get a bunch of (more or less) useless libraries. (*) Never in this sense means never within this computer age which is equivalent to 10 years in real time. ;-) [snip] Bye, Andreas **= Email 3 ==========================** Date: Thu, 19 Jun 2003 19:26:02 -0400 From: "T.Sikora" Subject: Re: libc Knut St. Osmundsen wrote: > Andreas Buening wrote: > >> Knut St. Osmundsen wrote: >> >> [snip] >> >> >>> Build system isn't an issue anylonger, and even if it were, there are >>> millions >>> of them (allready responsible for 10+ (closed and open) myself). (If >>> anything, a >>> working GNU make is of much better use than yet another build system >>> - the >>> latest port is leaking a file/pipe handle everytime it's spawning a >>> child, and >>> -j is broken.) >> >> >> >> Which make version? > > $ make --version > GNU Make version 3.79.2a1, by Richard Stallman and Roland McGrath. > Built for i386-pc-os2-emx > [snip] > $ ls -l `which make` > -rwxrwx--a 112288 Feb 20 20:30 G:\GCCOS2\TREE\TOOLS\usr\bin\make.exe > > Kind Regards, > knut > > > The make 3.76.1 package from the unixos2 distro seems to have no apparent problems. Works with automake too. -- T.Sikora tsikora at ntplx dot net **= Email 4 ==========================** Date: Thu, 19 Jun 2003 21:06:42 -0800 From: "Dave and Natalie" Subject: Re: libc On Fri, 20 Jun 2003 00:57:19 +0200, Knut St. Osmundsen wrote: >> Which make version? >$ make --version >GNU Make version 3.79.2a1, by Richard Stallman and Roland McGrath. >Built for i386-pc-os2-emx >[snip] >$ ls -l `which make` >-rwxrwx--a 112288 Feb 20 20:30 G:\GCCOS2\TREE\TOOLS\usr\bin\make.exe Maybe try this one http://unix.os2site.com/sw/pub/binary/make/make-3_79_2a1-r2-bin.zip Dave **= Email 5 ==========================** Date: Thu, 19 Jun 2003 21:49:47 -0700 (PDT) From: "Steve Wendt" Subject: Re: libc On Thu, 19 Jun 2003 21:06:42 -0800, Dave and Natalie wrote: >>$ ls -l `which make` >>-rwxrwx--a 112288 Feb 20 20:30 G:\GCCOS2\TREE\TOOLS\usr\bin\make.exe > >Maybe try this one >http://unix.os2site.com/sw/pub/binary/make/make-3_79_2a1-r2-bin.zip Isn't that the same one? ----------- "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.)