Re: [UnixOS2] libc

Stefan Neis wrote:
> 
> On Tue, 17 Jun 2003, Adrian Gschwend wrote:

[snip]

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

You're right. That sounds ... strange.


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

I think we'll have to start with more basic tasks like updating the
emx headers/libs for new standard functions. ;-)
I'd like to keep the standalone libs like intl and pthreads out of emx.
Lots of Unix system also have standalone versions of them so it's
more important to get them working than to integrate them into emx.
However, the details have to be discussed.


> for accessing files - BTW, large file support is the third candidate which
> "wants" specific changes in that same area).

How do other systems solve this problem? Do they use an internal
fseek_64() replacement which is used by default instead of fseek()?


[snip]

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

Yes, this could become a serious problem. Maybe we have to port emx
to a new build system first. ;-)

[snip]

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

Nobody knows, I guess.

[snip]


Bye,
Andreas