Re: [UnixOS2] libc

On Tue, 17 Jun 2003, Adrian Gschwend wrote:

> >Maybe moving that discussion to UnixOS2 or EMX list would
> >be more appropriate...
> 
> I vote for UnixOS2 list.

In view of Ilya's recent post to EMX list
> Can't we find a new volunteer for maintainance of EMX.DLL and
> EMXCRTM.DLL?  The job is to *collect* contributed patches, weed out
> the weeds, and decide when we have a snapshot good enough to be named
> golded.
I decided to also involve emx mailing list into this discussion...

I was asking about InnoTek and their gcc (and its libc), Adrian replied:

> Just some comments from Achim (taken from #netlabs irc, btw hint hint,
> IRC is a *good* way to communicate :-)

I like the asynchronity (??) of mail. Everyone can read/reply when he can
spare some minutes. ;-)
 
> <achimha> well, our libc is done to fulfill our needs
> <achimha> it is incompatible with emx (note by ktk: due to licensing
> problems with EMX)

Huh? Which ones? I always had the impression that EMX's licence is rather
permissive...

> <achimha> our GCC is targeted to be a VAC/Watcom replacement not a Unix
> porting environment
> <achimha> just wait for our first distribution then we can discuss how
> to combine the various efforts

To be honest, that doesn't sound to promising from the porting point of
view. There are some things that _have_ to be deep inside libc, otherwise
e.g. closing sockets by close instead of closesocket or pthread support
won't work... :-(

> For Unixos2-only people: Henry proposed to create a CVS for libc, now
> the question is what do we want to take as base (EMX, LIBEMU and
> Innotek-GCC libc is in dicussion, there is also one from IBM btw)

I think we should start with EMX, add Posix/2, some link support,
pthreads, libintl and maybe some other nice little extensions and then
start making it all work together and fixing bugs (e.g. pthread library
and library for symlink support (via EA) both modify certain functions
for accessing files - BTW, large file support is the third candidate which
"wants" specific changes in that same area).

Whether the CVS is rooted at netlabs or sourceforge (we could start by
abusing the Posix/2 CVS) is rather irrelevant to me, however it would be
great to automatically send all CVS commits (as a diff) to some dedicated
mailing list (I know that wxWindows did such a thing also while the CVS
was hosted by sourceforge, so it's possible to set it up like this even
there - but I don't know, how to do it), so whoever is interested has a
chance to check things easily.

The biggest problem for starting however is probably the build system:
EMX libs expect dmake, IIRC. Posix/2 wants some GNUmake, pthreads want
I don't know what etc. Unifying this and "porting" the Makefiles to some
current GNUmake is going to require much time for not much to gain... :-(

Ideally, we would also stay backward compatible, which implies keeping the
right ordering for the already existing symbols in the DLL's. (though I'd
suggest to make the import libraries for the new DLL's using "import by
name"). OTOH, I _suppose_ large file support if put into the "normal" C
routines is going to cause incompatibilities anyway (file positions no
longer fit into an int, do they?), so maybe it would even be a good idea
to be intentionally incompatible (old EMX DLL's handle small files, in the
new runtime, everything would be large file enabled - Hmm, I'll have to
get a new harddisk to create a large enough JFS partition for testing...).

> It would be nice if we really could discuss that all together and agree
> on a sollution that is fine for everyone and allows enhancements in the
> future (no dead end).

What I don't know at all is, how this could fit into Holger's long term
plans. Ideally, replacing a couple of low level C routines by his more
complete/efficient implementations - once they are ready - would be
sufficient, but for this,  it would be a big plus to have a rather
detailed list of what functions those are going to be, I suppose.
E.g. an improved link implementation is going to affect some other file
related functions ((f)open, (f)stat, ...), but if we know this in advance,
we can have some internal function like __dereference_link that's called
by all those, so the changes from a temporary E/A based link emulation to
"real" links are minimized...

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.