Date: Thu, 15 May 2003 09:01:37 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: stable@freebsd.org Cc: dl@leo.org Subject: Re: __stderrp problem again with tk83 Message-ID: <200305151601.h4FG1b0m015682@strings.polstra.com> In-Reply-To: <20030515082750.GC47407@atrbg11.informatik.tu-muenchen.de> References: <20030513113145.GA42435@atrbg11.informatik.tu-muenchen.de> <891553987.20030513151537@xs4all.nl> <20030513133337.GF42435@atrbg11.informatik.tu-muenchen.de> <20030515082750.GC47407@atrbg11.informatik.tu-muenchen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20030515082750.GC47407@atrbg11.informatik.tu-muenchen.de>,
Daniel Lang <dl@leo.org> wrote:
>
> maybe to clarify things for me, please answer the following
> question:
>
> On a recent System (FreeBSD 4.8-STABLE #15: Wed Apr 9 10:08:16 CEST 2003),
> is it valid, that an object file from a just compiled source
> contains one of the as-it-seems obsoleted stdin/out symbols?
> In my case the symbol: "__stderrp".
>
> More precisely: can the following code from tkFont.c
> [..]
> fprintf(stderr, "Font %s still in cache.\n",=20
> Tcl_GetHashKey(&fiPtr->fontCache, searchPtr));
> [..]
>
> result in the following (then undefined) symbol:
>
> > atrbg11:/usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix#nm tkFont.o | grep=
> stderrp=20
> > U __stderrp
Yes, it is correct that a freshly-compiled object file contains a
reference to "__stderrp". That is exactly how things should be.
That symbol should be resolved from "/usr/lib/libc.so":
thin$ objdump -T /usr/lib/libc.so | grep __stderrp
0008749c g DO .data 00000004 __stderrp
So either you have an out-of-date libc, or else your application is
finding the wrong version of libc. Figure out why that is, and your
problem will be solved.
John
--
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Two buttocks cannot avoid friction." -- Malawi saying
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305151601.h4FG1b0m015682>