[17140] in Kerberos_V5_Development
Re: Proposed libverto integration plan
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 7 12:13:12 2011
From: Greg Hudson <ghudson@mit.edu>
To: "krbdev@mit.edu" <krbdev@mit.edu>
In-Reply-To: <201108232107.p7NL7Vde012737@outgoing.mit.edu>
Date: Wed, 07 Sep 2011 12:13:04 -0400
Message-ID: <1315411984.718.15.camel@t410>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, 2011-08-23 at 17:07 -0400, ghudson@MIT.EDU wrote:
> 1. Bundle the libev source in util/k5ev [...]
> 2. Bundle the core libverto source in util/verto [...]
> 3. Add a libverto-k5ev module to the bundled libverto
> 4. If you configure with --with-system-verto [...]
> 5. If you configure with --without-system-verto [...]
> 6. If you don't specify either [...]
There have been a few adjustments to this plan:
* The k5ev sources are built directly into libverto-k5ev, so there's no
need for a separate libk5ev.
* When using the internal verto, we bypass dynamic linking by including
<libverto-k5ev.h> and calling verto_default_k5ev() instead of
verto_default().
The second adjustment is to make it possible for static builds to work
and to work around current issues with the dynamic linking support on
OSX.
Personally, I'm not 100% happy with handling the problem at the calling
layer. I'd prefer verto_default() to work for the integrated verto as
well as it does for a system verto. But Sam and Nathaniel preferred
this approach.
If we do decide to handle this inside verto_default(), it would probably
involve a compiler conditional in verto.c to throw out the dynamic
loading code (which would improve portability) and invoke a specific
loop creation function from verto_default().
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
