alsalib symbol problem

alsalib symbol problem

[Florian Bomers]

Hi,

my code lists all available cards/devices/subdevices. As a stand-alone program,
it works fine and it links dynamically to libasound.so . However, when I use the
same code in my library, I get the following at run time (the "Opening..." and
"ERROR..." lines are generated by my code):

Opening alsa device "hw:0"...
ALSA lib dlmisc.c:100:(snd_dlsym_verify) unable to verify version for symbol
snd_config_hook_load
ALSA lib conf.c:2655:(snd_config_hooks_call) symbol snd_config_hook_load is not
defined inside (null)
ALSA lib conf.c:3066:(snd_config_update_r) hooks failed, removing configuration
ERROR: snd_ctl_open, card=0: No such device or address
Opening alsa device "hw:1"...
ALSA lib dlmisc.c:100:(snd_dlsym_verify) unable to verify version for symbol
snd_config_hook_load
ALSA lib conf.c:2655:(snd_config_hooks_call) symbol snd_config_hook_load is not
defined inside (null)
ALSA lib conf.c:3066:(snd_config_update_r) hooks failed, removing configuration
ERROR: snd_ctl_open, card=1: No such device or address

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. 

Thanks for any help,
Florian

Configuration:
 Pentium II
 Red Hat 7.3
 ALSA 0.9rc3 drivers and libs
 kernel 2.4.18-10 (updated sources and kernel from red hat's web site)

/proc/asound/cards:
0 [SB128PCI (etc) ]: ES1371 - Ensoniq AudioPCI
                     Ensoniq AudioPCI ES1371 at 0x1440, irq 10
1 [ESS ISA        ]: ES1868 - ESS AudioDrive ES1868
                     ESS AudioDrive ES1868 at 0x220, irq 5, dma1 1, dma2 3

/proc/asound/version:
Advanced Linux Sound Architecture Driver Version 0.9.0rc3.
Compiled on Sep 16 2002 for kernel 2.4.18-10 with versioned symbols.

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: alsalib symbol problem

[Tim Goetze]

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.

hth, tim



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

Re: alsalib symbol problem

[Juergen Kreileder]

Paul Davis <pbd@op.net> writes:

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

Ah, I haven't tried to dlopen libasound in a plugin yet.  Up to now
I've linked the plugin lib with -lasound, in that case you have dlopen
the plugin lib with RTLD_GLOBAL.

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

Define _GNU_SOURCE.


        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:
>
>>>> 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.
>
>Ah, I haven't tried to dlopen libasound in a plugin yet.  Up to now
>I've linked the plugin lib with -lasound, in that case you have dlopen
>the plugin lib with RTLD_GLOBAL.

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.

that's why you either either need to use RTLD_GLOBAL on the plugin
lib, or make sure that libasound alone is linked with RTLD_GLOBAL.

dynamically linking code that is linked to other code that dynamically
links code is, ahem, a little complex ;)

--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: 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: 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