Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Feb 1998 09:52:18 -0500
From:      "Kaleb S. KEITHLEY" <k.keithley@opengroup.org>
To:        hackers@FreeBSD.ORG
Subject:   Re: symbols in libc_r not in libc
Message-ID:  <34F6D322.59D2@opengroup.org>
References:  <199802271415.PAA25144@ws6423.gud.siemens.at>

next in thread | previous in thread | raw e-mail | index | archive | help
marino.ladavac@siemens.at wrote:
> >
> > Well, just that Xlib isn't in the business of providing libc functions
> > or putting a band-aid over a broken libc.
> >
> > The weak __error() function belongs in libc.
> 
> Well, I am obviously of a different opinion--I'll try to give you my
> rationale for it.
> 
> libc exports a well-known interface to its clients.  errno is one of these
> interfaces, and if the clients want to use just libc, this is all they get.

And your headers are creating a new interface in libc/libc_r, one that
Xlib doesn't want to know about and should never need to know about.


> Now, you are building a client (Xlib) which should be usable both as a
> reentrant and non-reentrant library.  There is a slight dichotomy here.
> You really need an interface the libc does not need to provide (nor is
> required to do so).  

Maybe not required by virtue of any standard.

> Since your Xlib in this particular case is misusing
> the libc, 

No, it's not misusing libc. Why do you say that?

> it has to live with the interfaces that the libc provides.

The ones it knows about. Xlib is written to POSIX. If your headers
change things. If your headers create non-POSIX interfaces from POSIX
usage, then your libc needs to accomodate that.

> Therefore, it needs to provide its own interfaces made from the building
> blocks provided by libc.

Nope. As reluctant as I am to use this argument, I'll use it anyway. No
other system with threads requires me to hack Xlib as you suggest in
order to make this work. Does that help?

It's easier for me to just say "FreeBSD's libc is too badly broken for
me to consider supporting pthreads in X on FreeBSD."

> 
> The problem that we both have with this is that your Xlib is a performance
> hack.  

That's your opinion. I don't share it.

> The pure solution would require the existence of Xlib and Xlib_r.
> Let me state immediately that I am all for such an Xlib--having two of them
> would be one too many.

??? 

> 
> I hope you understand my view.

No, I don't. But that's okay. I just won't ever support pthreads in the
official Open Group Sample Implementation of X11 on FreeBSD.

I hope you understand my view.

-- 
Kaleb

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34F6D322.59D2>