Re: Re: [UnixOS2] libc

On Sun, 22 Jun 2003, Ilya Zakharevich wrote:

> > handle big ones. You surely want to add such garbage to autoconf/automake
> > rulesets, don't you?
> 
> ???  It is already there, since all the major players do it this way.

Sure,
CXXLAGS="-DSOME_LARGE_FILE_MACRO" CFLAGS="-DSOME_LARGE_FILE_MACRO" ./configure
Great! And if some sub-library has (not) been using the flag while you did
(not), the stuff that you will get after hours of configure/make process
is just garbage. It works as long as _everybody_ is either ignoring the
flag or _everybody_ is using it.
Why would I want to duplicate all those problems on OS/2?

> Since the program in question has no way to get a uid which is !=0,
> there is no need to do anything else to port it.

There are some multi-user additions being developped, so setuid might well
be able to get a uid != 0 in the not so distant future.
 
> Yes, bug-for-bug compatibility is a bad target; and 0.1% of programs
> will break no matter how careful you are.  But numbers matter; on many
> systems LIBPATHSTRICT will help, and given a very few failing
> programs, a wrapper is a viable solution.

What good is LIBPATHSTRICT if DLL's with different names are used anyway?
 
> > of acceptance by "the community", or precisely, by a number of speakers
> > with their own agendas. libemu, or Posix/2, is an example of code that 
> > was not accepted by the community, in that it was regularly used in ports
> > and continously improved to weed out the bugs. Why? My opinion is:
> 
> I never believed that anything would come out of this (but I hoped
> nevertheless that it would).  Actually, I do not remember what it
> wanted to be;

A simple layer of BSD compatibility function in addition to what EMX
provides.

> but IIRC, it tried to solve problems which are mostly
> irrelevant (i.e., take very little proportion of porting time) by
> making some "magic actions" (like opening a "wrong file"), and by some
> pipe dreaming ("let us design a new program loader").

None of those is related to Posix/2 (at least not at its current state).

Actually, trying to use it on a larger scale for UnixOS/2, the biggest
problem was software already containing own workarounds for stuff missing
in EMX, so one ends up with duplicate symbols (e.g. setuid and various
others). Patching e.g. perl accordingly is a minor problem, but people
tend to not want patching working stuff...

       Regards,
               Stefan