From: Alan W. I. <ir...@be...> - 2005-11-18 23:18:42
|
Hi Geoffrey: I am glad you got everything to work. Other general comments below that are probably mostly of interest to you and our past and present release managers. Alan On 2005-11-18 14:54-0600 Geoffrey Furnish wrote: > autoconf (GNU Autoconf) 2.59 > automake (GNU automake) 1.8.5 > ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27) These were the autotools versions that worked on Geoffrey's platform. I have autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.9.5 ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 224 $ All of mine are patched Debian (stable) versions, but I doubt that difference or probably even the difference between Geoffrey's automake 1.8.5 and my 1.9.5 version is going to matter that much. So even if Geoffrey changed over to my exact autotools, I think he would get the same (good) result on his system. The reason why my autotools give a different result on my system is not because my autotools are different. Instead, I believe the different results are because my system *is* different with different capabilities (linker, run-time loader) than Geoffrey's, and libtool recognizes that difference. After all, libtool is designed to give different (hopefully correct) responses on different platforms so we shouldn't be surprised when that occurs. Furthermore, I am pretty sure I am also getting a "good" result on my system. That is with my combination of linker and run-time loader I bet using a mixture of Intel and gcc compilers in any combination of PLplot build and application build would work just fine. That's just speculation though, and I have no time/inclination to try that experiment. All the above said, it is a known problem (even acknowledged in the autotools book) that certain combinations of autotools versions do screw up. And it does sound from Geoffrey's reports that the autotools combination that created the autotools-dependent files in the plplot-5.5.3 tarball gave incorrect results for his specific platform. However, we don't know exactly what those autotools versions were. They were the ones used by Tom Duck, our release manager to generate the tarball. IIRC, they were from Debian testing, but that is a moving target so even Tom could probably not recreate what they were at this late stage. There are a number of conclusions I draw from this saga. (1) We should be using unpatched autotools versions directly from gnu.org to create the tarballs. Tom, this is what I used to do as release manager, but this is not a complaint against you because Rafael and I encouraged you to just follow what Rafael did before you for his releases. Also, this isn't a knock against Rafael; I fully approved Rafael's use of Debian versions of the autotools because gnu.org was in a security mess at the time. But it isn't any more, and now we have had this bad experience with a particular (probably not re-creatable) Debian testing version of autotools, I think we should go back to using definite, unchanging gnu.org versions so Linux developers can easily repeat what was done to recreate any of our release tarballs. (2) To facilitate that "easy re-creation" we should clearly identify *in the tarball* what autotools versions were used to create the configuration files in that tarball. I think this could be accomplished by storing in a standard file location the output from the && cf/bootstrap.sh ${VERSION:---date-version} \ command in scripts/make-cvs-tarball.sh. Rafael, do you agree to this change or do you have some other preferred mechanism for putting a combined autotools version stamp into the tarball? (3) Finally, a big issue continues to be testing of the release tarballs on as wide a variety of platforms as possible. Geoffrey, if you had participated in the testing of the 5.5.3 tarball release candidate (without running cf/bootstrap.sh), you could have identified this problem on your particular platform sixth months ago. Nobody else has reported such a problem so there was probably no harm done in this case to our general users, but the next issue you find might have a larger impact on general users. So I encourage you as a PLplot core developer with a lot of PLplot knowledge and wide PLplot deployments to participate fully in the testing of our next tarball release. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |