libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: 333-gary-refactor-LTDL_INIT.patch


From: Ralf Wildenhues
Subject: Re: FYI: 333-gary-refactor-LTDL_INIT.patch
Date: Tue, 8 Jan 2008 08:34:05 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Gary, Bob, Bob,

* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET:
> >
> >Sure you want to disallow users just passing in appropriate CPPFLAGS  
> >and
> >LDFLAGS to find an installed libltdl?  I would count that as an
> >incompatible API change, too.
> 
> CPPFLAGS and LDFLAGS will continue to work as they always have done.  It
> seems far too obvious to mention in the docs though.  I have noticed  
> that many autotools users seem to prefer passing --enable/with-options
> though so I'm providing those too.

Oh, I thought they wouldn't work.  Guess I should have tested that.

> >
> >This fails to mention whether $(LIBLTDL) may be used as a dependency  
> >in,
> >say, libfoo_la_DEPENDENCIES.  The case where it is `-lltdl' is the
> >tricky one, as it leads to a make error, so we may have to introduce
> >another variable?  See M4 build failures on Bob's build farm for an
> >example of this.
> 
> Hmm.  Bummer.  Could you add a test?  Or, Bob, if you could give me
> access to your build logs, I'll look into creating one myself.

Sorry about the confusion.  I meant Bob Proulx, and these buildds:
<http://www.proulx.com/sys/build-daemons/>
Seems the M4 one is off-line ATM.

> >> address@hidden
> >> +If your package is built using the convenience libltdl,  
> >>@var{LIBLTDL}
> >> +will be the pathname for the convenience version of libltdl
> >> +(starting with @address@hidden@}/}) and @var{LTDLINCL} will  
> >>be
> >> address@hidden followed by the directory that contains @file{ltdl.h}
> >> +(starting with @address@hidden@}/}).
> >> +
> >> address@hidden
> >> +If an installable version of the included @code{libltdl} is being
> >> +built, its pathname starting with @address@hidden@}/}, will  
> >>be
> >> +stored in @var{LIBLTDL}, and @var{LTDLINCL} will be set just like  
> >>in
> >> +the case of convenience library.
> >> address@hidden itemize
> >
> >These two paragraphs are factually wrong if top_build_prefix is
> >available (i.e., with new enough Autoconf).
> 
> Oh.  Guess I haven't been paying attention to the Autoconf developments
> for a while then :-(  What should I have written instead?

Well if $top_build_prefix is available, then that will be the start of
the path names for LIBLTDL, instead of $top_builddir/
The difference is that, in case $top_builddir is `.', $top_build_prefix
is empty, which helps non-GNU make as they see `FILE' not `./FILE'
(which isn't the same for them).

This fix is quite new, the Libtool patch is the one right before your
big one.

> >> @@ -617,10 +620,10 @@
> >>        lt_cl_silent=: ;;
> >>
> >>      -*) AC_MSG_ERROR([unrecognized option: $[1]
> >> -Try `$[0] --help' for more information.]) ;;
> >> +Try \`$[0] --help' for more information.]) ;;
> >>
> >>      *) AC_MSG_ERROR([unrecognized argument: $[1]
> >> -Try `$[0] --help for more information.]) ;;
> >> +Try \`$[0] --help' for more information.]) ;;
> >
> >This hunk is completely superfluous.  Backticks get escaped properly
> >automatically with AC_MSG_ERROR.
> 
> Even with old autoconf?

Do we support anything older than 2.58 in practice?

> >> --- /dev/null      1 Jan 1970 00:00:00 -0000
> >> +++ tests/configure-iface.at 6 Jan 2008 16:32:11 -0000
> >
> >> +# TODO: Check that the installed program `main' is linked against  
> >>our libltdl
> >> +AT_CHECK([test -f $prefix/lib/libltdl.la])
> >> +AT_CHECK([test -f $prefix/include/ltdl.h])
> >
> >Yep, that TODO is a rather important test that is missing.  It will be
> >crucial on systems like OpenBSD.
> 
> I'm not sure how to test it though... any thoughts?

As below: build and install a fake libltdl, require failure to link.

> >> +# Remove build files
> >> +for x in .* *; do
> >> +  test $x == _inst || rm -rf $x
> >> +done
> >
> >That doesn't work.  Apart from the quoting errors ("$x"),
> 
> From the line above $x can never be empty (at worst it will be a  
> literal
> '*').

It could contain spaces though.  Yes, highly unlikely.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]