Paul TBBle Hampson wrote:
> I _think_ my last attempt involved causing librlm_eap_tls.* to come into
> existence during linking. The soname remains rlm_eap_tls so the actual
> references embedded in rlm_eap_{peap,ttls} are OK, and you can
> afterwards whack librlm_eap_tls.* and still have a working result. I'm
> pretty sure I had it working in make, and was just trying to find a good
> way to make it happen during the Debian build...
>
> Or I hit some other problem which escapes me.
>
> Alternatively, now we're usng a local libtool, I could try and hack on
> it to not screw with the lovingly crafted link-lines it's given.
I also tried with the evil RLM_EAP_LINK_MODE=-static, but it doesn't
work either. (non-PIC code errors in libeap)
Alan has fixed the problem in CVS head by moving all TLS code from
rlm_eap_tls to libeap, so the modules rlm_eap_peap and rlm_eap_ttls
don't link to rlm_eap_tls anymore.
http://lists.freeradius.org/pipermail/freeradius-devel/2005-November/009100.html
The same changes must be back-ported into the branch 1.1, it's better
than hacking libtool or the makefiles.
--
Nicolas Baradakis
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
