mechglue loading issue

Nico Williams nico at
Thu Mar 17 10:30:34 EDT 2011

On Thu, Mar 17, 2011 at 1:05 AM, Luke Howard <lukeh at> wrote:
> The mechglue has API-as-SPI, that is, it supports dynamically loading a mechanism that exports the same ABI as the mechanism glue itself (with some exceptions, which are mostly historical or otherwise my doing!).
> On the platform I tested, the mechanism glue will pull in the symbol of the glue itself if a mechanism which links against the glue does not implement an entry point.
> This of course is catastrophic because mechanism-specific objects will be passed to the glue functions.

And now you know why PAM has different SPI symbols than API ones...  :)

> I resolved this by passing RTLD_FIRST (fix is in the users/lhoward/moonshot-mechglue-fixes branch). I don't know if this is an OS X-specific issue or not; I guess it could also be resolved by not having the plug-in mechanism link against the mechanism glue, or by having mechanisms implement all entry points (impractical).

RTLD_FIRST is not sufficiently portable, sadly (not when you consider
the need to build on older releases of various OSes).

The SPI can be the API, if you rename the symbols (e.g., by adding an
affix).  Cue others who will speak in favor of v-tables and what not
(not for me, those, thanks).

The bigger problem with the API-as-SPI is memory management.  The fact
that in the C bindings of the GSS-API there are structures that are
exposed to the app and may be allocated by the app but which contain
mechanism-allocated data is a memory management disaster in a
pluggable mechglue.  You have to either mandate that all plugins use
the same allocator (OK, I can live with that), or you have to resort
to memoization.  Ugh!  (This is what convinced me that API-as-SPI
doesn't work, though only for APIs such as the GSS-APIv2u1.  It is
possible to design APIs for which SPIs can be the same as the APIs,
though even then there will be utility functions which will only ever
be needed from the glue.)


More information about the krbdev mailing list