Re: Re: [UnixOS2] libc

On Sun, Jul 06, 2003 at 10:24:06PM +0200, Andreas Buening wrote:
> > > 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.

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
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.

> > > 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.

If we do enough, then deprecation is not needed; depreciation is a
better solution.

(E.g.: "we honestly expect that many old libraries will work; but if
you encounter problems and if want more support, recompiling/replacing
your libraries can encourage more people to help you" ;-).

> > 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.

  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.

  It is inevitable that patches will conflict - so a conflict
  resolution scenario is required.

  At some moment a decision must be made that these and those patches
  are accepted into the development branch - so somebody who has a
  power to do so is required.

> 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.

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 ;-).

Hope this clarifies my position,
Ilya