Re: Re: [UnixOS2] libc

Ilya Zakharevich <[email protected]> Thu, 17 Jul 2003 08:39:03 -0700
Newsgroups gmane.comp.ide.emx.devel
Message-ID <[email protected]>
On Thu, Jul 17, 2003 at 05:21:17PM +0200, Stefan Neis wrote:
> > The obvious problem is how to interpret NULL given as the name of the
> > library.

> Now, that you mention it, I vaguely remember that there is such a problem.
> But since that's never used anyway ( ;-) ) what's the point in claiming
> that dlopen doesn't work?

a) I never claimed that dlopen() does not work;

b) I can't claim it until you (this is plural ;-) describe *how* the
   implementation is *supposed* to work;

c) I maintain two packages relying on dlopen(); one of them would
   never use NULL (perl); another one would *typically* use NULL (PARI).
   This is 50%.  Too much for "never" (even with smilies).

d) In both cases I have my own implementation of dlopen() which cater
   to particular modes of usage.

"b" is the crucial point.  *All* this discussion is about your (?)
claim "just look in BSD manpages".  *All* I'm trying to establish is
that this is a fallacy.  It just makes no sense (with exception of
several trivial cases, such as strcasecmp()).

> > Let me reiterate: this says nothing until you explain what is your design.

> Being as BSD-compatible as possible. At least I believe that was the
> design by those providing the code (_not_ me).

I repeat: this makes no sense.  Most cases where one *can* be fully
compatible are already in EMX.  The rest requires changes of semantic.
"As close as possible" says nothing if you can go in many different
directions to change the semantic.

> > Now, when one ports an application, *and one cannot avoid* using these
> > particular calls, the porters can check whether the calls are used as
> > you expected.  If so, then they can use your library.

> The problem is, they can't - at least not easily: configure script won't
> detect the function thus it will not be used (and in the worst case,
> there will be a problem at link time with multiple defined symbols).

If ./configure is able to detect that something is missing, then it
should be able to substitute something else (otherwise why check for
it)?

Moreover, it is trivial to ask configure to check additional libraries.

Hope this helps (and sorry that this discussion looks as directed
personally at you),
Ilya