Re: Re: [UnixOS2] libc

Stefan Neis <neis-RCUrBZHvLvKSHq+C5vT0LZQlNPQFfrerqZSUQi4AVrg@public.gmane.org> Wed, 18 Jun 2003 11:12:44 +0200 (CEST)
Newsgroups gmane.comp.ide.emx.devel
Message-ID <Pine.GSO.4.21.0306181056320.351-100000@cdc-ultra4.cdc.informatik.tu-darmstadt.de>
On Tue, 17 Jun 2003, Holger Veit wrote:

> > Huh? Which ones? I always had the impression that EMX's licence is rather
> > permissive...
> 
> The old GPL debate. GPL is not free, it is rather restricted. Too restricted
> to be acceptable for people who need tailored version of the software.

Is it GPL for the library? And even if the C runtime DLL is GPL'ed, what's
the effect on executables that happen to be usable together with that
specific DLL?
 
> EMX tried some
> balance there with the effect that some Unix things work, and some OS/2
> things work, and special cases don't, in both areas.

I'm under the impression that our aim would be to move that "balance"
closer to Unix, while InnoTek seems to try to move it closer to Win and
"native" OS/2.

> > 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.
> 
> Meanwhile, with rather limited time, I second that fully.

By now, I wonder if "cvs diff" is that much more uncomfortable for a
"small" project like this...

> complicated was the IMHO too complex interwoven system of dependencies
> in order to build the various variants of linraries from a single source
> tree. It needs some time to untangle this, but this is something that has
> to be done before any further work.

BTW, we should also determine what libraries we do want to build. I'd
suggest to drop at least single-threaded libraries and maybe even static
ones...
 
> Look at the way it is done in "real" Unix.

Well, I don't really know that much about "real" Unix libc internals...

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