From owner-freebsd-ports@FreeBSD.ORG Thu Apr 26 08:06:58 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 BCF041065676; Thu, 26 Apr 2012 08:06:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 539978FC08; Thu, 26 Apr 2012 08:06:58 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3Q86odc046868; Thu, 26 Apr 2012 11:06:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3Q86nA6051994; Thu, 26 Apr 2012 11:06:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3Q86nUc051993; Thu, 26 Apr 2012 11:06:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Apr 2012 11:06:49 +0300 From: Konstantin Belousov To: "Ronald F. Guilmette" Message-ID: <20120426080649.GO2358@deviant.kiev.zoral.com.ua> References: <33226.1335401917@tristatelogic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fGyljYnAz0/nfUD" Content-Disposition: inline In-Reply-To: <33226.1335401917@tristatelogic.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: pav@freebsd.org, freebsd-gnome@freebsd.org, freebsd-ports@freebsd.org, Shawn Webb 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 08:06:58 -0000 --2fGyljYnAz0/nfUD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 25, 2012 at 05:58:37PM -0700, Ronald F. Guilmette wrote: >=20 > In message > , you wrote: >=20 > >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. >=20 > That much seems self-evident. The error message itself in effect says > precisely that. >=20 > >The symbol is defined in the gthumb application itself. Is that symbol e= xported > >such that shared objects can reference it? >=20 > Based on the outcome, I would have to say that this answer to that questi= on > is also (self-evidently?) no. >=20 > 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 depen= ds > 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 a= way > 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".) >=20 > Like I say. I don't know, cuz I'm not the developer/maintainer of this > thing. >=20 > >If the problem is still unresolved by tomorrow... >=20 > It doesn't seem to be healing on its own so far... >=20 > >I can draft up a sample and confirm my suspicions > >(that non-exported symbols won't be resolvable by dynamically-loaded sha= red > >objects). >=20 > Oh, I do believe that you are 100% correct about that. This much, at lea= st, > I _do_ remember from ancient times when I worked on the GNU software deve= lop- > ment tools (including the linker). >=20 > In every object file... either a main executable or a shared library, the= re > 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 ne= ver > sees or, at any rate, doesn't pay any attention to. >=20 > But my dim recollection is that you can easily tell which is which by loo= king > at the type letter that appears next to the symbol in the `nm' output. F= or > example: >=20 > % nm gthumb | fgrep gth_viewer_page_get_type > 00000000004aaf10 T gth_viewer_page_get_type > ^ >=20 > 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 cas= e) > it means that the symbol in question is ``public'' and available for > linking. (Actually, I _am_ pretty darn sure that this is indeed what CAP= ITAL > type letters in the nm output mean.) >=20 > The only other thing that I can't quite remember anymore is whether such > a symbol is always and necessarily available for *dynamic* linking purpos= es. > 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. >=20 You need to pass --export-dynamic to the linker when linking binary that is supposed to export its own symbols. --2fGyljYnAz0/nfUD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+ZAhkACgkQC3+MBN1Mb4jCBACeJsPnmCAoGXjuR/d+8tAWCQUL MbMAnj94BR1lb0I4LGpPy4gGQ+5Gi0uw =Ans7 -----END PGP SIGNATURE----- --2fGyljYnAz0/nfUD--