Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf!
[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.] > > > > * <!> 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? 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. 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. 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. > > > > * <!> 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. Excellent! >>> 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. Okay, if you think it will save bug-libtool traffic later. Let me review that patch in its own thread first. > I'll await answer on this and update the TODO list then. Cool, thanks! >>> - 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? > 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. Ick. I guess we'll trip over it during pre-release testing. > 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 :-) > 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 NP. I'll take that one. 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). Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature