>> gcc -shared .libs/rlm_eap_peap.o >> .libs/peap.o -Wl,--rpath -Wl,/usr/lib/freeradius -L/root/downloads/freeradi >> us-snapshot-20040629/debian/freeradius/usr/lib/freeradius -L/usr/lib/freerad >> ius -lradius -lrlm_eap_tls
> As time goes by, my hatred of libtool grows even more. It's turning > a local reference to rlm_eap_tls (e.g. "../rlm_eap_tls/rlm_eap_tls.*) > into a non-local one (-lrlm_eap_tls). It does this automatically, but > does NOT add the appropriate "-L/home/foo/radiusd/.../rlm_eap_tls" > entry, which tells the linker where that library is to be found. > I think I'll spend some time looking into throwing away libtool. > It's just too painful to use in the real world. > The only suggestion I can offer here is to pass the > "--disable-shared" option to configure. If this can help you I made these test: changing ../.. in Makefile.ini RLM_LIB (peap end tssl) with [EMAIL PROTECTED]@/rlm_eap_tls/rlm_eap_tls.la Something than change: Process halts and log reports cannot find rlm_eap_tls in /usr/lib But there is a problem more: It seemes to me libraries not linked in .libs folder are tagged in a different way from the other were linking was successfull. For example: *rlm_eap_md5-1.1.0-pre0.so *rlm_eap_md5-1.1.0-pre0.soT and rlm_eap_md5-s0 is the symbolik link for *rlm_eap_md5-1.1.0-pre0.so when installing all is right. Installer found link and library Instead in the case of peap and ttls you can find: *rlm_eap_ttls-1.1.0-pre0.soU *rlm_eap_ttls-1.1.0-pre0.so instead doesn't exist but exist symbolik link rlm_eap_ttls.so pointing to *rlm_eap_ttls-1.1.0-pre0.so and is obviously broken. So broken link is incorporated in deb but not the library. All this with only few warning in build file. This is what I meant saying : i can find only broken links of the two missing libraries and server faults. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
