Re: Problem with LT 2.1a

[Bob Friesenhahn]

On Wed, 6 Sep 2006, Ralf Wildenhues wrote:
> I concur with Bob; about a handful of packages that need it one way or
> the other (after all, it was changed not only for cleanliness, but
> because some packages needed it changed).
>
> We could add another interface
>  lt_dlopen_flags (const char *filename, int flags);
>
> and transport that information through the loader_data?
>
> Or just
>  lt_dlopen_set_flags (int flags);
>
> but that again looks ugly from a serialization point of view (since the
> user would need to do the locking...).  Unsure.

Options should be specific to some sort of libltdl handle since 
multiple libraries used by the same application may make indepenent 
use of libltdl and their needs may be different.  This exposes a 
design weakness in the libltdl API in that it does not provide an 
extensible means of supplying options.  The POSIX threads API is a 
good example of an API which uses an extensible means of supplying 
options in an ABI-safe way.

Options like RTLD_GLOBAL have global impact to the application so 
operation of independent libraries could become ambiguious.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/