[LV2] lv2_descriptor() considered harmful

[David Robillard]

On Thu, 2012-03-15 at 18:49 +0100, Stefan Kersten wrote:
> On 3/15/12 6:31 PM, David Robillard wrote:
> > On Thu, 2012-03-15 at 18:24 +0100, Stefan Kersten wrote:
> >> On 3/15/12 6:17 PM, David Robillard wrote:
> >>> On Sun, 2012-02-26 at 17:03 -0500, David Robillard wrote:
> >>>> /**
> >>>>      Prototype for library accessor function.
> >>>>
> >>>>      This is the entry point for a plugin library.  Hosts load this
> >>>>      symbol from the library and call this function to obtain a
> >>>>      library descriptor which can be used to access all the UIs
> >>>>      contained in this library.  The returned object must not be
> >>>>      destroyed (using LV2_Lib_Descriptor::cleanup()) until all
> >>>>      plugins loaded from that library have been destroyed.
> >>>> */
> >>>> LV2_Lib_Descriptor const*
> >>>> lv2_lib_descriptor(const char*                bundle_path,
> >>>>                      const LV2_Feature *const * features);
> >>>>
> >>>> /**
> >>>>      Type of the lv2_lib_descriptor() function in an LV2 library.
> >>>> */
> >>>> typedef LV2_Lib_Descriptor const*
> >>>> (*LV2_Lib_Descriptor_Func)(const char*                bundle_path,
> >>>>                              const LV2_Feature *const * features);
> >>>
> >>> Should we perhaps avoid requiring a dlsym of a function, which is
> >>> technically not portable and usually a cause of at least a warning?
> >>
> >> could you elaborate why it's not portable?
> >
> > Standard C does not allow casting between function and data pointers.
> >
> > I am not sure how it impacts real world platforms.
> 
> hmm, but then on a platform where pointers to text and data are treated 
> differently then surely you would have a version of dlsym that returns a 
> function pointer? iow dlsym already is platform dependent and should do 
> the right thing?

dlsym() returns a data pointer.  It is the only function to get a symbol
from a library on POSIX.

GetProcAddress() returns a function pointer.  It is the only function to
get a symbol from a library on Windows.

So, no solution is correct.  I guess, yes, we just have to assume any
platform where this really is a problem would have a dlfunc or whatever.

In related news, I have discovered a different quasi-problem with this
API.  I was hoping having a LV2_Lib_Descriptor would remove the need for
all static data in the lib.  However, the library descriptor is not
available to LV2_Descriptor::instantiate, so if you load a list of
plugins at discovery time, you can't get at it in instantiate, unless:

 * You have static data in the library, shared between all instances of
that library

 * You calculate all that stuff again, for every plugin instantiation

This kinda sucks, but I see no solution.  It makes me wonder if a
library descriptor is even worth it.

-dr