From owner-freebsd-ports@FreeBSD.ORG Thu Apr 26 00:58:38 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB71C106566B; Thu, 26 Apr 2012 00:58:37 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A58298FC08; Thu, 26 Apr 2012 00:58:37 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 62B0650851; Wed, 25 Apr 2012 17:58:37 -0700 (PDT) To: Shawn Webb In-Reply-To: Date: Wed, 25 Apr 2012 17:58:37 -0700 Message-ID: <33226.1335401917@tristatelogic.com> From: "Ronald F. Guilmette" Cc: pav@freebsd.org, freebsd-ports@freebsd.org, freebsd-gnome@freebsd.org Subject: Re: Need a little help with a dynamic linking problem X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 00:58:38 -0000 In message , you wrote: >Without being able to look at the details in-depth myself, it looks like >the shared object is looking for a symbol which the RTLD can't resolve. That much seems self-evident. The error message itself in effect says precisely that. >The symbol is defined in the gthumb application itself. Is that symbol exported >such that shared objects can reference it? Based on the outcome, I would have to say that this answer to that question is also (self-evidently?) no. But I'm really not sure, frankly, because I have never before seen an instance of anybody trying to do something screwy like this... I mean having a shared library that depends upon somthing (a symbol) that is intended to be satisfied by the main executable. Frankly, this seems altogether screwy and bizzare to me. Unsually, the main executable depends on (or uses, dynamically) a number of shared libraries. Sharded libraries in turn typically depend on either (a) nothing at all or else (b) some combination of other shared and/or static linking libraries. That has always been my own past experience anyway. By like I said, I have been away from the software development tools for awhile, so mabe having a dynamic library that depends upon something in the main executable is considered kosher now. (Or maybe it ain't, actually, but it is nonthelwess one of those screwy things that the current or original developer or maintainer found out that he could get away with anyway, you know, like JUST over on that well-known hobbist OS whose name begins with the letter "L".) Like I say. I don't know, cuz I'm not the developer/maintainer of this thing. >If the problem is still unresolved by tomorrow... It doesn't seem to be healing on its own so far... >I can draft up a sample and confirm my suspicions >(that non-exported symbols won't be resolvable by dynamically-loaded shared >objects). Oh, I do believe that you are 100% correct about that. This much, at least, I _do_ remember from ancient times when I worked on the GNU software develop- ment tools (including the linker). In every object file... either a main executable or a shared library, there are symbols that are externally available/visible and then there are ones that aren't... i.e. that are local, and that the dynamic linker either never sees or, at any rate, doesn't pay any attention to. But my dim recollection is that you can easily tell which is which by looking at the type letter that appears next to the symbol in the `nm' output. For example: % nm gthumb | fgrep gth_viewer_page_get_type 00000000004aaf10 T gth_viewer_page_get_type ^ Here, the symbol type indicator is the letter `T', meaning that this is a ``text'' (executable/code) type of symbol. That much I know for sure. The part I am less clear about anymore is that I _think_ I remember that when the type letter on the nm output is a capital letter (as in this case) it means that the symbol in question is ``public'' and available for linking. (Actually, I _am_ pretty darn sure that this is indeed what CAPITAL type letters in the nm output mean.) The only other thing that I can't quite remember anymore is whether such a symbol is always and necessarily available for *dynamic* linking purposes. It might perhaps just be externally available & visible ONLY for *static* linking purposes, in which case that might explain why I am seeing a `T' on the nm output for the required symbol, but yet the dynamic linker clearly can't seem to find it. Regards, rfg