Re: The Universal Source Package: GNU Autoconf Solves Only Part o f the Problem

Bernard Dautrevaux <[EMAIL PROTECTED]> writes: > I'm afraid I (and perhaps others) don't know "stow" :-( could > you enlight= en us? It's GNU software: http://www.gnu.org/software/stow ftp://ftp.gnu.org/pub/gnu/stow -- Can I go now? I have a program I'm working on. from _The

[pmaydell@chiark.greenend.org.uk] Bug#58039: autoconf: AC_EXEEXT incompatible with AC_MINIX, AC_ISC_POSIX?

The following bug was reported against the Debian package for autoconf, presumably version 2.13-20, though the correspondent didn't note that. It seems that it's something that should be considered in upstream, rather than at the Debian level, so I am forwarding it to this list. I'd appreciate i

Re: [pmaydell@chiark.greenend.org.uk] Bug#58039: autoconf: AC_EXEEXT incompatible with AC_MINIX, AC_ISC_POSIX?

Assar Westerlund <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > > Either I'm very confused, or it's not possible to use the autoconf > > tests AC_EXEEXT and AC_MINIX in the same configure.in... To clarify: actually Peter Maydell said

Re: So it seems like AC_C_BIGENDIAN is broken for cross case

[Problem posed is that autoconf fails when detecting endianness for a cross-compiler.] In GNU PSPP I attempt to detect endianness at my program's runtime for the case of a cross-compiler. This might be reasonable in some other cases, too.

[peter@softwolves.pp.se] Bug#62180: autoconf: Does not detect EMX in AC_EXEEXT

Here's a somewhat old bug report that I neglected to forward upstream earlier. This was reported against the Debian GNU/Linux package for 2.13, but appears to be an upstream bug. [snippage below] --- Start of forwarded message --- Subject: Bug#62180: autoconf: Does not detect EMX in AC_E

Re: Autoconf Logo?

Akim Demaille <[EMAIL PROTECTED]> writes: > > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: > > Lars> Should it be a goat? I'm thinking of something to stick on the > Lars> web pages... > > Would be great to have one for Libtool, one for Automake and one for > Autoconf which would compo

typo in acgeneral.m4 (`witout')

This showed up in the Debian package for autoconf. --- autoconf-2.50.orig/acgeneral.m4 +++ autoconf-2.50/acgeneral.m4 @@ -3551,7 +3551,7 @@ [AC_CONFIG_COMMANDS(default, [$2], [$3])])dnl m4_ifval([$1$2$3], [AC_DIAGNOSE([obsolete], - [$0 should be used wito

[Adam Heath ] Bug#98991: AC_COPYRIGHT when used in aclocal.m4 generates incorrect shell code

The following bug was reported against the Debian GNU/Linux package for Autoconf version 2.50. I reproduced it and didn't see any obvious mistakes in the syntax, so I'm passing it on upstream. Thanks, Ben. -- Subject: Bug#9899

AC_TRY_RUN doesn't set $? as documented

The following bug was reported against the Debian package for autoconf 2.13. I was able to reproduce it with autoconf 2.52, using this configure.in fragment: AC_TRY_RUN([int main(void){return 5;}], [echo success], [echo fail: "$?"], [echo cross-compile]) which reports `

[Adam Heath ] Bug#116744: configure --help has incorrectly formatted help

The bug below was reported against version 2.50 of the Debian GNU/Linux package for autoconf. It appears to be in version 2.52 as well. Start of forwarded message Subject: Bug#116744: configure --help has incorrectly formatted help Date: Tue, 23 Oct 2001

Re: Condition evaluation removed

.opengroup.org/onlinepubs/009695399/utilities/export.html "source" is not part of POSIX. -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: autconf, configure & purify...

[ac_cv_use_foo], [ac_cv_use_foo=no])]) Please note that the call to `AS_HELP_STRING' is *unquoted*. It doesn't say why (and I don't know why). -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: autconf, configure & purify...

Eric Blake <[EMAIL PROTECTED]> writes: > According to Ben Pfaff on 10/23/2008 10:06 PM: >>> AC_ARG_ENABLE([purify], >>> [AS_HELP_STRING([--enable-purify], [build with Purify [default=no]]), >> >> The Autoconf manual explicitly recommends underquoting >

Re: Which header a symbol is declared in (AC_CHECK_DECLS) ?

asonable reason to #include , although Konstantin may not need those functions anyhow. -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Autotest: how stable?

o the Autoconf mailing lists. How concerned should I be in practice about Autotest changes? Is there any chance that Autotest might be "frozen" or "stabilized" soon? -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu

Re: Autotest: how stable?

Eric Blake writes: > According to Ben Pfaff on 7/16/2009 10:19 PM: >> How concerned should I be in practice about Autotest changes? Is >> there any chance that Autotest might be "frozen" or "stabilized" >> soon? > > The implementation is still in

Re: What IDEs support autoconf-based projects ?

Thomas Dickey writes: > oh... does emacs show class diagrams reconstructed from source code? http://sourceforge.net/projects/oo-browser/ -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mail

Re: How can I test if the GNU or Sun linker is used?

Russ Allbery writes: > "Dr. David Kirkby" writes: >> I'd rather not use libtool - I don't want to learn yet another >> tool. Especially since it has already caused me some grief on Solaris. > > I used to feel that way, but I'm personally switching everything over to > it, particularly as I have

Re: # or dnl for comments?

Josef Vukovic writes: > dnl (Discard to next line) is an m4 builtin while # isn't I guess, not sure. > See also http://www.gnu.org/software/m4/manual/m4.html#Dnl section 8.1 The difference is that dnl causes text to be discarded, but # causes text to be passed through to the output. So you can

checking for libraries that link but do not run

e right track? It seems to me that there should already be a mechanism to help with this, but I do not see one. Thanks, Ben. -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: checking for libraries that link but do not run

Bob Friesenhahn writes: > On Mon, 5 Oct 2009, Ben Pfaff wrote: >> >> To try to head off the problem, I'm thinking about putting >> something like this after each command that adds to LIBS: >>AC_RUN_IFELSE([AC_LANG_PROGRAM([], [])], >> [:

Re: checking for libraries that link but do not run

Bob Friesenhahn writes: > On Mon, 5 Oct 2009, Ben Pfaff wrote: >> >> If your advice is correct, then any use of AC_RUN_IFELSE (if any >> libraries are added to LIBS) must be incorrect, because Autoconf >> does not have the correct knowledge to run a program. It'

Re: checking for libraries that link but do not run

Richard Ash writes: > On Mon, 2009-10-05 at 12:13 -0500, Bob Friesenhahn wrote: >> On Mon, 5 Oct 2009, Ben Pfaff wrote: >> > >> > To try to head off the problem, I'm thinking about putting >> > something like this after each command that adds to LIB

Re: checking for libraries that link but do not run

Bob Friesenhahn writes: > On Mon, 5 Oct 2009, Ben Pfaff wrote: >> >> I'm not sure what "be prepared for dealing with the pitfalls" >> amounts to. Can you point to an example of a correct way to deal >> with the pitfalls? What does your package do to de

Re: checking for libraries that link but do not run

Ralf Wildenhues writes: > * Ben Pfaff wrote on Mon, Oct 05, 2009 at 06:20:47PM CEST: >> To try to head off the problem, I'm thinking about putting >> something like this after each command that adds to LIBS: >> AC_R

Re: Is there a way to insert a short pause?

"Dr. David Kirkby" writes: > If one runs a configure script, and it needs to show a warning for > some reason, that could be missed by someone quite easily. Is there a > way I could insert a 10s or so pause, so it becomes more obvious, and > they hopefully take time to read the warning? One way

Re: pkg-config wisdom

"Murray S. Kucherawy" writes: > What's the current general wisdom on using the pkg-config > extensions? I presume there's a reason they've not been > incorporated into basic autoconf, so I'm keen to learn what > common practices there are toward adopting it into people's > builds (or avoiding it

Re: pkg-config wisdom

t of macros that follows "if > pkg-config installed then use it, else try to find stuff using > this heuristic" exists out there someplace that I can use. I do not know of one, but I have not looked for one. -- Ben Pfaff http://benpfaff.org __

Re: pkg-config wisdom

stem, you would insert `-lSM -lICE'. Recent releases of Motif require `-lXp' and possibly `-lXpm' as well.) -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: portability of 'printf' command

AS_ECHO' and `AS_ECHO_N' macros, which choose between `echo -n' on implementations where that works, `printf' if it is available, or other creative tricks in order to work around the above problems. -- Ben Pfaff http://benpfaff.org _

Re: cross-compiling but keeping one target native

y writing build-time tools in a language such as shell, Python, Perl, or awk that doesn't need to be compiled at all. If the utility is simple, so that you could easily rewrite it in a different language, then you might consider that solution. -- Ben Pfaff http:

Re: Arithmetic Shift

n necessary to drag the preprocessor into it? if (-1 >> 1 == 1) -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Arithmetic Shift

Dave Goodell writes: > On Dec 10, 2010, at 11:33 AM CST, Ben Pfaff wrote: > >> Paul Eggert writes: >> >>> On 12/07/10 20:41, Mike Gibson wrote: >>>> Does a test already exist that checks for if the >> operator in C does >>>> arithmet

Re: PKG-CHECK-MODULES

s silently. I > was expecting an error message for this version number of GTK2. It sounds very much like you don't have pkg-config installed. PKG_CHECK_MODULES is part of pkg-config. -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoco

Re: PKG-CHECK-MODULES

at 09:44 -0700, Ben Pfaff wrote: >> Steve Teale writes: >> >> > AC_DEFUN([PKG_CHECK_MODULES]) >> > >> > PKG_CHECK_MODULES([GTK], [gtk+-2.0 >= 3.0.0]) >> > >> > Without the AC_DEFUN it won't run at all, contrary to most documentation I

Re: LC_ALL and UTF-8 directory names

es the JVM have any equivalent? -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf

Re: uint64_t fails with C++

art of the spec and thus not > "implementation dependent" ? That's correct, __STDC_LIMIT_MACROS is mentioned in a pair of footnotes in C99, both of which say "C++ implementations should define these macros only when __STDC_LIMIT_MACROS is defined before is included." -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf

license of Makefile.in

While packaging Autoconf 2.69 for Debian, I am trying to update the copyright information in the package using the new Debian copyright format here: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ In the process, I'm looking at each file in Autoconf to understand its li

Re: Build directory option for configure script

Daniel J Sebald writes, proposing a new "configure" option: > it might be something like: > > --builddir=DIR object and libraries > > which is essentially the same as doing: > > mkdir ../DIR > cd ../DIR > ..//configure OTHER_OPTS > cd ../ Following the "configure", the next step will be

Bug#776559: autoupdate: add option that reports needed updates to configure.ac

The following feature request was reported against the Debian packaging for Autoconf as bug #776559. I'm forwarding it to the autoconf mailing list in case anyone wants to comment or implement this feature request. I'd appreciate it if followups would retain the CC to 776...@bugs.debian.org, becau

Re: Bug#850329: autoconf tries to execute foreign binaries

I'm adding the autoconf mailing list. For more background, take a look at the Debian bug log: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329 On Sun, Aug 20, 2017 at 09:18:44PM +0200, Vincent Lefevre wrote: > On 2017-08-20 11:01:28 -0700, Ben Pfaff wrote: > > This b

Fwd: Bug#267140: autoconf: AC_LINK_IFELSE does not allow to specify an alternate linker

As the Debian maintainer of packaging for Autoconf, I'm forwarding along this bug report. I don't know much about libtool so I don't feel confident responding to it by myself. Start of forwarded message Subject: Bug#267140: autoconf: AC_LINK_IFELSE does n

[John Houck] Bug#271232: AC_F77_LIBRARY_LDFLAGS should ignore -lcrt2.o on Mac OS X

Following bug was reported against the Debian packaging of Autoconf. It seems like more of an upstream thing to me, because Debian has little to do with Mac OS X, so I'm passing it along instead of taking action myself. Start of forwarded message From: Jo

Re: [John Houck] Bug#271232: AC_F77_LIBRARY_LDFLAGS should ignore -lcrt2.o on Mac OS X

Paul Eggert <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > >> --lang* | -lcrt[[01]].o | -lcrtbegin.o | -lc | -lgcc | -libmil | -LANG:=*) >> +-lang* | -lcrt[[012]].o | -lcrtbegin.o | -lc | -lgcc | -libmil | -LANG:=*) > >

[Elrond] Bug#281364: autoconf: configure doesn't show version for --version

r --version Reply-To: Elrond <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Resent-From: Elrond <[EMAIL PROTECTED]> Resent-To: [EMAIL PROTECTED] Resent-CC: Ben Pfaff <[EMAIL PROTECTED]> Resent-Date: Mon, 15 Nov 2004 13:03:01 UTC Resent-Message-ID: <[EMAIL PROTECTED]> Date:

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/Linu

Re: Fw: bug in texi2dvi, and hack patch

"Eli Zaretskii" <[EMAIL PROTECTED]> writes: >> Date: Thu, 20 Jan 2005 12:35:08 +0100 >> From: Stepan Kasal <[EMAIL PROTECTED]> >> Cc: Eric Blake <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org >> >> test -f tex.exe && test -x tex.exe > > This will work, but is redundant: it's enou

Re: Fw: bug in texi2dvi, and hack patch

"Eli Zaretskii" <[EMAIL PROTECTED]> writes: >> From: Ben Pfaff <[EMAIL PROTECTED]> >> Date: Thu, 20 Jan 2005 13:30:27 -0800 >> Cc: autoconf@gnu.org >> >> >> test -f tex.exe && test -x tex.exe >> > >> > This

Re: Request for configure override for AC_FUNC_MALLOC

OC properly: they are not making a replacement for malloc() available as the Autoconf documentation says they must. You should report bugs against these programs. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org ___ Autoconf mailing l

Re: Request for configure override for AC_FUNC_MALLOC

Marc Singer <[EMAIL PROTECTED]> writes: > On Tue, Feb 22, 2005 at 05:18:33PM -0800, Ben Pfaff wrote: >> Marc Singer <[EMAIL PROTECTED]> writes: >> >> > The trouble is that I want to be able to cross compile a large >> > number of packages without g

Re: Request for configure override for AC_FUNC_MALLOC

Marc Singer <[EMAIL PROTECTED]> writes: > It is clear to me the intention of the AC_FUNC_MALLOC in protecting > programs from non-conforming malloc() implementations. By the way, malloc(0) returning a null pointer is perfectly conforming. It is just not what some programs want. -- I love deadli

Re: Autoconf and optional arguments for the configure script

Bernd Lachner <[EMAIL PROTECTED]> writes: > I want more this two types of arguments for the configure script: > > 1) > --device=x where x can be devicea, deviceb, > > This should lead for example to a #define devicea in config.h. > > 2) > --devicexresoluton=x > --deviceyresolution=y > > or ev

[Vincent Lefevre] Bug#325866: autoconf: AC_COMPILE_IFELSE generates a test that doesn't work on IRIX64

I'm forwarding the following bug reported against the Debian packaging of upstream autoconf 2.59. (Preserving the CC against [EMAIL PROTECTED] in replies would be appreciated.) Start of forwarded message Subject: Bug#325866: autoconf: AC_COMPILE_IFELSE ge

Re: [Vincent Lefevre] Bug#325866: autoconf: AC_COMPILE_IFELSE generates a test that doesn't work on IRIX64

Ben Pfaff <[EMAIL PROTECTED]> writes: > I'm forwarding the following bug reported against the Debian > packaging of upstream autoconf 2.59. (Preserving the CC against > [EMAIL PROTECTED] in replies would be appreciated.) Oh, crap: that should be [EMAIL PROTECTED] -- "

[Hubert Chan] Bug#332713: autoconf: checking for fork does not work for C++

The following bug was reported against the Debian packaging of Autoconf 2.59. I verified that it produced the reported results on my system as well. [Preserving the CC to [EMAIL PROTECTED] in replies would be kind, because that allows replies to be preserved in the Debian BTS.] [Hubert: sorry ab

Re: [Hubert Chan] Bug#332713: autoconf: checking for fork does not work for C++

Paul Eggert <[EMAIL PROTECTED]> writes: > CVS autoconf does this instead. I presume the AC_INCLUDES_DEFAULT > fixes the same problem in a different way? Yes, it does. I've applied the change to Debian's Autoconf package. Thanks for your help. -- "Then, I came to my senses, and slunk away, hop

Re: AC_FOREACH public?

Keith Marshall <[EMAIL PROTECTED]> writes: > But "Reply-to-All" is *not* the most appropriate solution -- > it's what I used here, so *you* can have *two* copies of this > message. Personally, I configure my mailreader to discard duplicates. -- Ben Pfaff emai

autoconf will accept a nonexistent compiler as the second one checked

compiler really exists and works, but it only gets run once per configure script, not once per compiler. I've tested this with Debian's Autoconf 2.59. I don't think the situation has changed in CVS, based on a brief look at the source, but I haven't actually tested it. -- Ben

expected Autoconf 2.59 <-> 2.60 compatibility?

, e.g. the change in the expansion of @top_builddir@ and the behavior of AC_SUBST_FILE. Does anyone have input on whether these changes are cumulatively important enough to break much software? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://be

Re: expected Autoconf 2.59 <-> 2.60 compatibility?

Noah Misch <[EMAIL PROTECTED]> writes: > On Tue, May 09, 2006 at 05:26:12PM -0700, Ben Pfaff wrote: >> [2.59 -> 2.60 transition] >> Does anyone have input on whether these changes are cumulatively >> important enough to break much software? > > We tried to pre

Re: expected Autoconf 2.59 <-> 2.60 compatibility?

Ben Pfaff <[EMAIL PROTECTED]> writes: > One option open to me is to package and upload a 2.59 pre-release Excuse me, I of course meant a 2.60 pre-release here. > to Debian "unstable". I imagine that this would lead to more > widespread testing of the pre-release,

Re: expected Autoconf 2.59 <-> 2.60 compatibility?

Paul Eggert <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > >> Any comments on whether this is a good idea? > > It's a good idea, yes. You could use 2.59c. [...] I'll try to put out a Debian package of a 2.60 pre-release in the n

Re: expected Autoconf 2.59 <-> 2.60 compatibility?

Ben Pfaff <[EMAIL PROTECTED]> writes: > Paul Eggert <[EMAIL PROTECTED]> writes: > >> Ben Pfaff <[EMAIL PROTECTED]> writes: >> >>> Any comments on whether this is a good idea? >> >> It's a good idea, yes. You could use 2.59c. [...]

Re: expected Autoconf 2.59 <-> 2.60 compatibility?

Paul Eggert <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > >> I've done this now. I actually generated it from the CVS tree, >> for what it's worth. > > Thanks. Where can we get it from? I just now checked > <http://pac

SunOS 4 support?

Debian bug #157805, from 2002, relates to SunOS 4 support: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157805 Here is the problem that it states: The /bin/sh that comes with SunOS 4.1.4, when it processes a "." command, parses the whole file before doing anything else, and wh

Re: SunOS 4 support?

Harlan Stenn <[EMAIL PROTECTED]> writes: >> I see that there is some mention of SunOS 4 in the Autoconf >> documentation, but I'm not sure that it's really supported >> anymore. Is it worth my keeping this bug around anymore, or >> should I close it as "SunOS 4 no longer supported"? > > I'm prett

AC_DEFINE_UNQUOTED and autoheader

Debian Bug #179086 (CC'd) states the following: I have code like ac_tr_lib=HAVE_LIB`echo $1 | sed -e 's/[^a-zA-Z0-9_]/_/g' \ -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'` AC_DEFINE_UNQUOTED($ac_tr_lib) which, is intended to define certain preproce

atomic replacement of autom4te's output file

print $out "$res\n"; } + if ($atomic_replace && !rename("$output.tmp", "$output")) { +move ("${output}.tmp", "$output") + or fatal "cannot rename ${output}.tmp as $output: $!"; + } + # If no forbidden words, we're do

patch to invalidate Autom4te cache upon upgrade

A long time ago, a Debian user filed bug #219621 (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219621), complaining that the Autom4te cache caused problems when retained from one version to the next: After upgrading autoconf to 2.58 (from 2.57), suddenly running autoconf in a tree

Re: atomic replacement of autom4te's output file

Paul Eggert <[EMAIL PROTECTED]> writes: > I'd lean against this patch. The standard behavior for Unix utilities > > is simply to open an output file for writing, and not to attempt to > make the entire creat

Re: SunOS 4 support?

Paul Eggert <[EMAIL PROTECTED]> writes: > Harlan Stenn <[EMAIL PROTECTED]> writes: > >> I'm pretty sure we still have bunch of SunOS 4 users in the population I >> have to support. > > Which population would that be? Computer museum operators? Thanks for the information. I closed the Debian bug

Re: poor m4 hash performance

should not use a hash table that grows dynamically? It is easier to deal with software that can figure out parameters on its own rather than having to be told. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org ___ Autoconf mailing list

Re: poor m4 hash performance

Eric Blake <[EMAIL PROTECTED]> writes: > According to Ben Pfaff on 6/4/2006 4:15 PM: >> >> Is there a good reason why m4 should not use a hash table that >> grows dynamically? It is easier to deal with software that can >> figure out parameters on its own rathe

Re: Autoconf test version 2.60a available

release to Debian as 2.60a-1, just now, and I expect I'll hear back within a few days if any serious bugs were introduced. Of course I'll pass along anything that doesn't seem to be my fault. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org _

Re: Question regarding sscanf() vs. off_t and similar

Philipp Marek <[EMAIL PROTECTED]> writes: > On Thursday 14 September 2006 14:49 Eric Blake wrote: >> Gnulib provides umaxtostr.c, which is a convenient way of printing any >> integer of unknown width: >> >> char buf[INT_BUFSIZE_BOUND (uintmax_t)]; >> sprintf("%s %s", umaxtostr(ino, buf), name); >

Install Autoconf's .m4f files into /var?

I received this suggestion for the Autoconf package in the Debian bug tracking system. I don't feel confident enough that I understand the implications of the suggestion to just do it on my own, so I thought I'd pass the idea along to the experts here, to see if it makes sense to you guys to insta

Re: patch to invalidate Autom4te cache upon upgrade

Paul Eggert <[EMAIL PROTECTED]> writes: > Following up to your May 25 message > re > Debian bug 219621, I was thinking of incorporating the proposed fix > into Autoconf before the 2.61 release, but ran into a couple of > problems:

[patch] AC_FUNC_GETMNTENT not defining HAVE_GETMNTENT to 1 but to empty

Debian bug 403243 reports that HAVE_GETMNTENT gets defined to empty when AC_FUNC_GETMNTENT is used. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403243 The bug log points to this Autoconf commit as the culprit: http://cvs.savannah.gnu.org/viewcvs/autoconf/autoconf/lib/auto

Re: [newbie] How to check for an "install" program

Stefano Sabatini <[EMAIL PROTECTED]> writes: > Strange enough the install-sh is not included in the autoconf package > (Debian Etch), but in the automake package. The Debian package includes all the files that Autoconf installs. install-sh isn't one of them because Autoconf doesn't actually insta

Re: Question on AC_PREREQ

gt; 2.9 > 2.7. And therefore one would expect that AC_PREREQ(2.7) would succeed under Autoconf 2.61a. In fact, it does succeed when I test it on my machine here. The OP implies that it fails on his machine. I don't know why it would, though. -- Ben Pfaff http://benpfaff.org

Re: Autoconf and apt

pendencies with a single command: apt-get build-dep -- Ben Pfaff http://benpfaff.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Debian archive rebuild with Autoconf 2.69c

On Fri, Sep 25, 2020 at 9:21 AM Zack Weinberg wrote: > I have prepared source and binary packages of the beta autoconf and > uploaded them to my personal website. > https://research.owlfolio.org/scratchpad/debian/ should work as an apt > source line, and the packages should cleanly upgrade from au

Debian Autoconf bug report: Bug#138666: autoconf: AC_EXEEXT fails when CFLAGS="-fprofile-arcs -ftest-coverage"

Hi. I'm the maintainer of the Debian package for Autoconf. I received the following bug report against Autoconf 2.52. It looks like it still applies to Autoconf 2.53, so I'm passing it along upstream with this message. Thanks, Ben. Start of forwarded message

Re: Bug#143536: autoconf: info documentation broken

Hi. I'm the maintainer for the Debian GNU/Linux package of Autoconf. It looks like the Texinfo manual for Autoconf 2.53 has a node name with a `.' in it. That's not okay, as the Texinfo manual says in section "`@node' Line Requirements": * Unfortunately, you cannot use periods, commas, colo

Bug#143590: autoconf 2.53 causes ncpfs to not build from source

Hi. I'm the maintainer of the Debian GNU/Linux package for Autoconf. The following bug report was recently filed. I don't think it's a bug that I introduced, and it isn't obvious to me that it's a bug in the submitter's configure.in, so I thought I'd forward it upstream. Thanks, Ben. ---

Re: Bug#143590: autoconf 2.53 causes ncpfs to not build from source

Andreas Schwab <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > > |> Hi. I'm the maintainer of the Debian GNU/Linux package for > |> Autoconf. The following bug report was recently filed. I don't > |> think it's

patch for autoheader problem with --warnings

autoheader from Autoconf 2.53 was griping about --warnings= and -W . It looks like the getopt() call was wrong: --- tmp/autoconf-2.53/bin/autoheader.in Fri Mar 8 03:52:41 2002 +++ autoconf-2.53/bin/autoheader.in Tue Apr 23 11:26:59 2002 @@ -103,7 +103,7 @@ my $srcdir; getopt ('I|inc

["Florian Weimer" ] Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

The following bug was reported against the Debian GNU/Linux package for Autoconf version 2.53. It is an upstream bug, so I am forwarding it to the Autoconf mailing list. Thanks, Ben. Start of forwarded message Subject: Bug#158969: autoconf: AC_SYS_LARG

Re: --with-foo= vs. FOO=${FOO:-foo_default}

Russ Allbery <[EMAIL PROTECTED]> writes: > This seems like obviously bad advice to me. How is one expected to handle > something like specification of a default paper size unless there's a user > switch somewhere? > > Surely the GNU coding standards aren't arguing that editing a cryptic > config

Re: --with-foo= vs. FOO=${FOO:-foo_default}

Bruce Korb <[EMAIL PROTECTED]> writes: > Ben Pfaff wrote: > > > In my experience, a cryptic configuration file is almost always > > an improvement over a configure switch. > > You're at Stanford. You must be a student. You got a problem with that? I have

Re: --with-foo= vs. FOO=${FOO:-foo_default}

Russ Allbery <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > > In my experience, a cryptic configuration file is almost always an > > improvement over a configure switch. To change a configure switch, I > > have to find the program&#x

[Daniel Schepler ] Bug#167503: autoconf: AC_MSG_WARN with #define inside fails

I received the following bug report against the Debian package for Autoconf 2.54. I'm a bit stumped, so I'm forwarding it to the list without further commentary. Thanks, Ben. Start of forwarded message Subject: Bug#167503: autoconf: AC_MSG_WARN with #de

[Kristian Kvilekval ] Bug#172858: autoconf:autoupdate fails to convert configure.in to latest version

The following bug was reported against the Debian GNU/Linux package for Autoconf 2.57. I managed to reproduce the infinite loop it mentions using the following trivial configure.ac: AC_LANG_SAVE AC_LANG_RESTORE AC_LANG_SAVE AC_LANG_RESTORE Thanks, Ben. Start of forwarded m

[Jason Dorje Short ] Bug#179086:autoconf: AC_DEFINE_UNQUOTED fails when used on variables

The following bug was reported against the Debian GNU/Linux packaging of Autoconf 2.57. I am passing it along because I suspect it is an upstream issue. Start of forwarded message Subject: Bug#179086: autoconf: AC_DEFINE_UNQUOTED fails when used on variab

Re: please bring back program suffix for autoconf bin files

Dan Kegel <[EMAIL PROTECTED]> writes: > Sure, I could, and maybe I will. But all I need is access to > a recent autoconf side by side with the old autoconf-2.13. > All the distros make autoconf available as /usr/bin/autoconf, > but the name they use for autoconf-2.13 varies: > > Red Hat 8.x: /us

Re: please bring back program suffix for autoconf bin files

Dan Kegel <[EMAIL PROTECTED]> writes: > That's a nice feature of Debian, but unfortunately, > it does not help in the case of somebody trying to > write a shell script that must invoke autoconf-2.13 > no matter what distro (Debian, Cygwin, or Red Hat) > it runs on. For such a shell script, having

Re: What is going on with releases, mailing lists?

Pavel Roskin <[EMAIL PROTECTED]> writes: > However, ftp.gnu.org has only version 2.58. Debian unstable also uses > version 2.58. As maintainer of Debian's Autoconf package, this is because I don't know where to get Autoconf 2.59. It has not been announced, and it is not available from ftp.gnu.o

Re: What is going on with releases, mailing lists?

Akim Demaille <[EMAIL PROTECTED]> writes: > 2.58 was not announced because it has a problem that affects Automake. > I never announced it, and I am somewhat unhappy that Debian has > already shipped it. All this mess results from the now asynchronous > process to upload files on ftp.gnu.org. Had

why warn for lack of AM_GNU_GETTEXT_VERSION?

The gettext manual says this about AM_GNU_GETTEXT_VERSION: The use of this macro is optional; only the `autopoint' program makes use of it (*note CVS Issues::). However, the autoreconf program will warn if AM_GNU_GETTEXT_VERSION is omitted (if AM_GNU_GETTEXT is used). Is it really opti

Re: shouldn't it error?

Bob Lockie <[EMAIL PROTECTED]> writes: > Shouldn't the following give an error about an unknown option > "./configure --enable-debu=full"? Actually this is explained in the Autoconf manual: `configure' scripts do not complain about `--enable-FEATURE' options that they do not support.

  1   2   >