Paul TBBle Hampson wrote:
I'll have a look this weekend at what's in 1.1.0. Now that I've actually skimmed the list rather than just looking at the website, I'm breathing a sigh of relief that we didn't just roll back the 2.x naming decision.
As it is, it sounds like it won't take ("didn't take Nicolas") much work to make it build.
I just did the port of the set of patches you created for the Debian package 1.0.5-2. I tested the current branch 1.1 of CVS on both sarge and etch, and it seems to build correctly. (except for rlm_eap_peap and rlm_eap_ttls)
There're a couple of bugs in the Debian BTS that I want to address, and last I checked rlm_eap_ttls and rlm_eap_peap were still not building properly, pulling in the static libeap/rlm_eap_tls libs instead of linking to the shared libs.
I think libtool try to link rlm_eap_tls.so to rlm_eap_{peap,ttls}.so but actually fails to do it because it can't find librlm_eap_tls.so (with the "lib" prefix) in the *install* directory. I don't know if we can work around this. More info on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335890
As I recall, I didn't apply the net-snmp patch to release_1_0 branch because it choked up some problems with net-snmp (on Fedora Core??) pulling in incorrect autoconf #defines, and breaking the build. In CVS HEAD things were rearranged so that none of the .h files pulled in the net-snmp .h files, only the actual .c files that used them.
Ok, I think we'll definitely leave that for later, after 1.1.0 has been released.
Keep in mind that this is stolen from the now-defunct Debian libtool1.4 patch, and I make no promises that it'll work on non-glibc platforms. (I expect it'll work on glibc platforms, but I also don't promise this. ^_^)
It seems to me the changes in ltmain.sh are bugfix only, but I'm not very sure of it. An other option is to back-port the newer autotools version from CVS head, but it's a lot more of work... Either way, it's a post-1.1.0 thing, too. -- Nicolas Baradakis