From owner-freebsd-current Sat May 23 15:21:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11923 for freebsd-current-outgoing; Sat, 23 May 1998 15:21:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (root@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11914 for ; Sat, 23 May 1998 15:21:45 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA17263; Sat, 23 May 1998 14:08:02 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd017206; Sat May 23 14:07:53 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id OAA13753; Sat, 23 May 1998 14:07:51 -0700 (MST) From: Terry Lambert Message-Id: <199805232107.OAA13753@usr07.primenet.com> Subject: Re: Fix for undefined "__error" and discussion of shared object versioning To: jdp@polstra.com (John Polstra) Date: Sat, 23 May 1998 21:07:51 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <199805231948.MAA06143@austin.polstra.com> from "John Polstra" at May 23, 98 12:48:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In article <199805211742.KAA18688@usr01.primenet.com>, > Terry Lambert wrote: > > > Loading should occur in reverse link order. > > Are you suggesting that shared libraries should behave exactly the > opposite of static libraries? Sorry, that dog don't hunt. No. I'm saying if I have shared libraries A, B, C, with link order A B C And I'm resolving a weak symbol that exists in all three, then I should get the definition from C, not from A or B. So the inversion of priority only applies to weak symbols. Consider the case where I have a program linked against these libraries, and there is a strong symbol in C, but it's already been assigned to the weak one in A. In practice, ld.so does the right thing right now. The problem is when I have a statically linked weak symbol in the same compilation unit, and I want to link shared against something with a strong version of the symbol, the shared objects symbol does not override. This is a bug in ld. Another interesting bug in ld is that the code that would tell me that a dependent symbol was not resolved in my cshared library, and save my bacon at runtime, is "#if 0"'ed out for no reason that I can discern. This relates to a previous bug I reported against ld, where I have an object O that takes symbol q from shared library A, and symbol q requires symbol r as a dependency, the lack of the symbol r in A or any other shared library fails to evoke an undefined symbol error. Basically, ld is a mess. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message