From owner-freebsd-current Sun May 3 03:30:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA12513 for freebsd-current-outgoing; Sun, 3 May 1998 03:30:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12409; Sun, 3 May 1998 03:30:02 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id DAA09447; Sun, 3 May 1998 03:30:01 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd009410; Sun May 3 03:29:51 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id DAA26301; Sun, 3 May 1998 03:29:46 -0700 (MST) From: Terry Lambert Message-Id: <199805031029.DAA26301@usr08.primenet.com> Subject: Re: errno change breaks old shared library linkage To: jb@cimlogic.com.au (John Birrell) Date: Sun, 3 May 1998 10:29:46 +0000 (GMT) Cc: bde@zeta.org.au, jb@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199805030606.QAA11651@cimlogic.com.au> from "John Birrell" at May 3, 98 04:06:26 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 > The problem here is that shared libraries don't link against other > shared libraries - only the program knows what shared libraries it > is looking for. This is broken. I believe it's an "ld" bug. An example would be a shared library "A" that exports the function "foo". The function "foo" depends on the function "fee". The function "fee" is implemented in library "B". A program that imports function "foo" by linking against shared library "A" will *NOT* get an unresolved symbol error at link time, despite not having been linked against library "B" as well. In other words, the current ld does not correctly handle second order dependencies. I have run into this bug while doing production code. The only workaround has been to do one of: 1) First link the program statically. If this succeeds, then relink it dynamically. 2) Modify the dlopen call in crt0's mapping of shared libraries to ensure a preload, so as to cause a runtime error. Currently, the only method of detection is a runtime error if the code *happens* to hit a codepath in the program that results in "foo" calling "fee". That is, it's currently possible for a vendor to deploy defective dynamically linked programs, and not be aware of the problem. This should be a high priority item, I'd think. Currently, I plan to implement workaround #1. 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