Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 08:10, Bob Friesenhahn wrote: > but with FreeBSD 8.0: > > > 3 of 96 tests failed > (10 tests were not run) > Please report to bug-libt...@gnu.org > > > I found that the file tests/testsuite.log was from a very old run. So I > removed the build tree and did everything from scratch. No > tests/testsuite.log file was produced. This similar failure was counted > three times: > > FAIL: tests/depdemo-make.test > FAIL: tests/depdemo-make.test > FAIL: tests/depdemo-make.test Old tests results are not logged, you need to run 'VERBOSE=1 make check TESTS='prerequisite tests from the failing batch depedemo-make.test' to see what is going wrong here. If you have time to bisect your way to the commit that introduced the failure that would help narrow it down some too. I don't think the changes I've committed in the last couple of days should cause this failure, so it might have been around a little longer... Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 05:39, Bob Friesenhahn wrote: > On Wed, 30 Jun 2010, Gary V. Vaughan wrote: >> >> I can't reproduce this one. But that might be something to do with the fix >> I just committed... > > I am dutifully re-running the tests with your latest patch > (d8bdf9339ba7de82f40c49705650506e0cc3f979). Early impressions are that there > are far fewer failures than before under Solaris 10 but the "stress" tests > are still running. This one is still new though: > > 6: enhanced shell option appending FAILED > (getopt-m4sh.at:183) I can't reproduce. Are you sure you got a new libtool generated by this test-run? That test is copying func_append from libtool into tests/testsuite.dir/006/options and running a test to make sure that it works correctly. What does tests/testsuite.dir/006/options contain? What is the error message in tests/testsuite.dir/006/testsuite.log? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: libtool head fails under Solaris 10 & FreeBSD
With OS-X Leopard PowerPC: ## - ## ## Test results. ## ## - ## 100 tests behaved as expected. 15 tests were skipped. but with FreeBSD 8.0: 3 of 96 tests failed (10 tests were not run) Please report to bug-libt...@gnu.org I found that the file tests/testsuite.log was from a very old run. So I removed the build tree and did everything from scratch. No tests/testsuite.log file was produced. This similar failure was counted three times: FAIL: tests/depdemo-make.test FAIL: tests/depdemo-make.test FAIL: tests/depdemo-make.test Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool head fails under Solaris 10 & FreeBSD
On Wed, 30 Jun 2010, Gary V. Vaughan wrote: 26 of 53 tests failed (53 tests were not run) Please report to bug-libt...@gnu.org I can't reproduce this one. But that might be something to do with the fix I just committed... Now Solaris 10 produces just 3 unexpected failures, which is one more than normal. The tests/testsuite.log file is attached. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ testsuite.log.gz Description: Binary data
Re: libtool head fails under Solaris 10 & FreeBSD
On Wed, 30 Jun 2010, Gary V. Vaughan wrote: I can't reproduce this one. But that might be something to do with the fix I just committed... I am dutifully re-running the tests with your latest patch (d8bdf9339ba7de82f40c49705650506e0cc3f979). Early impressions are that there are far fewer failures than before under Solaris 10 but the "stress" tests are still running. This one is still new though: 6: enhanced shell option appending FAILED (getopt-m4sh.at:183) I don't have access to FreeBSD 8.0, could you retest, and show verbose logs of the fails if they haven't gone away please? Yes, sir. Will do. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool head fails under Solaris 10 & FreeBSD
Hi Bob, On 30 Jun 2010, at 01:40, Bob Friesenhahn wrote: > As a heads-up, yesterday libtool was passing the normal number of tests > (usually fails 2) under Solaris 10. With latest changes from today, libtool > tests are failing badly: > > > 26 of 53 tests failed > (53 tests were not run) > Please report to bug-libt...@gnu.org > I can't reproduce this one. But that might be something to do with the fix I just committed... > Usually the test suite works perfectly under FreeBSD 8.0 but it is failing 3 > tests now: > > > 3 of 96 tests failed > (10 tests were not run) > Please report to bug-libt...@gnu.org > I don't have access to FreeBSD 8.0, could you retest, and show verbose logs of the fails if they haven't gone away please? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/29/2010 12:35 PM, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 08:30:43PM CEST:
>> On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
>>> I think m4sh can simply use code like
>>>
>>> if ( eval '$smart_works' ) >/dev/null 2>&1; then
>>>func_foo () { smart code; }
>>> else
>>>func_foo () { safe code; }
>>> fi
>>>
>>> for code run a handful of times, without need for extra m4 magic, it's
>>> just that libtool is easily run hundreds of times in a typical large
>>> software build so it warrants optimization.
>>
>> In that case might the retarded shell choke and die as it parses 'smart
>> code;'?
>
> Good point. IIRC gnulib-tool uses e.g.,
> eval 'func_foo () { smart code; }'
That's how m4sh already does it for AS_VAR_APPEND (take a look at
practically any configure script built with recent autoconf):
if (eval "as_var=1; as_var+=2; test x\$as_var = x12") 2>/dev/null; then :
eval 'as_fn_append ()
{
eval $1+=\$2
}'
else
as_fn_append ()
{
eval $1=\$$1\$2
}
fi # as_fn_append
which works just fine with retarded Solaris /bin/sh.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
libtool head fails under Solaris 10 & FreeBSD
As a heads-up, yesterday libtool was passing the normal number of tests (usually fails 2) under Solaris 10. With latest changes from today, libtool tests are failing badly: 26 of 53 tests failed (53 tests were not run) Please report to bug-libt...@gnu.org Usually the test suite works perfectly under FreeBSD 8.0 but it is failing 3 tests now: 3 of 96 tests failed (10 tests were not run) Please report to bug-libt...@gnu.org Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 08:30:43PM CEST:
> On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
> > I think m4sh can simply use code like
> >
> > if ( eval '$smart_works' ) >/dev/null 2>&1; then
> >func_foo () { smart code; }
> > else
> >func_foo () { safe code; }
> > fi
> >
> > for code run a handful of times, without need for extra m4 magic, it's
> > just that libtool is easily run hundreds of times in a typical large
> > software build so it warrants optimization.
>
> In that case might the retarded shell choke and die as it parses 'smart
> code;'?
Good point. IIRC gnulib-tool uses e.g.,
eval 'func_foo () { smart code; }'
or eval inside the smart code, to get around that where needed.
> I don't actually know whether retarded shells mostly ignore the code
> during parsing, and can be reliably fed what they would otherwise consider
> garbage as long they are never instructed to execute the garbage... but
> it seems like something we'd need to be very careful about.
Just trying it with Solaris sh and maybe a couple of the other vendor
systems helps, these things are easily sorted out with your level of
system access.
Cheers,
Ralf
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hallo Ralf,
On 30 Jun 2010, at 01:22, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 05:09:29PM CEST:
>> On 29 Jun 2010, at 21:03, Eric Blake wrote:
>>> Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
>>> support, but that will have to wait until after autoconf 2.66.
>>
>> While that might turn out to be useful elsewhere (I wrote a quick esyscmd
>> to check for the things that Libtool needs, so it's not difficult in
>> principle), it's not useful for Autotools as things stand right now, since
>> m4sh generally runs on the developers machine to generate scripts that are
>> shipped and executed on the user's shell.
>>
>> It might be nice if a future Autotools does the m4sh->sh generation from
>> some AC_macros that expand at distribution time but are still executed on
>> the user's machine - but then we are requiring that the user have modern
>> GNU m4 available, which might not be smart.
>
> I think m4sh can simply use code like
>
> if ( eval '$smart_works' ) >/dev/null 2>&1; then
>func_foo () { smart code; }
> else
>func_foo () { safe code; }
> fi
>
> for code run a handful of times, without need for extra m4 magic, it's
> just that libtool is easily run hundreds of times in a typical large
> software build so it warrants optimization.
In that case might the retarded shell choke and die as it parses 'smart
code;'?
I don't actually know whether retarded shells mostly ignore the code
during parsing, and can be reliably fed what they would otherwise consider
garbage as long they are never instructed to execute the garbage... but
it seems like something we'd need to be very careful about.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: checking for header/library mismatch, rpath problem?
[ please elide autoconf@ from followups, thanks ] Hi Peter, * Peter Breitenlohner wrote on Tue, Jun 29, 2010 at 10:36:32AM CEST: > Here the macro we are using in TeX Live for such tests (C and C++). Our > purpose is to test properties of libraries that can be either > (1) uninstalled libtool libraries already built when this configure runs, > or (2) installed libraries -- libtool or not. Good stuff. Are you willing to turn this into a patch against git Libtool? Otherwise we'll put it on our todo list. You might need to sign papers though, at least if you're adding test coverage. A general set of macros could be LT_USE_LIBTOOL_PUSH and _POP and could adjust the AC_LANG setting of all configured libtool tags; the pop macro could reset them to their original state afterwards; that would help for encapsulation. Or some better names I can't think of right now. > # _KPSE_USE_LIBTOOL() > # --- > AC_DEFUN([_KPSE_USE_LIBTOOL], > [## $0: Generate a libtool script for use in configure tests > AC_PROVIDE_IFELSE([LT_INIT], , > [m4_fatal([$0: requires libtool])])[]dnl > LT_OUTPUT > m4_append([AC_LANG(C)], > [ac_link="./libtool --mode=link --tag=CC $ac_link" > ])[]dnl > AC_PROVIDE_IFELSE([AC_PROG_CXX], > [m4_append([AC_LANG(C++)], > [ac_link="./libtool --mode=link --tag=CXX $ac_link" > ])])[]dnl > AC_LANG(_AC_LANG)[]dnl > ]) # _KPSE_USE_LIBTOOL Thanks, Ralf
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Gary,
* Gary V. Vaughan wrote on Tue, Jun 29, 2010 at 05:09:29PM CEST:
> On 29 Jun 2010, at 21:03, Eric Blake wrote:
> > Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
> > support, but that will have to wait until after autoconf 2.66.
>
> While that might turn out to be useful elsewhere (I wrote a quick esyscmd
> to check for the things that Libtool needs, so it's not difficult in
> principle), it's not useful for Autotools as things stand right now, since
> m4sh generally runs on the developers machine to generate scripts that are
> shipped and executed on the user's shell.
>
> It might be nice if a future Autotools does the m4sh->sh generation from
> some AC_macros that expand at distribution time but are still executed on
> the user's machine - but then we are requiring that the user have modern
> GNU m4 available, which might not be smart.
I think m4sh can simply use code like
if ( eval '$smart_works' ) >/dev/null 2>&1; then
func_foo () { smart code; }
else
func_foo () { safe code; }
fi
for code run a handful of times, without need for extra m4 magic, it's
just that libtool is easily run hundreds of times in a typical large
software build so it warrants optimization.
Cheers,
Ralf
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Eric,
On 29 Jun 2010, at 21:03, Eric Blake wrote:
> On 06/29/2010 12:52 AM, Gary V. Vaughan wrote:
> i=$((i+1))
>>
>> I think we can't rely on the availability of $((expr)) :(
>
> Is there any shell that supports XSI but not $(()), seeing as how both
> are mandated by POSIX? But we've already come up with better
> alternatives, so this is a moot point.
I have no idea, but you make a good point. Currently libtool is testing
for every non-basic feature it uses - which is still a giant leap forward
from just a few years ago where we were still afraid to use functions!
>> However, I think that will be considerably slower than the ${1:0:2}/${1:2}
>> approach. But we're probably talking microseconds... so I'm open to
>> advice on whether to use bash/ksh variable substrings exclusively (as per
>> current master); XSI exclusively (although we make heavy use of += already
>> if it is available, so not really exclusively); or to prefer substring
>> syntax over the XSI syntax if either or both are available, falling back
>> on sed if necessary?
>
> Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
> support, but that will have to wait until after autoconf 2.66.
While that might turn out to be useful elsewhere (I wrote a quick esyscmd
to check for the things that Libtool needs, so it's not difficult in
principle), it's not useful for Autotools as things stand right now, since
m4sh generally runs on the developers machine to generate scripts that are
shipped and executed on the user's shell.
It might be nice if a future Autotools does the m4sh->sh generation from
some AC_macros that expand at distribution time but are still executed on
the user's machine - but then we are requiring that the user have modern
GNU m4 available, which might not be smart.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/29/2010 12:52 AM, Gary V. Vaughan wrote:
i=$((i+1))
>
> I think we can't rely on the availability of $((expr)) :(
Is there any shell that supports XSI but not $(()), seeing as how both
are mandated by POSIX? But we've already come up with better
alternatives, so this is a moot point.
> However, I think that will be considerably slower than the ${1:0:2}/${1:2}
> approach. But we're probably talking microseconds... so I'm open to
> advice on whether to use bash/ksh variable substrings exclusively (as per
> current master); XSI exclusively (although we make heavy use of += already
> if it is available, so not really exclusively); or to prefer substring
> syntax over the XSI syntax if either or both are available, falling back
> on sed if necessary?
Ultimately, I'd like to fix m4sh to make it easier to probe/require XSI
support, but that will have to wait until after autoconf 2.66.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
Hi Paolo,
On 29 Jun 2010, at 15:21, Paolo Bonzini wrote:
> On 06/29/2010 08:52 AM, Gary V. Vaughan wrote:
>> func_split_short_arg ()
>> {
>> arg="$1"; while test ${#arg} -gt 2; do arg="${arg%?}"; done
>> rest=${1%??}
>> }
>
> What about
>
> func_split_short_arg () {
> rest=${1#??};
> arg=${1%"$rest"};
> }
Perfect! I amended libtool.m4 and pushed, many thanks.
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Add an XSI replacement for func_split_short_opt.
On 06/29/2010 08:52 AM, Gary V. Vaughan wrote:
Well, really the problem is this:
while $# -gt 0; do
opt=$1; shift
case $opt in
-p) opt_p="$1"; shift ;;
-q) opt_q="$1"; shift ;;
-x) opt_x=: ;;
-y) opt_y=: ;;
-p*|-q*) # option args
func_split_short_arg $opt
set dummy $arg "$rest" ${1+"$@"}; shift ;;
-x*|-y*) # non-option args
func_split_short_arg $opt
set dummy $arg -$rest ${1+"$@"}; shift ;;
esac
done
So, we know there will always be at least 3 characters available in $1
by the time we reach func_split_short_arg. Also we don't really discard
the leading '-'. Which means that this works correctly:
func_split_short_arg ()
{
arg="$1"; while test ${#arg} -gt 2; do arg="${arg%?}"; done
rest=${1%??}
}
What about
func_split_short_arg () {
rest=${1#??};
arg=${1%"$rest"};
}
The quoting ensures that it works even if a star is present in $1:
$ func_split_short_arg -X*YZ ; echo $arg; echo $rest
-X
*YZ
$ func_split_short_arg -XYZ ; echo $arg; echo $rest
-X
YZ
Paolo
