From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 6 Jul 2003 14:08:30 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 144 ************************************************** Saturday 05 July 2003 Number 144 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Andreas Buening **= Email 1 ==========================** Date: Sun, 06 Jul 2003 22:24:06 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Ilya Zakharevich wrote: > > On Fri, Jun 27, 2003 at 08:48:35PM +0200, Andreas Buening wrote: [snip] > > 2) Existing static libraries can still be used if a) either the > > compilation and linkage is done only with old libraries and > > the old emx or b) the compilation and linkage is done with > > old libraries or libraries generated by (-D_OLD_EMX_STYLE) > > and the new libc, > > This needs also a support from the header files (e.g., mapping tell() Of course, static libraries and headers have to be consistent. [snip] > But I would object to the naming of your macro. Which style is OLD, > and which is NEW changes when time goes. It is much better to name > capability macros by the described capability, not by a timestamp. The macro name wasn't intended to be a draft. :-) > > 3) On the long term all old libraries will (hopefully) vanish? > > If a library has no linkage with changed functions, and has no > function with a changed typedef in the signature, there is no need to > obsolete this. If a library is very specialized and would never be > critical in a big-file situation, there is also no need to fix it. Nevertheless, the safe way would be to deprecate old libraries. [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? For the practical schedule I think it would be a good idea to divide the development into three steps: 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. 2. Appliance of all known bug fixes to emx and the last 100% compatible emx release (0.9g) as a proof of concept. 3. Update of the headers and addition of new features/functions. [snip] Bye, Andreas