From owner-freebsd-stable@FreeBSD.ORG Thu May 15 09:01:51 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21D1637B401 for ; Thu, 15 May 2003 09:01:51 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 817FB43F75 for ; Thu, 15 May 2003 09:01:49 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h4FG1b7b097522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 May 2003 09:01:38 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h4FG1b0m015682; Thu, 15 May 2003 09:01:37 -0700 (PDT) (envelope-from jdp) Date: Thu, 15 May 2003 09:01:37 -0700 (PDT) Message-Id: <200305151601.h4FG1b0m015682@strings.polstra.com> To: stable@freebsd.org From: John Polstra 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> Organization: Polstra & Co., Seattle, WA X-Spam-Status: No, hits=-19.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) cc: dl@leo.org Subject: Re: __stderrp problem again with tk83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 16:01:51 -0000 In article <20030515082750.GC47407@atrbg11.informatik.tu-muenchen.de>, Daniel Lang 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