Re: alsalib symbol problem

Re: alsalib symbol problem

[Juergen Kreileder]

Paul Davis <pbd@op.net> writes:

>>Paul Davis <pbd@op.net> writes:
>>
>>> the problem is that libasound itself calls dlopen(), and the
>>> initial (non-RTLD_GLOBAL) linkage hasn't put libasound's symbol
>>> into the global namespace. hence, libasound's own dlopen'ed code
>>> can't access libasound itself.
>>
>>I know, that's why I suggested to not do dlopen(NULL, ...) inside
>>libasound (see the code from my previous mail).
> 
> how does this help?

You don't have to use RTLD_GLOBAL when dlopening libasound.so or
libraries linked with libasound.so anymore.


        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux/java2-status/


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Re: alsalib symbol problem

[Florian Bomers]

Thanks ! I guess Juergen's suggestion would be of general: a plugin should be
able to link to libasound with -lasound without the need that the plugin itself
is linked/dlopen()'ed with RTLD_GLOBAL. With increasing adoption of ALSA, we'll
see such a scenario more and more...

On the practical side - how can I solve the problem ? I can't change the way my
plugin is linked to the main app, so do I need to manually dlopen() libasound
myself with the RTLD_GLOBAL flag (and not use -lasound ??)

Thanks,
Florian


Juergen Kreileder wrote:
> 
> Paul Davis <pbd@op.net> writes:
> 
> >>Paul Davis <pbd@op.net> writes:
> >>
> >>> the problem is that libasound itself calls dlopen(), and the
> >>> initial (non-RTLD_GLOBAL) linkage hasn't put libasound's symbol
> >>> into the global namespace. hence, libasound's own dlopen'ed code
> >>> can't access libasound itself.
> >>
> >>I know, that's why I suggested to not do dlopen(NULL, ...) inside
> >>libasound (see the code from my previous mail).
> >
> > how does this help?
> 
> You don't have to use RTLD_GLOBAL when dlopening libasound.so or
> libraries linked with libasound.so anymore.
> 
>         Juergen
> 
> --
> Juergen Kreileder, Blackdown Java-Linux Team
> http://www.blackdown.org/java-linux/java2-status/
> 
> -------------------------------------------------------
> Sponsored by: AMD - Your access to the experts on Hammer Technology!
> Open Source & Linux Developers, register now for the AMD Developer
> Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Re: alsalib symbol problem

[Tim Goetze]

Florian Bomers wrote:

>On the practical side - how can I solve the problem ? I can't change the way my
>plugin is linked to the main app, so do I need to manually dlopen() libasound
>myself with the RTLD_GLOBAL flag (and not use -lasound ??)

until your copy of alsa has jaroslav's recent addition, both. after,
-lasound should do.

tim



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: Re: alsalib symbol problem

[Florian Bomers]

Thanks - Juergen just pointed out a hack to me: define LD_PRELOAD=libasound.so .
It works fine - until I'll be able to use Jaroslav's fix. Thanks Jaroslav, too!

Florian


Tim Goetze wrote:
> 
> Florian Bomers wrote:
> 
> >On the practical side - how can I solve the problem ? I can't change the way my
> >plugin is linked to the main app, so do I need to manually dlopen() libasound
> >myself with the RTLD_GLOBAL flag (and not use -lasound ??)
> 
> until your copy of alsa has jaroslav's recent addition, both. after,
> -lasound should do.
> 
> tim
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: AMD - Your access to the experts
> on Hammer Technology! Open Source & Linux Developers, register now
> for the AMD Developer Symposium. Code: EX8664
> http://www.developwithamd.com/developerlab
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: alsalib symbol problem

[Juergen Kreileder]

Paul Davis <pbd@op.net> writes:

> the problem is that libasound itself calls dlopen(), and the initial
> (non-RTLD_GLOBAL) linkage hasn't put libasound's symbol into the
> global namespace. hence, libasound's own dlopen'ed code can't access
> libasound itself.

I know, that's why I suggested to not do dlopen(NULL, ...) inside
libasound (see the code from my previous mail).


        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux/java2-status/


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: alsalib symbol problem

[Paul Davis]

>Paul Davis <pbd@op.net> writes:
>
>> the problem is that libasound itself calls dlopen(), and the initial
>> (non-RTLD_GLOBAL) linkage hasn't put libasound's symbol into the
>> global namespace. hence, libasound's own dlopen'ed code can't access
>> libasound itself.
>
>I know, that's why I suggested to not do dlopen(NULL, ...) inside
>libasound (see the code from my previous mail).

how does this help?


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Re: alsalib symbol problem

[Takashi Iwai]

At Tue, 17 Sep 2002 10:59:17 -0400,
Paul Davis wrote:
> 
> >Paul Davis <pbd@op.net> writes:
> >
> >> the problem is that libasound itself calls dlopen(), and the initial
> >> (non-RTLD_GLOBAL) linkage hasn't put libasound's symbol into the
> >> global namespace. hence, libasound's own dlopen'ed code can't access
> >> libasound itself.
> >
> >I know, that's why I suggested to not do dlopen(NULL, ...) inside
> >libasound (see the code from my previous mail).
> 
> how does this help?

it openes /usr/lib/libasound.so.2 (resolved from dladdr) explicitly,
so you'll get symbols from the handle without referring to the global
namespace.

this solution sounds nice to me -- if it really works ;)

can anyone test it?


Takashi


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: alsalib symbol problem

[Juergen Kreileder]

Tim Goetze <tim@quitte.de> writes:

> Florian Bomers wrote:
> 
>>Why does this happen ? I searched the mailing list archive and only
>>found an explanation that symbols don't match and I need to
>>recompile the ALSA lib. In my case it's a clean install of ALSA on a
>>newly installed red hat system. There was never any other version of
>>ALSA.
> 
> you probably are calling alsa from a shared object -- try 
> 
>   dlopen ("libasound.so", RTLD_LAZY | RTLD_GLOBAL);
> 
> in your module's init function.

The need for RTLD_GLOBAL is somewhat ugly, usually one wants to load
plugins with RTLD_LOCAL.  E.g. Java's System.load()/loadLibrary()
doesn't use RTLD_GLOBAL.  We could make a special case for ALSA in our
Java implementation but that won't help people running JMF with
another JVM.

Is there any reason ALSA can't do something like 

   if (name == NULL) {
       Dl_info dlinfo;
       static int dummy;
       dladdr((void *) &dummy, &dlinfo);
       name = dlinfo.dli_fname;
   }

in snd_dlopen()?  This would fix the snd_dlopen(NULL, ...) problem
when the ALSA library has been dlopened with RTLD_LOCAL and the
symbols are unknown in the main program.


        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux/java2-status/


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Re: alsalib symbol problem

[Paul Davis]

>> you probably are calling alsa from a shared object -- try 
>> 
>>   dlopen ("libasound.so", RTLD_LAZY | RTLD_GLOBAL);
>> 
>> in your module's init function.
>
>The need for RTLD_GLOBAL is somewhat ugly, usually one wants to load
>plugins with RTLD_LOCAL.  

the suggestion is not that *your* plugin should use RTLD_GLOBAL, but
that RTLD_GLOBAL needs to be used when alsa-lib is linked into the
address space.

if you don't use RTLD_GLOBAL, then the symbols in libasound are not
availble for subsequently-loaded dynamically linked code.

>Is there any reason ALSA can't do something like 
>
>   if (name == NULL) {
>       Dl_info dlinfo;
>       static int dummy;
>       dladdr((void *) &dummy, &dlinfo);
>       name = dlinfo.dli_fname;
>   }

perhaps because this implementation of dlopen is platform specific?
the dladdr function and the dlinfo structure are not present in
my version of glibc, at least not as far as i can tell.

--p


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Re: alsalib symbol problem

[Jaroslav Kysela]

On Tue, 17 Sep 2002, Juergen Kreileder wrote:

> Tim Goetze <tim@quitte.de> writes:
> 
> > Florian Bomers wrote:
> > 
> >>Why does this happen ? I searched the mailing list archive and only
> >>found an explanation that symbols don't match and I need to
> >>recompile the ALSA lib. In my case it's a clean install of ALSA on a
> >>newly installed red hat system. There was never any other version of
> >>ALSA.
> > 
> > you probably are calling alsa from a shared object -- try 
> > 
> >   dlopen ("libasound.so", RTLD_LAZY | RTLD_GLOBAL);
> > 
> > in your module's init function.
> 
> The need for RTLD_GLOBAL is somewhat ugly, usually one wants to load
> plugins with RTLD_LOCAL.  E.g. Java's System.load()/loadLibrary()
> doesn't use RTLD_GLOBAL.  We could make a special case for ALSA in our
> Java implementation but that won't help people running JMF with
> another JVM.
> 
> Is there any reason ALSA can't do something like 
> 
>    if (name == NULL) {
>        Dl_info dlinfo;
>        static int dummy;
>        dladdr((void *) &dummy, &dlinfo);
>        name = dlinfo.dli_fname;
>    }
> 
> in snd_dlopen()?  This would fix the snd_dlopen(NULL, ...) problem
> when the ALSA library has been dlopened with RTLD_LOCAL and the
> symbols are unknown in the main program.

Nice fix. Applied.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab