From owner-freebsd-current Sun May 24 20:57:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08840 for freebsd-current-outgoing; Sun, 24 May 1998 20:57:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08831 for ; Sun, 24 May 1998 20:57:01 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id UAA08934; Sun, 24 May 1998 20:56:54 -0700 (PDT) (envelope-from jdp) Message-Id: <199805250356.UAA08934@austin.polstra.com> To: Terry Lambert cc: current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object versioning In-reply-to: Your message of "Sat, 23 May 1998 21:07:51 -0000." <199805232107.OAA13753@usr07.primenet.com> Date: Sun, 24 May 1998 20:56:54 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. It seems like that behavior would be awfully surprising to most users. I don't think any other linkers treat weak symbols like this, do they? > 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. Yes, it's been there for years. :-( > 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. Yes, another old bug. :-( > Basically, ld is a mess. 8-(. Exactly. Several people including myself have gone into ld with the idea of fixing the above bugs. We all still have nightmares about the experience. The bugs aren't just bugs, they're major design problems. That's why everybody who really scrutinizes ld decides it would be a lot easier to throw it out and switch to ELF. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message