I was having some trouble using the ALSA library called from within a
plugin. Apparently at some point libasound dlsym's itself, using a
null handle, which doesn't work if libasound is loaded as a dependency
of a dlopen'ed library (since its symbols are then not available to link
libraries against).
A web search produced an earlier post to this list (sorry, I lost the
reference) in which Jaroslav suggests opening the plugin library using
the RTLD_GLOBAL flag. I tried this, and in fact it works, but there is
a problem if you are loading more than one plugin at a time. That is,
with the plugins loaded RTLD_GLOBAL, there may be conflicts between
symbols in the plugins or their dependencies, leading to very puzzling
results (i.e., the wrong function being called). This actually
happened to me and it took a while to figure out what was going wrong.
In general, I don't think it's a good idea to have applications
loading plugins with RTLD_GLOBAL, since the application writer has no
idea what libraries might be loaded with the plugins (and thus what
symbols might be added to the symbol table). It occurred to me that I
could just have the plugin itself dlopen libasound with RTLD_GLOBAL in
its _init routine, which would then make the libasound symbols
available to itself (!). However, besides this being a nasty hack, this
still leaves the problem that the libasound symbols are made global.
On the whole, if it's not a terrible performance hit, it might be
better to have libasound dlopen itself in order to lookup symbols,
rather than using a null handle. This seems easier and cleaner than
documenting the problem so that application writers can work around it.
Just a suggestion.
Best regards -- Ken McMillan
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
