Re: rhel8 test failure confirmation?

Mike Frysinger wrote:
> On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
>   
>> Karl Berry wrote:
>>     
>>>     jb> a more thorough test would locate the autom4te script and grep it
>>>     for the perllibdir that was substituted when autoconf was
>>>     configured.
>>>
>>> I guess that would work.
>>>       
>> Challenge accepted.  Here's a refined version:  (lines \-folded for email)
>>
>> if $PERL -I${autom4te_perllibdir:-$(sed -n \
>>               '/autom4te_perllibdir/{s/^.*|| //;s/;$//;s/^.//;s/.$//;p;q}' \
>>             <$(command -v autom4te))} -MAutom4te::FileUtils \
>>          -e 'exit defined $INC{q[Time/HiRes.pm]} ? 0 : 1'; then
>>    # autom4te uses Time::HiRes
>> else
>>    # autom4te does not use Time::HiRes
>> fi
>>     
>
> this doesn't work on systems that wrap `autom4te`.  Gentoo for example wraps
> all autoconf & automake scripts to support parallel installs of different
> versions.  this way we can easily have access to every autoconf version.  we
> got this idea from Mandrake, so we aren't the only ones ;).
>   

If you install a wrapper script, (instead of, for example, making 
autom4te, etc. easily-repointable symlinks), then you must also set 
autom4te_perllibdir in the environment to the appropriate directory when 
building autoconf/automake.  This (with the Gentoo-specific knowledge of 
where the active autom4te is actually located) should be easy to add to 
the ebuild.

If autom4te_perllibdir is set in the environment, its value will be used 
instead of extracting that information from the autom4te script.

> [...]
>
> seems like the only reliable option is to invoke autom4te.
> 	am_autom4te_ver=`$AUTOM4TE --version | sed -n '1{s:.*) ::;p}'
> 	AS_CASE([$am_autom4te_ver],
> 	... do the matching ...
>
> what is the first autoconf release that has the fix ?
>   

The problem with testing autoconf versions for this is that Time::HiRes 
is an *optional* module in Perl.  It was available from CPAN before it 
was bundled with Perl, and distributions technically can *unbundle* it 
from later Perl releases if they want.  The only reliable way to know if 
Time::HiRes is available (without effectively reimplementing Perl's 
module search) is to try to load it.  Autom4te now (correctly) uses 
Time::HiRes if it is available and falls back to Perl builtins if not, 
for any version of Perl.  The best way to check if high-resolution 
timestamps are available to autom4te is to have perl load 
Autom4te::FileUtils and check if that also loaded Time::HiRes.


-- Jacob