[sr #108503] Running autoscan in a directory with ltmain.sh produces conflicting warnings with libtoolize about AC_PROG_RANLIB

Follow-up Comment #2, sr #108503 (project autoconf): Filed bug #110261 on Libtool. ___ Reply to this item at:

[sr #108503] Running autoscan in a directory with ltmain.sh produces conflicting warnings with libtoolize about AC_PROG_RANLIB

e been before the beginning of the VCS history in 2001, though.) If I manually change _LT_CMD_OLD_ARCHIVE to do AC_REQUIRE([AC_PROG_RANLIB]) instead of what it does, then autoscan stops suggesting the addition of AC_PROG_RANLIB. I'll bounce this to the libtool maint

bug in perl autoscan

I just installed autoscan version 2.21 (on guixSD), and it gave me this warning in a recently un-tar-ed linphone.tar.gz directory. #BEGIN_SRC sh autoscan #END_SRC Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked

Re: a bug in autoscan 2.69

ok, thanks for your reply 发自网易邮箱大师 在2017年12月14日 06:49，Eric Blake 写道： On 12/13/2017 03:35 PM, aquanox wrote: > 1 > $ autoscan > Unescaped left brace in regex is deprecated here (and will be fatal in Perl > 5.30), passed through in regex; marked by <-- HERE in m/\${ <-- HERE [

Re: Bug in autogenerated 'autoscan' Perl script

On 12/21/2016 08:36 AM, Eric Blake wrote: > On 12/12/2016 12:07 AM, Ken Cotterill wrote: >>I encountered a bug in the autogenerated 'autoconf-2.69/bin/autoscan' >>script which caused 'make check' to fail on test 503. >>The statement causing the problem is:

Re: Bug in autogenerated 'autoscan' Perl script

On 12/12/2016 12:07 AM, Ken Cotterill wrote: >I encountered a bug in the autogenerated 'autoconf-2.69/bin/autoscan' >script which caused 'make check' to fail on test 503. >The statement causing the problem is: >s/\${[^\}]*}//g; >which was at line 361 in my v

Bug in autogenerated 'autoscan' Perl script

I encountered a bug in the autogenerated 'autoconf-2.69/bin/autoscan' script which caused 'make check' to fail on test 503. The statement causing the problem is: s/\${[^\}]*}//g; which was at line 361 in my version. The diagnostic message was: "Unescaped left brace in

[sr #108503] Running autoscan in a directory with ltmain.sh produces conflicting warnings with libtoolize about AC_PROG_RANLIB

URL: http://savannah.gnu.org/support/?108503 Summary: Running autoscan in a directory with ltmain.sh produces conflicting warnings with libtoolize about AC_PROG_RANLIB Project: Autoconf Submitted by: egallager Submitted on: Thu 13

[PATCH 06/16] build: no more recursion for lib/autoscan subdir

Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- configure.ac | 2 +- lib/Makefile.am | 31 +-- lib/autoscan/Makefile.am | 40 3 files changed, 30 insertions(+), 43 deletions(-) delete mode

Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

(or another) implementation. I believe this can be fixed by simply omitting AC_FUNC_REALLOC (on the premise that realloc(p, 0) is never used). The macro was originally added to configure.in on the sug- gestion of autoscan which basically means that in a few years some well-meaning developer

Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

believe this can be fixed by simply omitting AC_FUNC_REALLOC (on the premise that realloc(p, 0) is never used). The macro was originally added to configure.in on the sug- gestion of autoscan which basically means that in a few years some well-meaning developer will probably re-run auto

Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

On Mon, 20 Feb 2012, Tim Landscheidt wrote: So is there a way to advise autoscan that it shouldn't suggest AC_FUNC_REALLOC? Another (human) solution would of course be to add appropriate comments to configure.in and hope that they will be read, but I'd prefer something more robust

Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

On 02/20/2012 10:01 AM, Bob Friesenhahn wrote: My proposal is to never run autoscan. That's what *I* do. But if you really want to run it, I suppose you can fool it, e.g.,: q = realloc /* Pacify autoscan, since 'newsize' can't be zero. */ (p, newsize); Ouch! Now I'd better go hide under

Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

including gnulib's (or another) implementation. I believe this can be fixed by simply omitting AC_FUNC_REALLOC (on the premise that realloc(p, 0) is never used). The macro was originally added to configure.in on the sug- gestion of autoscan which basically means that in a few years some well

Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

Eric Blake ebl...@redhat.com writes: The macro was originally added to configure.in on the sug- gestion of autoscan which basically means that in a few years some well-meaning developer will probably re-run auto- scan, re-add the macro and the bug will re-appear. Autoscan is primarily

newbie - autoscan for f90

Hello autoconf community, I am a newbie to autoconf so I am sorry in advance for my basics questions I am trying to swicth my existing config to an autoconf config. I tried to run autoscan in my src directory but it is not finding any of my f90 files... From what the verbose mode tells

Re: newbie - autoscan for f90

On 01/12/2011 03:11 PM, Eve-Marie Devaliere wrote: Hello autoconf community, I am a newbie to autoconf so I am sorry in advance for my basics questions I am trying to swicth my existing config to an autoconf config. I tried to run autoscan in my src directory but it is not finding any

Re: autoscan

Hi Russell, * Russell Shaw wrote on Sun, Mar 21, 2010 at 06:19:07AM CET: I ran autoscan and it gives: configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:1601 So i added AC_PROG_RANLIB and ran autoreconf and now it says: libtoolize: `AC_PROG_RANLIB' is rendered obsolete

autoscan

Hi, I ran autoscan and it gives: configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:1601 So i added AC_PROG_RANLIB and ran autoreconf and now it says: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4

Autoscan and automake

Why doesn't autoscan output the AM_INIT_AUTOMAKE macro into configure.scan when it detect Makefile.am, but does output AC_CONFIG_FILES([Makefile]), even when Makefile doesn't exist, but only Makefile.am does? ___ Autoconf mailing list Autoconf@gnu.org

Re: Autoscan and automake

On Wed, Feb 24, 2010 at 10:43 AM, Eric Blake ebl...@redhat.com wrote: According to NightStrike on 2/24/2010 8:37 AM: Why doesn't autoscan output the AM_INIT_AUTOMAKE macro into configure.scan when it detect Makefile.am, but does output AC_CONFIG_FILES([Makefile]), even when Makefile doesn't

Re: Autoscan and automake

-headers  mingw-w64-tools [trunk]$ autoscan [trunk]$ ls AUTHORS       configure.scan  COPYING.MinGW-w64          DISCLAIMER  Makefile.am    mingw-w64-doc      mingw-w64-libraries autoscan.log  COPYING         COPYING.MinGW-w64-runtime  DISCLAIMER.PD  mingw-w64-crt  mingw-w64-headers  mingw-w64-tools

Re: AC_PREREQ comes first in autoscan

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 9/1/2009 11:38 AM: Hello, * NightStrike wrote on Tue, Sep 01, 2009 at 06:19:07PM CEST: This macro is the only macro that may be used before AC_INIT, This isn't even true. AC_DEFUN and m4_define, as well as

Re: AC_PREREQ comes first in autoscan

On Fri, Sep 4, 2009 at 8:22 AM, Eric Blakee...@byu.net wrote: Yes, indeed.  Pushing this (NightStrike, let me know if you'd rather have a real name instead of a pseudonym in THANKS): I prefer anonymity :) ___ Autoconf mailing list Autoconf@gnu.org

Re: AC_PREREQ comes first in autoscan

, and sorry for pushing back all my pending autotools stuff. s/autoupdate/autoscan/ btw. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

AC_PREREQ comes first in autoscan

Using autoconf 2.63 and autoscan, my automatically generated configure.scan has AC_PREREQ as the first macro in the file, and AC_INIT second. The autoconf manual has this to say about it: This macro is the only macro that may be used before AC_INIT, but for consistency, you are invited not to do

Re: AC_PREREQ comes first in autoscan

description of what the text you quoted really wanted to say). but for consistency, you are invited not to do so. If the manual says please don't do it, why does autoscan do it? I have no idea. Both code and manual have been like that for more than seven years ... Cheers, Ralf

Re: underquoted autoscan output

Hello, AC_PREREQ(2.61) Should that be AC_PREREQ([2.61])? yes, you are right. I have fixed it in the development version of Autoconf, see the attched patch. From: Stepan Kasal [EMAIL PROTECTED] Date: Wed, 2 Jul 2008 15:38:24 +0200 Subject: [PATCH] Add quotes to the header of autoscan-generated

underquoted autoscan output

I'm curious about the fact that when I run autoscan, it generates a configure.scan with the line: AC_PREREQ(2.61) Should that be AC_PREREQ([2.61])? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: bug-report: autoscan generating wrong macro call

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John Calcote on 3/18/2008 7:41 PM: | Hi - | | autoscan (v 2.61) seems to be generating a call to AC_CONFIG_HEADER | (singular). I believe this macro is out of date (although apparently | still supported). The correct call should

autoscan yields AC_CHECK_LIB([oad],[main])

Running autoscan recommands this line in configure.scan: AC_CHECK_LIB([oad], [main]) I can't seem to find that library, and I can't tell from autoscan.log what function makes it think that this liboad library is needed. How do I tell? $ grep autoscan autoscan.log autoscan: warning: missing

Re: autoscan yields AC_CHECK_LIB([oad],[main])

NightStrike wrote: Running autoscan recommands this line in configure.scan: AC_CHECK_LIB([oad], [main]) I can't seem to find that library, and I can't tell from autoscan.log what function makes it think that this liboad library is needed. How do I tell? All that means is that autoscan

autoscan shouldn't recommend obsolescent macros

], [AC_HEADER_STAT]) AC_DEFUN([AC_HEADER_STAT], [AC_CACHE_CHECK(whether stat file-mode macros are broken, ac_cv_header_stat_broken, @@ -628,28 +617,6 @@ fi # AC_HEADER_STDC # -- -# FIXME: I find this list very strange. It comes from the original -# autoscan list, but I don't think

Re: Autoscan fails cryptically on our code

Hi Richard, * Richard Brooksby wrote on Thu, May 11, 2006 at 07:14:19PM CEST: Following the instructions in the Goat Book at http:// sources.redhat.com/autobook/autobook/autobook_241.html#SEC241 I ran autoscan on our source tree, which is visible at http:// www.ravenbrook.com/project/mps

Autoscan fails cryptically on our code

Following the instructions in the Goat Book at http:// sources.redhat.com/autobook/autobook/autobook_241.html#SEC241 I ran autoscan on our source tree, which is visible at http:// www.ravenbrook.com/project/mps/master/code/. It said: [EMAIL PROTECTED] autoscan -v autoscan: srcdir

Re: Fix autoscan to not search config-subdirs

configure subdirectory trees. * tests/autoscan.at (autoscan): Unmark xfail. + # Skip config subdirs. + if (defined $subdir_regex + $File::Find::name =~ /^\.\/($subdir_regex)$/o) + $subdir_regex = join ('|', map { quotemeta } @subdir); As a matter of Perl Fu, I would build

Re: Fix autoscan to not search config-subdirs

Ralf Wildenhues [EMAIL PROTECTED] writes: Also, it would be nice if somebody could look over my weak perl fu. Alas, it won't be me: I switched from Perl to Python long ago, and my Perl is so rusty that about all I can do with it is make red ochre.

Fix autoscan to not search config-subdirs

The patch below fixes the autoscan buglet reported a while ago. So, if the user already has a working configure.ac, autoscan won't add unnecessary checks of AC_CONFIG_FILES for stuff found in subpackages. If configure.ac is present but not parseable (due to syntax errors, for example

Re: autoscan failure: do not walk subpackages

Hello, On Tue, Aug 16, 2005 at 07:41:38AM +0200, Ralf Wildenhues wrote: Oops, I must've overlooked that as well as the old FSF address done. I also fixed copyright years list in sute.at. (can you tell how long this patch has been sitting around here?). Since April 21? Stepan

Re: autoscan failure: do not walk subpackages

On Mon, Aug 15, 2005 at 06:21:16PM +0200, Ralf Wildenhues wrote: * tests/autoscan.at (autoscan): New file. Test autoscan traversal of subpackages Makefile's. Reported against Libtool by Gideon Go [EMAIL PROTECTED]. Applied. Thanks. I did finish the change log entry

Re: autoscan failure: do not walk subpackages

Hi Noah, * Noah Misch wrote on Tue, Aug 16, 2005 at 01:50:15AM CEST: On Mon, Aug 15, 2005 at 06:21:16PM +0200, Ralf Wildenhues wrote: * tests/autoscan.at (autoscan): New file. Test autoscan traversal of subpackages Makefile's. Reported against Libtool by Gideon Go

Problems running autoscan

$ autoscan autom4te: configure.ac: no such file or directory autoscan: /usr/bin/autom4te failed with exit status: 1 This is a puzzling message, since the purpose of autoscan, as I understand it, is to produce a file which, if blessed by me, becomes configure.ac. So why would it complain

Re: Problems running autoscan

Ross Boylan [EMAIL PROTECTED] writes: Does this just indicate that autoscan does additional stuff for people who have configure.ac, or is something wrong? $ autoscan --version autoscan (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Running on Debian GNU/Linux

RE: Problems running autoscan

-Original Message- From: [EMAIL PROTECTED] [mailto:autoconf- [EMAIL PROTECTED] On Behalf Of Ben Pfaff Sent: vendredi 3 décembre 2004 00:34 To: [EMAIL PROTECTED] Subject: Re: Problems running autoscan Ross Boylan [EMAIL PROTECTED] writes: Does this just indicate that autoscan

Re: autoscan and AC_CHECK_DECLS

In article [EMAIL PROTECTED], Mike Castle [EMAIL PROTECTED] wrote: Ok. Strange interactions with autoscan and autom4te.cache. And a possible bug in autoscan otherwise. Hmmm. The following patch seems to improve my system a little bit. But I'm not certain if they are correct. Looks like

autoscan and AC_CHECK_DECLS

Ok. Strange interactions with autoscan and autom4te.cache. And a possible bug in autoscan otherwise. Starting in a clean directory: nexus@thune[10:06pm]~/foo(203) ls nexus@thune[10:06pm]~/foo(204) echo int sys_siglist; a.c nexus@thune[10:06pm]~/foo(205) echo int st_blksize; a.c nexus@thune

autoscan generates the new macros

I have made some changes in perl script autoscan. I have added new properties 1. have been added new three command line parameters: 'package name', 'package version' and 'bug report address'. These parameters fill the three parameters in the macro AC_INIT. 2. has been changed the function

Problem with autoscan

I was about to address Paul's suggestion for sys/types.h when I saw that there were duplicate entries in some of the autoscan tables. In order to catch them, I added this: Index: autoscan.in === RCS file: /cvs/autoconf/autoscan.in

Re: autoscan - make missing macro output readable

Paul Martinolich [EMAIL PROTECTED] writes: The autoscan from autoconf-2.49c has ugly output for the missing macro warning. $ ../../devel/bin/autoscan.orig warning: missing AC_TYPE_PID_T wanted by: libsdptk/src/PGS_IO_Gen_Temp_Reference.c:675 libsdptk/src/PGS_SMF_Comp.c:5336 libsdptk/src

autoscan - make missing macro output readable

The autoscan from autoconf-2.49c has ugly output for the missing macro warning. $ ../../devel/bin/autoscan.orig warning: missing AC_TYPE_PID_T wanted by: libsdptk/src/PGS_IO_Gen_Temp_Reference.c:675 libsdptk/src/PGS_SMF_Comp.c:5336 libsdptk/src/PGS_SMF_Comm.c:139 libsdptk/smfcompile

Re: Improving autoscan: help!

Hello, Akim! Running autoscan on (configured) CVS Automake gives: warning: missing AC_CHECK_HEADERS([malloc.h]) wanted by: ansi2knr.c:157 warning: missing AC_CHECK_HEADERS([stdlib.h]) wanted by: ansi2knr.c:150 warning: missing AC_CHECK_HEADERS([string.h]) wanted by: ansi2knr.c:128