* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 03:43:11PM CET: > > [Is the personal Cc: okay? The list lag is so long that I've gotten into > the habit of Cc:ing you back in so you don't have to wait half a day to > get this.]
Yes, surely. There was one point in time where I fixed my gnu.org subscriptions to do what I want for my mail setup, and since then I could stop bothering about this for mails sent to me. List lag is interesting though: it can vary between several hours and less than a minute within the time frame of 12 hours. I am at a loss how to explain this, maybe it's fast when the US-based spammers go to sleep. ;-> > > > 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? > I originally wrote LT_WITH_LTDL as a convenience wrapper for AC_LIB_LTDL > in CVS M4, and realised that it was useful enough to almost all clients > of libltdl that it should probably belong in the Libtool distribution... > There is definitely a documentation bug (added to RoadMap) that it is > still undocumented. It's not LT_WITH_LTDL that is undocumented. LTDL_INIT is. > The real question then is whether LT_WITH_LTDL alone > should be equivalent to LTDL_CONVENIENCE plus LTDL_INIT (overridable > with LTDL_INSTALLABLE) or whether it should be *in addition* to all that. Right. > I'm leaning toward the former, but either way the current situation of > being like LTDL_INIT plus --with-ltdl processing is counter-intuitive. > I'll post a documentation patch to help us define the semantics clearly, > and then fix the code to implement what we decide upon. Good. > >>> - 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. > > Can you transcribe them to the RoadMap once we've got clarification on > the issue from Bob please? OK. I'll ask him to test again after patch-6 is in (or test myself). > > 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. > > Okay. Is that a long standing bug, or a regression? Please mark the > RoadMap accordingly :-) Well, both. Apparently dlpreloading has never worked on need_lib_prefix systems, so that is long-standing. Now that libltdl requires working dlpreloading, it fails to work completely, while in 1.5.x it at least worked in some cases. From a user POV, that's a regression, from a Libtool developer POV it's long-standing. ;-) > Just discovered yet another in my patch queue (needs another round of > testing before I post): make installcheck currently always fails in > trees that used 'libtoolize --ltdl' in some modes. (Added to RoadMap). OK. Cheers, Ralf