Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Feb 1998 13:38:59 -0500
From:      "Kaleb S. KEITHLEY" <k.#nojunk#keithley@opengroup.org>
To:        hackers@FreeBSD.ORG
Subject:   Re: symbols in libc_r not in libc
Message-ID:  <34F70843.2781E494@opengroup.org>
References:  <199802271257.NAA24819@ws6423.gud.siemens.at>

next in thread | previous in thread | raw e-mail | index | archive | help
marino.ladavac@siemens.at wrote:
> 
> >
> > On a 3.0-971225-SNAP system, when I build Xlib thread-safe I use
> > -D_REENTRANT and -D_THREAD_SAFE, and all references to errno are
> > converted to *__error(). No problem there.
> >
> > Now when I link a non-threaded program, e.g. xterm, to the mt-safe Xlib,
> > when I try to run it I get unresolved externals for ___error.
> >
> > What that tells me is that libc (not libc_r) needs a #pragma weak
> > __error so that when I link non-threaded programs against libX11,
> > they'll work, and when I link a threaded program with libX11 and libc_r,
> > it'll get the right version of __error.
> >
> 
> As far as I can understand weak symbols, you can add your own version of
> __error() in Xlib, as a weak symbol.  

In my not so humble opinion, that's a hack.

> That way, the programs that do not
> use libc_r get the __error() from Xlib, and the ones that do from libc_r
> (I take it that the libc_r __error() is a strong symbol).  This should
> give you exactly what you need exactly where you need it.
> 
> The Xlib implementation of __error() should naturally just return the
> address of errno.  Don't forget to undefine errno when you implement
> the Xlib __error().
> 
> Hope I didn't miss anything.

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.

--
Kaleb S. KEITHLEY

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?34F70843.2781E494>