severity 288547 serious tags 288547 +sarge +etch +sid Thanks to a recent extension of lintian nonPIC checking to libraries that the linker doesn't see, it seems that this bug is simply a libtool1.4 breakage, and _should_ affect any architecture that can't load nonPIC code in a shared object, rather than just AMD64.
It only affects rlm_eap and rlm_eap_sim, that I can see, but it is probably present all the way back to their introduction to Debian. (rlm_eap_sim was enabled in 1.0.2-1, rlm_eap has been around for ages, but wouldn't have had this problem before rlm_eap_sim was introduced in 1.0.0, as that caused libeap to be split out of rlm_eap, and that's where this problem started.) The annoying part is that during the build, the library is fine and dandy. Then during "make install" libtool decides to slurp in libeap.a (non-PIC, static) instead of continuing to NEEDSing libeap.so (PIC, sharable) for rlm_eap.so and rlm_eap_sim.so. Since this bug was reported against 1.0.1-2, it's already part of Sarge's tree. And etch's, and sid's. Yuck! On the plus side, this means it shouldn't interfere with testing propagation. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office.
pgp0C8pKepLBp.pgp
Description: PGP signature
