Date: Thu, 26 Apr 2012 11:06:49 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: pav@freebsd.org, freebsd-gnome@freebsd.org, freebsd-ports@freebsd.org, Shawn Webb <lattera@gmail.com> Subject: Re: Need a little help with a dynamic linking problem Message-ID: <20120426080649.GO2358@deviant.kiev.zoral.com.ua> In-Reply-To: <33226.1335401917@tristatelogic.com> References: <CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3L_so732ePv1Vr5w@mail.gmail.com> <33226.1335401917@tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <CADt0fhw=3DcOrwaAmb8VNDRbCnwAuzhRyu=3Dn3L_so732ePv1Vr5w@mail.= gmail.com> > , 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120426080649.GO2358>