Need a little help with a dynamic linking problem

Ronald F. Guilmette rfg at
Thu Apr 26 00:58:38 UTC 2012

In message <CADt0fhw=cOrwaAmb8VNDRbCnwAuzhRyu=n3L_so732ePv1Vr5w at>
, 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

>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

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

% 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.


More information about the freebsd-ports mailing list