From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9996 invoked by alias); 28 Apr 2003 23:47:28 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 9988 invoked from network); 28 Apr 2003 23:47:27 -0000 Received: from unknown (HELO palrel11.hp.com) (156.153.255.246) by sources.redhat.com with SMTP; 28 Apr 2003 23:47:27 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel11.hp.com (Postfix) with ESMTP id BF6631C011DB; Mon, 28 Apr 2003 16:47:26 -0700 (PDT) Received: from hplex1.hpl.hp.com (hplex1.hpl.hp.com [15.0.152.182]) by hplms2.hpl.hp.com (8.12.9/8.12.9/HPL-PA Hub) with SMTP id h3SNlPVn025243; Mon, 28 Apr 2003 16:47:26 -0700 (PDT) Received: from 15.0.152.182 by hplex1.hpl.hp.com (InterScan E-Mail VirusWall NT); Mon, 28 Apr 2003 16:47:24 -0700 Received: by hplex1.hpl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Apr 2003 16:47:24 -0700 Message-ID: <75A9FEBA25015040A761C1F74975667D01442060@hplex4.hpl.hp.com> From: "Boehm, Hans" To: "'binutils@sources.redhat.com'" Cc: "'Manuel Serrano'" , Hans Boehm , "'Kenneth C. Schalk'" , "'tromey@redhat.com'" Subject: Weak versioned symbols? Date: Mon, 28 Apr 2003 23:47:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2003-04/txt/msg00595.txt.bz2 Ken Schalk and Manuel Serrano pointed out a bug that shows up in my garbage collector. It is also reported in http://bugs.debian.org/165837 . My garbage collector currently refers to __libc_stack_end as a weak symbol. This symbol is no longer exported in glibc 2.3. I'm referring to it because there isn't yet an adequate replacement in deployed glibc versions, and my fallback algorithm for Linux is slower and relies on /proc, which may not always be available. The problem is that this appears to generate a runtime error if an executable was linked against glibc 2.2, but is then run in a 2.3 environment. My understanding was that weak symbols were introduced precisely to avoid this problem? What went wrong? Is this related to the patch in http://sources.redhat.com/ml/binutils/2003-04/msg00239.html ? Thanks for any insight. Hans Here's part of Ken's description of what happens: [Ken:] ...I ran into a thorny issue with __libc_stack_end and different versions of the GNU libc. The problem I had was exhibited by this message: relocation error: symbol __libc_stack_end, version GLIBC_2.1 not defined in file ld-linux.so.2 with link time reference Because of the way Vesta works, my builds of the collector (and everything linking with it) get done in a change-root environment that can be somewhat different from what's installed on the system I subsequently run the binaries on. In the case where I saw this, I was compiling in an environment with a 2.2 GNU libc and running in an environment with a 2.3 libc. ... I'm not sure who to pin the blame on, but the symbol does seem to get resolved at link time (to either "__libc_stack_end@@GLIBC_PRIVATE" or "__libc_stack_end@@GLIBC_2.1"). At run-time (when the error occurs), it's definitely no longer a weak symbol.