Subject: Re: Fw: Fighting gst-plugins
To: Julio M. Merino Vidal <>
From: Rafal Boni <>
List: tech-userlevel
Date: 04/05/2004 16:18:16
In message <>, you write: 

-> On Mon, 5 Apr 2004 18:00:39 +0200
-> Martin Husemann <> wrote:
-> > On Mon, Apr 05, 2004 at 05:24:55PM +0200, Julio M. Merino Vidal wrote:
-> > > > What is the output of "objdump -R | grep gst_audio_cloc
-> k_new"?
-> > > 
-> > > Nothing...  is that good or bad?
-> > 
-> > That means, for whatever reason, libgstaudio is not dynamically exporting
-> > that symbol. This explains your problem ;-)
-> Looking at objdump -R output, I see that some functions appear, while others
-> don't.  I haven't been able to guess the rationale behind that, though.  If
-> I manually define a 'void foo(void)' function in any of those source files,
-> it doesn't get exported (but it appears in nm as T).  But if I add a call to
-> foo() inside any of the functions that already appeared in objdump -R, foo()
-> appears too.

Right, -R is probably the wrong flag to be checking.  You probably want 
objdump -D or nm -D instead.  -R will only show the function if there are
relocations which reference it in that library (like if you call it from
some other place in the library), but generally the relocs you care about
will occurr in the caller (be it a shared lib or the main executable).

(On my sparc64 machine, for example, "tanf(3)" doesn't show a dynamic
 reloc in libm, but I can still write a program that calls it and it's
 found just fine when I link with -lm; nm -D/objdump -D on *do*
 however show a symbol table entry for tanf; as does objdump -R on the

-> Shouldn't func() appear as a dynamic relocation entry?  If not, what
-> determines which symbols should appear?

Not necessarily (it should, however, if you reference it from some other
function in your shared lib).  The symbol *should* be in the dynamic symbol
table in either case, however.


Rafal Boni                                           
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill