From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 8 Jul 2003 14:08:31 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 145 ************************************************** Monday 07 July 2003 Number 145 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Andreas Buening 2 Re: [EMX] Re: libc : Stefan Neis **= Email 1 ==========================** Date: Tue, 08 Jul 2003 09:40:15 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Ilya Zakharevich wrote: > > On Sun, Jul 06, 2003 at 10:24:06PM +0200, Andreas Buening wrote: [snip] > > Of course, static libraries and headers have to be consistent. > > This is not what I meant. For full compatibility, when a ABI/API-fork > (if you know what I mean ;-) is performed, the new functions should Not really. ;-) > have different link-time name, and the header files should #define old > names into the new ones. Actually, the same should be done for the > old names; i.e., fstat() should be replaced by fstat32() and fstat64() > - with "purely named" fstat() also sitting somewhere for the sake of > ./configure scripts. For configure scripts only the linker needs to find them. So fstat will be most likely only exist in the import library and will be an alias for fstat64. [snip] > > > P.S. But unless EM says otherwise, I think that without a volunteer > > > maintainer all this is going to be a pipe dream. > > > We'll see. Btw, where have gone all the volunteers who wanted to host > > the new emx CVS? > > It may be ignorance, but in many years of my experience I never saw a > situation when CVS helps. We need a central source archive, anyway. > It is *crucial* that the patches fly through a mailing list (or, > better, an mailing-list/archived-newsgroup combo) - so that as many > people as possible can comment on this. ACK. If we have no maintainer we need at least some quality control. :-) [snip] > > 1. Restructuring of the current emx build system (no idea how much > > work would be necessary for this) to make sure the new build > > system works before we change anything. > > IMO: DO NOT do this. Use 2.8.1 + dmake. Somebody mentioned that the current emx build system should be improved if I remember correctly. I haven't looked closely at this, yet. If we want to do this we should do it right at the beginning. > There are *pressing needs* to fix things. Restructuring is a luxury > with no (?) known benefits. > > > 2. Appliance of all known bug fixes to emx and the last 100% > > compatible emx release (0.9g) as a proof of concept. > > AFAIK, there is no need to have the *last* compatible release. The > amount of work to make new releases compatible is muniscule comparing > to QA work. And in the absense of QA framework it is crucial to have > a large pool of applications which have a chance to break due to > yet-uncovered bug - so we can fix this bug early ;-). Of course, it isn't necessary to have a _compatible_ release but it is (IMHO) necessary to have a _working_ release directly at the beginning so we can revert to this working version if anything goes wrong. And in this case it makes sense to make the first working release also a compatible release. When applying the (few) bug fixes we'll see where the possible bottlenecks are of our mailinglist/CVS system and whether it works at all. Btw, could reply to the UnixOS/2 list directly by 'to' not by 'cc'? cc'ed posts seem to get lost. Bye, Andreas **= Email 2 ==========================** Date: Tue, 8 Jul 2003 17:10:15 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Tue, 8 Jul 2003, Ilya Zakharevich wrote: > I repeat: > > a) I know of no issue with 2.8.1 + dmake (but of course, this may be > just ignorance). While I agree, the problem is that whatever new source one adds (e.g. Posix/2), it won't be happy with dmake. While mixing two different makes is certainly possible, it's also possibly confusing. > > it is (IMHO) necessary to have a _working_ release directly at the > > beginning so we can revert to this working version if anything goes > > wrong. > > Again, I do not follow. All the releases should be treated this way... I suppose, that's the CVS point of view. Start CVS with something that's working, so their is a solid grounding... Regards, Stefan