On 17/05/2013 19:50, Simon McVittie wrote: > On 17/05/13 10:43, Chow Loong Jin wrote: >> On 17/05/2013 13:17, Guillem Jover wrote: >>> I agree dlopen()ing shared libraries in general should not be >>> supported (I'd even go further and say this should be outright >>> banned, given the pain it causes, and optional library support >>> should always be implemented by loading a plugin properly linked >>> against such library with an ABI under the control of the program >>> loading it). >> >> But how do you load a plugin without using dlopen()? > > Classify each ELF dynamic library as either a "shared library" or a > "plugin", where shared libraries: > > * have a proper SONAME (libfoo.so.1 or at least libfoo-1.2.3.so) > * are linked normally (without using -module, if using libtool) > * are in /usr/lib/TUPLE or /usr/lib or a private library directory > * have a compilation symlink (libfoo.so -> libfoo.so.1), if not private > > and plugins: > > * have a trivial SONAME (libfoo-plugin.so) > * are linked with "libtool --mode=link -module -avoid-version" > if using libtool > * are always in a private library directory > > According to libtool documentation, on some platforms this distinction > is really significant, and "real shared libraries" can't be > dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I > think) are among the platforms where either works, so in practice most > projects don't have any supported platforms where there is a big > technical difference between shared libraries and plugins, and the > line between the two gets blurred.
Okay, so real shared libraries can't be dlopen()'d on some systems, and plugins still have to be dlopen()'d. That doesn't answer my question, really. -- Kind regards, Loong Jin
signature.asc
Description: OpenPGP digital signature
