Re: Do opaque struct changes break C library ABIs
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.
S
Reply to: