On Thu, Apr 15, 2004 at 10:28:10AM -0400, Alan DeKok wrote: > [EMAIL PROTECTED] (Paul Hampson) wrote: > > > They can then be patched to call lt_dlopen, which should solve the > > > problem. > > > > Looking at it, surely it'd be better to grab the already loaded module > > pointer from the array filled in by eaptype_load. > > That won't help, though, because the ttls module doesn't have those > symbols resolved. So grabbing the module pointer from eaptype_load > doesn't help you, unless you use it to link to the functions by hand. > In which case, you might as well just have dlopen'd rlm_eap_tls.
Fair point. I was indeed thinking about using lt_dlsym all over the shop, but that's silly in the harsh light of morning. I guess I should just lt_dlopenext(blah, "rlm_eap_tls") in the attach routines of ttls and peap, and lt_dlopenext(blah, "libeap") in the attach routines of ttls, peap and sim. Anyone got an easy EAP/SIM test harness set up for me to confirm that I've fixed it and not broken anything? > > The other choice is the muck with the Makefiles so eap_ttls links > > against rlm_eap_tls and libeap directly. Seems less neat, although > > we _know_ that TTLS and PEAP both depend on TLS utterly, and SIM > > utterly depends on libeap, as I can tell from almost glancing at it. > If it works... I'm less fond of this solution, since FreeRADIUS is happy to load everything _else_ at runtime. -- Paul "TBBle" Hampson, on an alternate email client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
