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