Thanks for the explanations.

But I have found, at last, the real problem (with some help from the gstreamer
guys).  glib2's configure script has a check to see if RTLD_GLOBAL works or
not.  This check fails under NetBSD; the reason is that the test program tries
to dlopen() libpthread, while the program is not linked against it.  Then, it
crashes (the startup problem I've listened multiple times).

So, after that, glib2 will always ignore requests to globally bind symbols,
causing the problems exposed by gst-plugins (and probably other programs). *EWW*

I'll be commiting a fix tomorrow morning.  It's too late now to finish all
this stuff ;)

Cheers


On Mon, 05 Apr 2004 16:18:16 -0400
Rafal Boni <rafal@pobox.com> wrote:

> In message <20040405193643.60199b0c.jmmv@menta.net>, you write: 
> 
> -> On Mon, 5 Apr 2004 18:00:39 +0200
> -> Martin Husemann <martin@duskware.de> wrote:
> -> 
> -> > On Mon, Apr 05, 2004 at 05:24:55PM +0200, Julio M. Merino Vidal wrote:
> -> > > > What is the output of "objdump -R libgstaudio.so | 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 libm.so *do*
>  however show a symbol table entry for tanf; as does objdump -R on the
>  binary).
> 
> -> 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
> 
> ----
> Rafal Boni                                                     rafal@pobox.com
>   We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill
> 


-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/