Ralf Wildenhues wrote:
Hi Gary,
Hallo Ralf! I think I can discount the following points... plus an okay for your patch... I'll repost 279 later when I've worked out the remaining known bugs.
* Gary V. Vaughan wrote on Thu, Sep 29, 2005 at 11:19:41AM CEST:Ralf Wildenhues wrote:* Gary V. Vaughan wrote on Tue, Sep 27, 2005 at 03:36:43PM CEST:I'm not sure I understand how the aclocal.m4 problem came to be:(The aclocal.m4 problem is orthogonal; let's discuss it elsewhere).Okay. I'd like to fix this in a separate patch.I had previously thought this wasn't a Libtool bug at all..
Agreed. I had thought you were saying it was a bug in my patch. But now that I've looked at it, I think it is either a bug in the package you tested with, or a stale file picked up by mistake somewhere in the bootstrap process.
but there are some more issues. - One is the following (only happens if sub/ltdl does not exist): $ libtoolize --copy --ltdl *snip* libtoolize: copying file `sub/ltdl/config/ltmain.sh' libtoolize: `./ltmain.sh' is already up to date. libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `sub/ltdl/m4'. libtoolize: copying file `sub/ltdl/m4/libtool.m4' /bin/sed: can't read sub/ltdl/m4/argz.m4: No such file or directory /bin/sed: can't read sub/ltdl/m4/ltdl.m4: No such file or directory I believe it is fixed with the following patch. OK to apply?
> > * libtoolize.m4sh (func_included_files): Do not recurse > non-existent files. Looks okay to me.
(By the way, the use of global variables prefixed with my_ really sucks here; I also needed some time to realize that you are actually not using them wrongly.)
Patches always welcome ;-)
- The other problems are connected to the AC_CONFIG_SUBDIRS call in LT_WITH_LTDL, is both wrong there, and does not work. Wrong in the sense that, should non-subpackage libltdl ever work, it should still be possible to use LT_WITH_LTDL (this is what Bob complained about originally). IOW: the decision whether libltdl is to be a subpackage or not must be done in a new macro. And the default should of course be that libltdl _is_ a subpackge (backwards compatible). This may be fixed in an another patch though, it's not a regression introduced by this one.
This patch is just to introduce LT_CONFIG_LTDL_DIR without regressions. The rest of the fixes for LT_WITH_LTDL are yet to be split into separate patches and posted for review.
- The fifth thing is, that I can't seem to disable the included ltdl: --without-included-ltdl --with-included-ltdl=no -without-included-ltdl -with-included-ltdl=no all end up with | checking whether to use included libltdl... yes I believe this worked in the last iteration of your patch.
The previous iteration was checking for lt_dlcaller_register which is a different API to what we have now. This patch now checks for lt_dlinterface_register, which I guess your installed libltdl doesn't have? For clarity, I've changed the messages to read something like: checking for lt_dlinterface_register in -lltdl... no checking whether to use included libltdl... yes
It's a twisted maze. :-/
That's why it's taken me a month to fix it :-( At least breaking it into pieces for the commit is giving it an excellent review though. Thanks! 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