Need a little help with a dynamic linking problem

[Konstantin Belousov]

On Wed, Apr 25, 2012 at 05:58:37PM -0700, Ronald F. Guilmette wrote:
> 
> In message <CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3L_so732ePv1Vr5w at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20120426/3e416392/attachment.pgp