[sr #110214] autoreconf passes -Wcross to aclocal/automake but they don't support that

2020-09-24 Thread Zack Weinberg 
Update of sr #110214 (project autoconf):

Priority:   1 - Later => 5 - Normal 
  Status:   Confirmed => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Fixed in edcb0925a54cc7bd96e444925aa8fa1e9294b713.

Warning categories are now in sync between trunk autoconf and trunk automake;
autoreconf passes down warning options in a way that will cause unknown
warning categories to be ignored by tools that don't support them; and in
trunk autoconf and automake, an unknown warning category on the command line
will never be treated as a hard error.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110285] Probes for C++11 and C11 are too slow

2020-09-24 Thread Zack Weinberg 
Update of sr #110285 (project autoconf):

  Status:  Ready For Test => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I'm going to mark this as fixed, but please don't hesitate to reopen if
AC_PROG_CXX is still too slow for you.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

2020-09-24 Thread Zack Weinberg 
Follow-up Comment #2, sr #110312 (project autoconf):

Could you please construct and send us a minimal configure.ac that reproduces
this behavior?  Also, it would be helpful to see the output of 

find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \) -ls

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

2020-09-24 Thread Zack Weinberg 
Follow-up Comment #3, sr #110312 (project autoconf):

The output of these commands would also be really helpful:

nm --defined-only /usr/lib64/libfl.a
nm --dynamic --defined-only /usr/lib64/libfl.so

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

2020-09-24 Thread Tomasz Kłoczko 
Follow-up Comment #4, sr #110312 (project autoconf):


[comment #2 comment #2:]
> Could you please construct and send us a minimal configure.ac that
reproduces this behavior?  Also, it would be helpful to see the output of 
> 
> find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \) -ls

[root@barrel SRPMS]# find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \)
-ls
  7281276 24 -rw-r--r--   1 root root21270 Sep 15 20:57
/usr/lib64/libfl.a


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

2020-09-24 Thread Tomasz Kłoczko 
Follow-up Comment #5, sr #110312 (project autoconf):


[comment #3 comment #3:]
> The output of these commands would also be really helpful:
> 
> nm --defined-only /usr/lib64/libfl.a
> nm --dynamic --defined-only /usr/lib64/libfl.so

[root@barrel SRPMS]# nm --defined-only /usr/lib64/libfl.a

libmain.o:
 T main

libyywrap.o:
 T yywrap


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110306] Upstream: netbsd/patch-aa

2020-09-24 Thread Zack Weinberg 
Update of sr #110306 (project autoconf):

  Status:None => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Verified that 2.69c successfully detects alloca on NetBSD 9.0, with no
additional code changes required.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #109513] Release Autoconf 2.70

2020-09-24 Thread Zack Weinberg 
Follow-up Comment #3, sr #109513 (project autoconf):

Status update: The second beta, Autoconf 2.69c, has been released:
https://lists.gnu.org/archive/html/autoconf/2020-09/msg6.html

The plan is to make the final release of Autoconf at the end of October.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110317] Upstream: oe/autotest-automake-result-format.patch

2020-09-24 Thread Zack Weinberg 
URL:
  

 Summary: Upstream: oe/autotest-automake-result-format.patch
 Project: Autoconf
Submitted by: zackw
Submitted on: Thu 24 Sep 2020 06:36:37 PM UTC
Category: None
Priority: 5 - Normal
Severity: 1 - Wish
  Status: Need Info
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

OpenEmbedded is carrying a patch to add an option to autotest scripts that
changes their output format to match the output of automake test suites.  This
was presumably easier than teaching some higher-level script to parse both
formats.  Reasonable enhancement request but not for 2.70, and I think we
should have a discussion with the automake team about converging automake test
support with autotest.

The switch they added is spelled -A / --am-fmt.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110317] Upstream: oe/autotest-automake-result-format.patch

2020-09-24 Thread Zack Weinberg 
Update of sr #110317 (project autoconf):

Priority:  5 - Normal => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110308] Upstream: yocto/autoreconf-exclude.patch

2020-09-24 Thread Zack Weinberg 
Update of sr #110308 (project autoconf):

Priority:  5 - Normal => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110307] Upstream: netbsd/patch-lib_autoconf_fortran.m4

2020-09-24 Thread Zack Weinberg 
Update of sr #110307 (project autoconf):

Priority:  5 - Normal => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110318] autoreconf: support libtoolize being named glibtoolize

2020-09-24 Thread Zack Weinberg 
URL:
  

 Summary: autoreconf: support libtoolize being named
glibtoolize
 Project: Autoconf
Submitted by: zackw
Submitted on: Thu 24 Sep 2020 06:55:29 PM UTC
Category: None
Priority: 5 - Normal
Severity: 1 - Wish
  Status: Need Info
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Circa autoconf 2.61, Gentoo started carrying a patch to autoreconf that
changes the default name for the libtoolize helper program from 'libtoolize'
to 'glibtoolize'.

An unconditional change is not appropriate for upstream, but it might be
reasonable to make autoreconf try _both_ names for that helper program. 
However, to do that cleanly would require a lot of surgery, and then should we
support a 'g' prefix on _all_ the tools?

Revisit after 2.70. 




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110318] autoreconf: support libtoolize being named glibtoolize

2020-09-24 Thread Zack Weinberg 
Update of sr #110318 (project autoconf):

Priority:  5 - Normal => 1 - Later  

___

Follow-up Comment #1:

2.61 was a long time ago.  I'm wondering if Gentoo still ships 'glibtoolize'
and not 'libtoolize'.  If it doesn't, this change is only weakly motivated.

Note that one can set the environment variable LIBTOOLIZE to override the name
of libtoolize at runtime (and likewise for _all_ the tools autoreconf runs).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

2020-09-24 Thread Zack Weinberg 
Update of sr #110267 (project autoconf):

Priority:  5 - Normal => 1 - Later  
  Status: In Progress => Need Info  

___

Follow-up Comment #5:

The Make-related failures were fixed in
c42dd55ddd598b45664899bfc171c13945a77c0c and
1a5ed4566952f5b2ad854939357ff4b6ec2de180 .

I believe the only remaining problem is with OpenMP detection sometimes
leaving a file named `penmp` in the build directory.  That's a
shouldn't-ever-happen condition that I can't make happen myself; without a
reliable way to reproduce it I'm not going to be able to do anything about it.
 I'm going to leave this bug open for now but mark it "need info" and "later".

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

2020-09-24 Thread Zack Weinberg 
Follow-up Comment #6, sr #110312 (project autoconf):

Thanks.  I understand how your system is set up now, I think.

I still need that minimal configure.ac that reproduces the behavior to make
any progress.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/