Hi Gary, * Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET: > Ralf Wildenhues wrote: > > > > However, I have absolutely no problem with delaying the application of > > the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2. Although > > we should still commit both the `-static' hardcoding fix and the > > static.at test patch (the latter is written so that it works also > > without the per-deplibs-flags patch; it needs only -static-libtool-libs). > > Agreed. The more tests we commit, the better. I think adding tests that > will fail due to known bugs in the release is okay too... we just mark > them XFAIL until the known bug is fixed after the release.
Sure. > >> * <!> libtool.m4 macro ordering/requirement audit. pending > > > > This is as good as done. > Okay, moved to 'fixed'. Thanks! > >> * <!> LT_WITH_LTDL should build libltdl by default; currently > >> nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE > >> is also given. > > > > I don't even know what this means. I'd guess we should ignore it? > > It means that LT_WITH_LTDL in configure.ac that mentions neither > LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all. > I have a start to a fix for this. Well, so is that really a bug? AFAIK the 1.5 docs require you to use AC_LIB_LTDL, _not_ AC_WITH_LTDL (that exists but isn't even mentioned in the docs), and AFAICS AC_LIB_LTDL *will* cause libltdl to be built: see the second old-am-iface.at test, which explicitly does this. The updated form of AC_LIB_LTDL is LTDL_INIT, not LT_WITH_LTDL. However, our current CVS HEAD documentation fails to even mention LTDL_INIT. I wonder whether this is maybe a bug in documentation only? Disclaimer: I haven't tested anything now. > >> * <!> fix potential denial of service with compilers that do not > >> understand "-c -o". > > I don't mind postponing that to after 2.0, iff that is _not_ responsible > > for bugs like this one: http://bugs.debian.org/350989 > Okay. I'll leave it on the list as is until you determine whether to > postpone or not. The Debian bug is unrelated. I'll still try to finish my pending patch today and post it: we can still decide then whether it's more risky to apply it or to postpone it. > > IMHO (most notably the OpenBSD failure; and good would be the > > application of the `-static-libtool-libs' patch for users that > > need the other `-static' semantics; together with the hardlinking > > regression that I also found for `-static') > > I agree that fixing regressions is necessary. I'm not sure that we > need to delay the release for new features... Can you amend the RoadMap > to reflect your thinking on this please? Sure. Can we agree on adding `-static-libtool-libs'? Rationale: the semantic change of `-static' effectively caused a regression for users. The new flag is to amend this. I'll await answer on this and update the TODO list then. > > - I know about a couple more tweaks necessary for HEAD libtoolize > > and Bob has a couple of failures I (or somebody else) need to track > > down. > > Agreed. If you put them on the RoadMap, I might get to them before you. Well, this comment of Bob completely mystifies me: http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582 I believe in that thread there were more issues mentioned. There was one other one, and from memory, I believe it goes like this: suppose we have a package with libltdl. If the user does --without-included-ltdl then I believe `-Ilibltdl' and such paths get still added to includes, which is wrong. I don't remember from memory whether that was for subpackage libltdl, or for nonrecursive, or for recursive. Sorry. Ahh, and there was another one: the breakage on need_lib_prefix systems. I think we did not mark it release-blocking, but I still would like to test Pierre's patch extensively and use it if it turns out good: otherwise libltdl will be completely useless on e.g. BeOS. > > - AC_PROG_SED may not be AC_DEFUNed (for aclocal < 1.6?), and > > LT_AC_PROG_SED should be catered for. > > D'oh! I have a patch for this already :-/ I'll post it presently. Good. > > - Makefile.am rules somewhere use GNU make 3.80 features. I have > > encountered many difficulties preventing autotools reruns on other > > systems, and am quite fed up with hunting these down. > > :-( I haven't tripped over those yet. Well, to tell you the truth, I don't actually _know_ what the problem is. I'd have posted or fixed it already then. > > - I have a pending Solaris/whole_archive_flag_spec patch, fixing a > > regression, and to make libtool work on Solaris 10. > > Cool! Please add an entry to the RoadMap. I hope to post the actual patch today. I also expect it to pass review quickly. ;-) > > You webpage does not seem accessible at the moment. > > Yeah, my ISP seems to give me 10 min outages once or twice a week... or else > my new modem takes that long to notice the dropped connection from the > ISP end and redial. Sorry about that :-( No problem. I must've just been lucky to hit that. > > And I have several more tests which I would like to write or have > > already started. For example: I would like comprehensive exposure of -L > > path issues in order to fix the OpenBSD link `-L path order issue' right, > > so that it does not turn into another regression on another system. > > Okay. Adding tests at any time is fine by me. Cool. > > I know you would rather release. There is a trade off: better test > > exposure vs. release delay. My being fed up with working on bootstrap > > and similar issues that were mostly introduced by the great code > > reorganizations, and also there being very few test suite contributors > > and people working on bug reports, has led me to work on the former. > > NP. However, there is plenty to be said for letting the community > tackle some of the testing. Although we need to show diligence and not > release with gaping bugs, a mostly good 2.0.0 release will provoke a > huge amount of feedback and testing that we can funnel into a speedy > 2.0.2. I'd hate for you to burn yourself out looking for corner cases, > especially when much of that work will be done by the community post- > release anyway. We should probably work a bit on feedback documentation. The rate of users for which the first reply is "please post this and that as well" is still a bit high. I must admit being not too good at working on documentation > > Libtool will only get consistently better with a testsuite that exposes > > much more issues. And if you then keep to adding features only with > > comprehensive test exposure already (which static.at probably isn't for > > the patch at stake here), then adding features to libtool won't > > destabilize it much. > > ACK. I think we can be justifiably proud of the huge improvements we've > brought to the new testsuite in the last 18 months. :) I think with about 10-20 times as much test exposure we can have almost well-defined semantics in libtool. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool