On Wed, Apr 25, 2012 at 05:58:37PM -0700, Ronald F. Guilmette wrote: > > In message > <CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3l_so732epv1v...@mail.gmail.com> > , 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. >
You need to pass --export-dynamic to the linker when linking binary that is supposed to export its own symbols.
pgpo71aLSij2q.pgp
Description: PGP signature
