__stderrp problem again with tk83

[John Polstra]

In article <20030515082750.GC47407 at atrbg11.informatik.tu-muenchen.de>,
Daniel Lang  <dl at 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