[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 279-gary-LT_CONFIG_LTDL_DIR.diff
From: |
Gary V. Vaughan |
Subject: |
Re: 279-gary-LT_CONFIG_LTDL_DIR.diff |
Date: |
Thu, 29 Sep 2005 17:32:32 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (X11/20050305) |
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 ())_. address@hidden,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