Re: 279-gary-LT_CONFIG_LTDL_DIR.diff

[Gary V. Vaughan]

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