AC_OUTPUT vs m4 nesting limit
When trying to generate more than 250 files with one configure script (like the kdebase package wants to do) you'll hit the nesting limit of m4 (due to the fact that loops are implemented through recursion). Currently there is no way increase this limit from the autoconf invocation. How about adding an option so that, say, --m4-options=--nesting-limit=300 can fix that? Or maybe this limit should be increased by default? Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Re: AC_OUTPUT vs m4 nesting limit
Akim Demaille <[EMAIL PROTECTED]> writes: |> >>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: |> |> Andreas> Or maybe this limit should be increased by default? |> |> Yep, it sounds very reasonable. |> |> What would you suggest? Jump to say 1024? Well, pick any magic number you like. Are there any other loops in the autoconf macros that may hit this limit? Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Re: AC_OUTPUT vs m4 nesting limit
Akim Demaille <[EMAIL PROTECTED]> writes: |> BTW, you might want to use several AC_CONFIG_FILES. Using a single |> huge AC_OUTPUT seems bizarre to me. That does not help, since AC_CONFIG_FILES just collects the files. They are actually processed by AC_OUTPUT. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Re: AC_OUTPUT vs m4 nesting limit
Akim Demaille <[EMAIL PROTECTED]> writes: |> | Akim Demaille <[EMAIL PROTECTED]> writes: |> | |> BTW, you might want to use several AC_CONFIG_FILES. Using a single |> | |> huge AC_OUTPUT seems bizarre to me. |> | |> | That does not help, since AC_CONFIG_FILES just collects the files. They |> | are actually processed by AC_OUTPUT. |> |> Hm... but IIRC there is no M4 loop to output the code in AC_OUTPUT. |> ISTR it was implemented via a diversion. It is part of _AC_OUTPUT_CONFIG_STATUS: AC_FOREACH([AC_File], AC_LIST_FILES, [ 'm4_patsubst(AC_File, [:.*])' )dnl CONFIG_FILES="$CONFIG_FILES AC_File" ;; ])dnl |> Actually, the limit you might be hitting might be due to the macro |> which checks that there are no duplicates :( This can be worked around, because it only loops on the list actually passed to AC_CONFIG_FILES. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
_AC_CHECK_TYPE_REPLACEMENT_TYPE_P
IMHO, _AC_CHECK_TYPE_REPLACEMENT_TYPE_P should treat words of the form [a-z]*_t as types so that AC_CHECK_TYPE(__u8, u_int8_t) does the right thing. Incidentally, AC_CHECK_TYPE(__s8, int8_t) is already treated as an old form, because int8_t starts with "int". Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Re: _AC_CHECK_TYPE_REPLACEMENT_TYPE_P
Akim Demaille <[EMAIL PROTECTED]> writes: |> >>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: |> |> Andreas> IMHO, _AC_CHECK_TYPE_REPLACEMENT_TYPE_P should treat words of |> Andreas> the form [a-z]*_t as types so that AC_CHECK_TYPE(__u8, |> Andreas> u_int8_t) does the right thing. Incidentally, |> Andreas> AC_CHECK_TYPE(__s8, int8_t) is already treated as an old |> Andreas> form, because int8_t starts with "int". |> |> This was settled with Paul. |> |> Paul, the code is |> |> # _AC_CHECK_TYPE_REPLACEMENT_TYPE_P(STRING) |> # - |> # Return `1' if STRING seems to be a builtin C/C++ type, i.e., if it |> # starts with `_Bool', `bool', `char', `double', `float', `int', |> # `long', `short', `signed', or `unsigned' followed by characters |> # that are defining types. |> # Because many people have used `off_t' and `size_t' too, they are added |> # for better common-useward backward compatibility. |> m4_define([_AC_CHECK_TYPE_REPLACEMENT_TYPE_P], |> [m4_if(m4_regexp([$1], |> |[^\(_Bool\|bool\|char\|double\|float\|int\|long\|short\|\(un\)?signed\|size_t\|off_t\)\([_a-zA-Z0-9() | *]\|\[\|\]\)*$]), |>0, 1, 0)dnl |> ])# _AC_CHECK_TYPE_REPLACEMENT_TYPE_P |> |> |> But Andreas, I guess you do have a warning, don't you? What patch |> would you suggest? Yes, I get a warning. I'd like to have the regex changed to ^\(_Bool\|bool\|char\|double\|float\|int\|long\|short\|\(un\)?signed\|[_a-z0-9][_a-z0-9]*_t\)\([_a-zA-Z0-9() *]\|\[\|\]\)*$ Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Re: _AC_CHECK_TYPE_REPLACEMENT_TYPE_P
Akim Demaille <[EMAIL PROTECTED]> writes:
|> Index: NEWS
|> ===
|> RCS file: /cvs/autoconf/NEWS,v
|> retrieving revision 1.173
|> diff -u -u -r1.173 NEWS
|> --- NEWS 2001/07/17 07:53:06 1.173
|> +++ NEWS 2001/07/17 09:59:27
|> @@ -36,10 +36,13 @@
|>
|> ** Generic macros
|> - AC_CHECK_HEADER and AC_CHECK_HEADERS support a fourth argument to
|> - specify pre-includes.
|> + specify pre-includes. In this case, the headers are compiler with
Typo.
Andreas.
--
Andreas Schwab "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Re: Issue in autoconf with config.status generation
"Evan Hunter" <[EMAIL PROTECTED]> writes: > The problem I'm finding is that the command-line options are being saved in > the config.status, but not the environment variables. If you want an env var to be saved in config.status (in addition to the predefined list) you should declare it as precious (see (autoconf)Setting Output Variables). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Error while autoconf on Ubuntu
"mahendra panpalia" <[EMAIL PROTECTED]> writes: >> aclocal.m4:22: error: m4_defn: undefined macro: _m4_divert_diversion Most likely underquoted macro. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: tr portability
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> +On Solaris, don't put @code{/usr/ucb} early in your PATH. @code{/usr/ucb}
It's probably better to avoid starting the sentence with
@code{/usr/ucb}.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: autconf, configure & purify...
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > - many vendor shells complain about 'test -z' without further argument: A POSIX-compliant test won't, and returns zero. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Getting data from a nested configure script?
"Allan Caffee" writes: > Is there a simple way to do this inside a Makefile without having the > value get expanded by our own configure script? I was thinking > something like: > > echo '+CFLAGS+' | tr '+' '@' | ./config.status --file=- echo '@'CFLAGS@ | ./config.status --file=- Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: value of a macro parameter and position of )
Vincent Torri writes: > Hey, > > i've written a macro with 2 parameters. Suppose that the macro name is > FOO, if I use it like that in the configure.ac file: > > FOO([var1] > ["yes"] > ) Did you mean to write comma after [var1]? Without it there is only one argument. > the value of the 2nd parameter in the macro is not yes, but yes followed > by a new line See node Macro Arguments in the m4 documentation: only leading unquoted whitespace is skipped when collecting macro arguments. All other whitespace will become part of the argument. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_TRY_COMPILE() annoyances with 2.63b
Eric Blake writes: > I'm also leaning towards omitting the else if $1 is provably blank, > otherwise providing the : in case non-blank $1 ultimately expands to a > blank (unless someone finds a shell where 'if false ; then :; fi; echo $?' > fails to output 0). >From the autoconf manual: There are shells that do not reset the exit status from an `if': $ if (exit 42); then true; fi; echo $? 42 whereas a proper shell should have printed `0'. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AS_IF optimization (was: AC_TRY_COMPILE() annoyances with 2.63b)
Eric Blake writes: > According to Andreas Schwab on 4/7/2009 3:47 AM: >>>From the autoconf manual: >> >> There are shells that do not reset the exit status from an `if': >> >> $ if (exit 42); then true; fi; echo $? >> 42 >> >> whereas a proper shell should have printed `0'. > > Which shells? Solaris /bin/sh passed this test (to my surprise, since if > fails the similar test for 'case `false` in *);; esac'). Even cygwin's > super-old ash passed this, although it falls flat on a number of other > constructs. Could this be a case of urban legend? According to <http://www.in-ulm.de/~mascheck/bourne/> this was fixed in the System III shell. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Portability problems in autoconf manual
Mike Frysinger writes: > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap > If the first operand is an unsigned decimal integer, the shell shall treat > all > operands as conditions, and shall reset each condition to the default value. > Otherwise, if there are operands, the first is treated as an action and the > remaining as conditions. This paragraph is new in POSIX.1-2008. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Lost commit
When I updated my copy of the autoconf repository today I noticed that one commit got lost (45b928b: autotest: fix file descriptor leak). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bash security issue
Eric Blake writes: > Overkill. The security hole arises because the problem, as it currently > exists, is triggerable by ANY portable environment variable definition. In the context of security you need to forget about portable. You need to think about the improbable. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: finding datadir from executable
Ralph Corderoy <[EMAIL PROTECTED]> writes: > Does argv[0] always contain a path on all Unixes? No. It contains exactly the string passed in by execve, unmodified. It can be arbitrary. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: finding datadir from executable
Ralph Corderoy <[EMAIL PROTECTED]> writes:
> I wasn't clear. I realise it isn't always an absolute path, and is
> normally whatever's passed to execve(2). I was just trying to point out
> that some old Unixes, Xenix? -- I can't remember, effectively strip any
> path, absolute or relative, from execve's argument before it turns up in
> argv[0], i.e. execve("./ls", ...) and execve("/bin/ls", ...) both
The first argument of execve is irrelevant for argv[0]. The argv array
(including argv[0]) is completely passed in by the caller, which can set
it any way it likes. What you have seen might be the effect of a
misbehaving shell. Usually argv[0] is the command name before looking it
up in $PATH.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Header template file
Markus Moeller <[EMAIL PROTECTED]> writes: > If I do so my predefined my_tool.h gets overwritten. Is there a way to use a > predefined template file ? You can use AH_TOP, AH_BOTTOM, etc. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: Header template file
Markus Moeller <[EMAIL PROTECTED]> writes: > I thought they are also deprecated like acconfig.h or is AH_TOP ,etc something > different ? Only acconfig.h is deprecated. AH_TOP, etc. have replaced it. > How does it work ? See <http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_30.html>. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: C99 support
Roger Leigh <[EMAIL PROTECTED]> writes: > Are there any tests I can use to specify that I want a C99 compiler? > AC_PROG_CC isn't sufficient. IMHO the preferred way is to check for the specific features you need (eg. with AC_COMPILE_IFELSE) and abort when not provided (or maybe use workarounds instead). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_PROG_CC_C99
Ralph Schleicher <[EMAIL PROTECTED]> writes: > Paul Eggert <[EMAIL PROTECTED]> writes: > >> "ISO" is not an acronym > > International Standard Organization No. See <http://www.iso.org/iso/en/aboutiso/introduction/index.html#three>. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Last configure args
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > Unfortunately, using > > ./config.status --recheck > > to reconfigure is not the complete solution to re-configuring since there > are files it will not update (e.g. config.status). Huh? config.status is the _only_ file that this updates. To get the other files updated just run the new config.status. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Use of config.h: summary of responses.
Stepan Kasal <[EMAIL PROTECTED]> writes: > Hi, > > 4 months ago, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: >> > The fact of the matter is that some/many libraries have header files >> > which are OS/CPU/compiler dependent and there has to be a way to >> > record/work-around these dependencies so that the library headers work >> > right. This way is commonly known as 'config.h'. > > Resurrecting that ancient thread, Ian Lance Taylor writes: >> Then we substitute in bfd-in2.h as we do in config.h, by adding it to >> AC_CONFIG_FILES. Then we install the result. > > you mean AC_CONFIG_HEADERS, of course. In case of bfd-in2.h it's generated be AC_CONFIG_FILES. It only depends on the format of the substitution, either @FOO@ or #define FOO. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Using $bindir in configure.ac
Stepan Kasal <[EMAIL PROTECTED]> writes: > + ac_define_dir=`eval echo "\"[$]$2\""` > + ac_define_dir=`eval echo "\"[$]ac_define_dir\""` In this case the quotes are not necessary because assignments are not word splitted. But it can be further simplified: eval ac_define_dir=\"[$]$2\" eval ac_define_dir=\"[$]ac_define_dir\" Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Using $bindir in configure.ac
Stepan Kasal <[EMAIL PROTECTED]> writes: > You are right, bu you need to quote more: Yes, I see my error now. Thanks for correcting me. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: 5.9 The Future of `aclocal'
Bruce Korb <[EMAIL PROTECTED]> writes: > In fiddling with sharutils, I discovered that it is too early to encourage > the dropping of bootstrap scripts just yet. "autoreconf" does not provide > a way of convincing automake to run with the options, "--gnu" and > "--add-missing". Sure it does. "--gnu" comes from AUTOMAKE_OPTIONS in Makefile.am or from AM_INIT_AUTOMAKE, and "--add-missing" is added with "--install". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Pending Patches
Roger Leigh <[EMAIL PROTECTED]> writes:
> Noah Misch <[EMAIL PROTECTED]> writes:
>
>> % Fix cached use of AC_PROG_CC_C{89,99} + unify common bits
>> http://lists.gnu.org/archive/html/autoconf-patches/2005-01/msg00052.html
>
> The mailing list archive has mangled the hunk headers (e.g.
> "@@ -910,11 +915,7 @@ esac").
I don't see anything wrong with the headers. Note that the diff was
generated with -p.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf 2.59 - Syntax error in autoreconf?
"Stan Guillory" <[EMAIL PROTECTED]> writes: > That is the mkdir command requires two arguments, and the autoreconf > script was only passing one. Is this a Perl version thing? perlfunc(1) from perl 5.8.6 says that the second argument is optional and defaults to 0777. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: x86_64 and x86 userland
[EMAIL PROTECTED] (Bob Proulx) writes: > Actually, that is one of the possibilities. And in that case I would > deny that it is a completely x86 userland. > > 1. User installs x86 kernel. x86 userland. Everything 32-bit. I >think this would be considered the "normal" installation. > > 2. User installs amd64 (aka x86-64) kernel. /usr/bin/ is x86 but can >now run amd64 binaries too. So now the userland is a multiarch >userland. > > 3. User installs amd64 (aka x86-64) kernel. /usr/bin/ is 64-bit amd64 >binaries but the system can run 32-bit binaries too. Userland is a >multiarch userland. 4. User installs a x86-64 kernel that has the ia32 emulation disabled. That results in a pure 64-bit environment. > That is correct. The kernel returns x86_64 for 'uname -m'. The gcc > toolpath is using x86_64 (with an underscore to avoid problems with > the dash) as the architecture string. My understanding is that the > kernel uses whatever gcc uses and returns that for 'uname -m'. The kernel has no connection to gcc. The return value of the uname syscall only depends on the personality of the calling process. > I don't know about 'setarch' but you can use the 'linux32' program. > It intercepts system calls and masquerades. It does nothing like that, it just sets the personality and execs its command line. The personality determines, among others, which syscall table is used. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Preferring a specific compiler?
Dan Stromberg <[EMAIL PROTECTED]> writes: > On Tue, 31 May 2005 21:16:00 +0200, Stepan Kasal wrote: > >> Hi, >> >> On Tue, May 31, 2005 at 10:27:01AM -0700, Dan Stromberg wrote: >>> I have an app I'd like to compile with tcc -b if available, otherwise try >>> gcc, and if that is unavailable too, then try cc. >> >> place >> >> AC_PROG_CC(["tcc -b" gcc cc]) >> >> near the top of your configure.ac >> >> Stepan > > That's generating a ./configure line: > > for ac_prog in "tcc -b" gcc cc > > ...but it's not finding tcc. Perhaps it's looking for a program called > "tcc -b", and not a program called "tcc" with a "-b" argument? Works fine here. Note how AC_CHECK_PROG splits its argument to extract the first word from it. $ cat configure.ac AC_INIT AC_PROG_CC(["gcc -v"]) AC_OUTPUT $ ./configure checking for gcc... gcc -v checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc -v accepts -g... yes checking for gcc -v option to accept ANSI C... none needed configure: creating ./config.status Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf and optional arguments for the configure script
Bernd Lachner <[EMAIL PROTECTED]> writes: > Ok. But I don't know if I understand this right. Is it possible to give > AC_ARG_ENABLE more than two arguments to choose. That means in configure the > following should be possible: > > configure --enable-device=devicea > or > configure --enable-device=deviceb > or > configure --enable-device=devicec > or It is completely up to you how you interpret the argument given to --enable-foo. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Need help with autoconf configure script
Bob Rossi <[EMAIL PROTECTED]> writes: > If I run ./configure then by default opt_with_readline_prefix is "no". > During ../cgdb/configure I get, >checking pty.h usability... yes >checking pty.h presence... no >configure: WARNING: pty.h: accepted by the compiler, rejected by the > preprocessor! >configure: WARNING: pty.h: proceeding with the compiler's result >checking for pty.h... yes > so I get error's when VL_LIB_READLINE is *not* run. Please check config.log for the actual preprocessor error you get. Without that it is impossible to guess what's going on. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Need help with autoconf configure script
Bob Rossi <[EMAIL PROTECTED]> writes: > On Wed, Jul 13, 2005 at 12:04:27AM +0200, Andreas Schwab wrote: >> Bob Rossi <[EMAIL PROTECTED]> writes: >> >> > If I run ./configure then by default opt_with_readline_prefix is "no". >> > During ../cgdb/configure I get, >> >checking pty.h usability... yes >> >checking pty.h presence... no >> >configure: WARNING: pty.h: accepted by the compiler, rejected by the >> > preprocessor! >> >configure: WARNING: pty.h: proceeding with the compiler's result >> >checking for pty.h... yes >> > so I get error's when VL_LIB_READLINE is *not* run. >> >> Please check config.log for the actual preprocessor error you get. >> Without that it is impossible to guess what's going on. > > Thanks for the response Andreas. The attached is the diff between when > the config.log that works and doesn't work. That's the old AC_REQUIRE problem. VL_LIB_READLINE is probably the first macro requiring the AC_PROG_CPP framework, but since all of this is skipped when $vl_cv_lib_readline is no, the expansion from that macro is never executed, and many of the internal autoconf variables remain unset. Workaround: Put AC_PROG_CPP somewhere before this block. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to let autoconf NOT include ($CFLAGS) in LINK?
[EMAIL PROTECTED] writes: > Now, gcc handles compiler flags on the command line well when linking, but > 'ld' > on a Tru64 machine doesn't :-) Automake generates these variable settings: CCLD = $(CC) LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ Thus there is nothing that calls 'ld' with $(CFLAGS), only $(CC). In fact, if you are using gcc then calling the linker directly is almost always wrong. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Help in AC_CHECK_LIB
"madan m raj" <[EMAIL PROTECTED]> writes: > AC_CHECK_LIB (IL, ilSaveImage, [], [ ^ Drop the space. In m4, a macro call must be followed immediately by the open paren for being recognized as the start of a parameter list. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Command Substitution in AC_ARG_WITH Help Strings
Keith Marshall <[EMAIL PROTECTED]> writes: > Hello, > > I would like to implement a configure option which would have the effect of > > AC_DEFUN([MY_LANGUAGE_SET], > [AC_ARG_WITH([languages], > AS_HELP_STRING([--with-languages=LIST], > [install language files in LIST, a comma separated subset of '$1']), > [languages=$withval], > [languages=en])]) > > MY_LANGUAGE_SET([`cd lang; echo ?? | tr " " ,`]) > > and have the result of the command substitution > >`cd lang; echo ?? | tr " " ,` > > appear in the `configure --help' output. This won't do the right thing if configure is executed outside the source directory (for buiding in a separate directory). > Given these limitations, can anyone suggest a better mechanism for achieving > this objective? Use esyscmd to interpolate the output of the command at configure creation time. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: building xcb without check
Trevor Woerner <[EMAIL PROTECTED]> writes: > Unfortunately the autoreconf tool (which our autogen.sh script uses) > doesn't provide a means to pass this option onto the aclocal program. It does. $ autoreconf --help [...] The environment variables AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL, AUTOPOINT, LIBTOOLIZE are honored. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AM_CONDITIONAL
Russell Shaw <[EMAIL PROTECTED]> writes: > Hi, > In configure.in, i have: > > AM_CONDITIONAL(ENABLE_GTK_DOC, test x$enable_gtk_doc = xyes) > > and it gets turned into: > > if test x$enable_gtk_doc = xyes; then > ENABLE_GTK_DOC_TRUE= > ENABLE_GTK_DOC_FALSE='#' > else > ENABLE_GTK_DOC_TRUE='#' > ENABLE_GTK_DOC_FALSE= > fi > > Isn't this backward? Look at the generated Makefile.in: everything prefixed with @ENABLE_GTK_DOC_TRUE@ is enabled (not commented out) when the condition is true. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: checking for specific versions of operating system
Harlan Stenn <[EMAIL PROTECTED]> writes: > I use things like this: > > AC_CHECK_FUNC(gethostent, , AC_CHECK_LIB(nsl, gethostent, , , -lsocket)) > AC_CHECK_FUNC(openlog, , > AC_CHECK_LIB(gen, openlog, , > AC_CHECK_LIB(syslog, openlog, , , -lsocket))) Always quote nested macro calls. Actually, _all_ arguments should be quoted, but for those containing macro calls it is most important. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: variables in configure.ac
Matthias Langer <[EMAIL PROTECTED]> writes: > I'm trying to to the following in my configure.ac: > > VTK_LIBS=$vtk_lib_path > VTK_LIBS+="-lvtkFiltering -lvtkfreetype -lvtkftgl -lvtkGraphics > -lvtkHybrid" \ > "-lvtkImaging -lvtkIO -lvtkRendering" > > However, when i run configure, i get > ...: VTK_LIBS+=-lvtkFiltering -lvtkfreetype -lvtkftgl -lvtkGraphics > -lvtkHybrid: command not found > > Can anybody tell my what i'm doing wrong ? This isn't valid Bourne Shell syntax. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to force the caller of configure to pass arguments
Matthias Langer <[EMAIL PROTECTED]> writes: > However, when the caller of configure forgets to pass this option, > configure will work, but make certainly fail. So it would be great, if i > can > check if certain arguments were supplied allready in configure and exit with > an error message if not. The optional fourth parameter of AC_ARG_WITH is executed if no such option is passed, as described in the manual (hint, hint). You can use AC_MSG_ERROR to abort. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: sh portability questions
Paul Eggert <[EMAIL PROTECTED]> writes: > Assuming you don't need recursion, here's a thought. Use "local", but > stick to the convention that all variable names are unique. On > systems that don't support "local", define a function named "local" > that warns if any of its arguments is a variable whose value is set; That would also (spuriously) warn if you call a function with local variables a second time, unless you explicitly unset the local variables before returning. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: sh portability questions
Akim Demaille <[EMAIL PROTECTED]> writes:
> if (local foo) >/dev/null 2>&1; then :; else
> local () { true; }
> fi
Note that local is only valid in function context, so this will always
produce a failure.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: [OT] reply-to (was: AC_FOREACH public?)
Keith MARSHALL <[EMAIL PROTECTED]> writes: > Great. You still have that choice, even if the "Reply-to" header points > back to the list: > > . Reply to the address in the "Reply-to" header, for a list reply; This is an open list. You'll remove anyone from the thread who is not subscribed to the list. > . Reply to the address in the "From" header, for a private response; If Reply-to is present, it replaces the From address for replies (RFC 2822). > . Reply-to-All, to spam the world... Keep the non-subscribers in the loop. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Defining Macros With Literal Values
Eric Lemings <[EMAIL PROTECTED]> writes: > Greetings, > > I have a tricky little problem I was hoping someone could > help me with. I am trying to write an Autotools macro that > extracts the value of a macro from a system header file > and defines another preprocessor macro with the same value. You can use AC_DEFINE_UNQUOTED to define a macro to the result of a shell substitution. You can easily extract the value from the output of the preprocessor. Don't use the output of a compiled program because that would make cross-compiling impossible. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AW: prefix
Keith Marshall <[EMAIL PROTECTED]> writes: > BTW, I don't think ac_default_prefix is officially documented But AC_PREFIX_DEFAULT is. -- Macro: AC_PREFIX_DEFAULT (PREFIX) Set the default installation prefix to PREFIX instead of `/usr/local'. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: debug builds with NO optimizations
"John Calcote" <[EMAIL PROTECTED]> writes: > My question: Anyone know of a good idiom for managing optimization flags - > including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC? .../configure CFLAGS=-g Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: debug builds with NO optimizations
"John Calcote" <[EMAIL PROTECTED]> writes: > When you override CFLAGS on the configure command line, you give > configure the opportunity to add more flags to the CFLAGS variable that > are then passed on to make. Yes, there are many broken configure scripts out there that do that. Please don't spread that further. CFLAGS (as well all CPPFLAGS, CXXFLAGS, etc.) should always be reserved for the user to override any time. It it highly annoying if that does not work. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: ensure a VPATH build
Keith Marshall <[EMAIL PROTECTED]> writes: > Where is it *ever* necessary? The backticks themselves serve as quotes. This is wrong. The expansion of a command substitution is subject to word splitting and filename expansion, unless quoted. Especially the latter is most serious. > A string such as >"a string `echo with an embedded backquoted` substring" > > can always be safely rewritten as >"a string "`echo with an embedded backquoted`" substring" $ echo `echo 'a b'` a b $ echo "`echo 'a b'`" a b Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: ensure a VPATH build
Keith Marshall <[EMAIL PROTECTED]> writes: > Nevertheless, it does seem that avoiding backquoted expressions within > double quotes where possible, can lead to more robust and portable > scripts. I disagree. Not quoting the output of a command substitution is a bug waiting to happen. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure script question ?
"June Fang" <[EMAIL PROTECTED]> writes:
> i know ${ZSH_VERSION} means variable substituting;
> and ${ZSH_VERSION:+set} means "If parameter is null or unset, nothing
>~~ Note the `:`
> is substituted, otherwise the expansion of word is substituted."
> from Bash reference manual
>
> but what dose ${ZSH_VERSION+set} without the `:` means ?
See the Bash menual (same section):
When not performing substring expansion, Bash tests for a parameter
that is unset or null; omitting the colon results in a test only for a
parameter that is unset. Put another way, if the colon is included,
the operator tests for both existence and that the value is not null;
if the colon is omitted, the operator tests only for existence.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf linking with shared object
Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hi Braden, > > * Braden McDaniel wrote on Wed, Mar 29, 2006 at 10:32:37AM CEST: >> Is this advice really still relevant? Are all those packages that apply >> -l and -L together as a unit Doing It Wrong? > > Yes. And anybody trying to link completely statically in this case will > be hurt: the linker will only search the static libraries when it > encounters them on the command line; if a later library needs some > object from an earlier one pulled in (that wasn't already pulled in by > something else), then you will get a link failure. With linker flags like --as-needed this becomes relevant even in the shared case. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FILES on /dev/stdin
David Fang <[EMAIL PROTECTED]> writes:
> To give a little more context for what I'm trying to do in C++
> (experimentally): I've discovered that std::ifstream foo("/dev/stdin")
> results in a file stream that works just like cin, likewise for stdout,
> etc... Just like in standard C, one could use stdin, stdout, stderr as
> FILE*, I'd like to do the equivalent with std::fstream's. (std::cin is a
> basic_istream, not type-equivalent to a basic_ifstream.)
But basic_ifstream is a basic_istream.
> I'm writing a little stream manager that maintains stream objects (not
> references to) internally without any run-time polymorphism, so I need
> one single type to handle both stdio and file streams,
That would be basic_istream/ostream.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FILES on /dev/stdin
David Fang <[EMAIL PROTECTED]> writes:
>> >To give a little more context for what I'm trying to do in C++
>> > (experimentally): I've discovered that std::ifstream foo("/dev/stdin")
>> > results in a file stream that works just like cin, likewise for stdout,
>> > etc... Just like in standard C, one could use stdin, stdout, stderr as
>> > FILE*, I'd like to do the equivalent with std::fstream's. (std::cin is a
>> > basic_istream, not type-equivalent to a basic_ifstream.)
>>
>> But basic_ifstream is a basic_istream.
>
> Sorry for the confusion, I meant that the need to be *identical*, not just
> derivable from the other, because I'm containing their objects (value),
> not references.
> struct foo { ifstream _stream; };
I think you are making a design bug. An iostream is generally not
copyable, so you should always using it via a reference.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Broken makefile given Autoconf version mismatch
Keith Marshall <[EMAIL PROTECTED]> writes: > On Wednesday 12 April 2006 8:47 pm, Stepan Kasal wrote: >> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote: >> > here's a patch that I think does more or less what Bruno's patch >> > intends to do, against current CVS. >> >> I worked on the same issue. We both use the same pattern >> `sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...` > > I'd like, if I may, to sound a note of caution concerning this sed > command syntax: the use of semicolons as command separators in the sed > script is an implementation dependent extension, which is not portable. > On some platforms, the test using this sed syntax *will* fail, not > because the feature you are testing is unsupported, but because the test > itself is invalid. > > In November 2005, Robert Goulding posted these bug reports on > groff@gnu.org: > http://lists.gnu.org/archive/html/groff/2005-11/msg4.html > http://lists.gnu.org/archive/html/groff/2005-11/msg00074.html > > It turns out that Robert was having a problem building CVS groff, > which requires texinfo >= 4.8 to compile the info files, under Mac OS X, > and configure was saying his texinfo was too old, in spite of him having > explicitly just installed texinfo-4.8. The actual problem was that the > configure test employed a sed command with this same semicolon usage, > and was not behaving as expected -- the test failed because *it* was > invalid, *not* because the detected texinfo was too old! Is there any evidence that there exists a sed implementation that does not support the semicolon as command separator? Note that the thread you quote above is _not_ about semicolons being unsupported, but rather about missing ones. Autoconf is using semicolons in sed expressions already for many years (eg in the AC_OUTPUT_FILES macro). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Broken makefile given Autoconf version mismatch
Keith Marshall <[EMAIL PROTECTED]> writes:
> Let me turn that around, and ask if you can provide any documentary
> evidence, other than anecdotal, to suggest that this use of semicolons
> *should* be supported? SUSv3 *expressly* demands that sed directives be
> separated by newlines:
> http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html
"The command can be preceded by s and/or semicolons. The function
can be preceded by s. These optional characters shall have no
effect."
"Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed
by a semicolon, optional s, and another command verb."
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: ac_link variable...
"Ben Bergen" <[EMAIL PROTECTED]> writes: > Is there a way to force "$ac_link" to use a "-c" before the source > file when doing AC_CHECK_LIB? Why would you do that? It subverts the whole point of ac_link. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Noobie question about building libraries: catch 22
Douglas Phillipson <[EMAIL PROTECTED]> writes: > I'm wanting to build a library as part of my application, but since > configure wants to detect my library with the AC_CHECK_LIB Why do you want to check for it if it is part of your application? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: changed from cpp to c, autoconf will not work any more.
William Estrada <[EMAIL PROTECTED]> writes: > I have run into this problem before but don't remember how I fixed it in the > past. > I can't find any place in the source tree that references 'marker.cpp'. But > for > some reason it is remembering 'marker.cpp'. Remove the dependency file in the .deps directory. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How AC_PROG_CC find the cross-compiler?
"Tzu-Chien Chiu" <[EMAIL PROTECTED]> writes: > Thank you. It works now. > > But I am confused. Are the definitions of build, host and target (to > configure script) different in the cases: > (1) building the cross-compiler > (2) building a software with a cross-compiler > > In (1), target is used to specify where the built program will run. > But in (2), host instead is used. It is always the *host* is where the built program will run. When you build a cross compiler, the built compiler will run on the *host*. The *target* (which is only meaningful in compiler-related tools) does not come into play until you actually run the cross compiler, i.e. when you build something with it. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: can autoconf determine if a preprocessor macro is defined or not?
Ed Hartnett <[EMAIL PROTECTED]> writes: > But is there an autoconf way to solve this? I can see how to use > autoconf to detect if a function can be found in a library > (AC_CHECK_LIB), but how do you check if a preprocessor symbol is > defined in a header file? Why do you need autoconf for that? The C preprocessor is perfectly capable of doing it. > Here's what I had to add to get my code to build. I would prefer if > autoconf could add this to config.h, for example: Just use AH_VERBATIM to add anything you like to config.h. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS(sigsetjmp)
"Bruce Korb" <[EMAIL PROTECTED]> writes: > This macro does not work when the headers #define sigsetjmp to > something else. sigsetjmp is special since it's not required to be a normal function. You can't use AC_CHECK_FUNCS to check for it. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS(sigsetjmp)
Thomas Dickey <[EMAIL PROTECTED]> writes: > btw - does AC_CHECK_FUNCS(stat) work? stat() is required to be a > function. Yes, but many libcs are buggy. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS(sigsetjmp)
Bruce Korb <[EMAIL PROTECTED]> writes: > "not required to be a normal function" implies that it is > common knowledge that everybody knows you have to roll your > own AC macro? autoconf does not save you from learning the language you use for programming. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: CC=cc ./configure or ./configure CC=cc
Bruno Haible <[EMAIL PROTECTED]> writes: > 2) As a user, when I build packages in several directories in parallel >in multiple xterms, it's easier to do > $ echo $CC >to view the current settings, than to grovel 200 lines across config.status >in order to see the settings. Try ./config.status --version. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: #if vs. #ifdef -- again (was: AC_CHECK_SIZEOF failing on undefined HAVE_STDINT_H with -Werror)
nash <[EMAIL PROTECTED]> writes: > Wouldn't it be preferrable to use #if so that a config.h token could > be an expression that variously evaluates to T/F depending on other > stuff? For example, > > In config.h somewhere: > #define HAVE_WORKING_MMAP (defined(HAVE_MMAP) && defined(HAVE_MUNMAP)) This won't work anyway, the C standard does not define the behaviour of defined in expanded tokens. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: #if vs. #ifdef -- again (was: AC_CHECK_SIZEOF failing on undefined HAVE_STDINT_H with -Werror)
nash <[EMAIL PROTECTED]> writes: > Really? C99 seems to do so (section 6.10.1). Perhaps I'm reading more > into it than is actually there, though. 6.10.1#3 ... If the token defined is generated as a result of this replacement process or use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Question regarding sscanf() vs. off_t and similar
Philipp Marek <[EMAIL PROTECTED]> writes:
> If I'm doing
> ino_t ino;
> char *name;
> sprintf("%Lu %s", ino, name);
Note that "L" is not a valid length modifier for integer formats.
> that works fine for 64bit systems, but writes trash for sizeof(ino_t) == 4.
>
> Is there an easy way to find the format strings (sprintf, printf, sscanf) for
> various system types, or something like that?
Assuming you meant %llu instead of %Lu you can always add a cast to
unsigned long long to match the format.
> Or has somebody some already defined preprocessor magic to get this for some
> variable?
> I'm thinking of something along the lines
> #define FORMAT(x)
> #if sizeof(x) == 4
> "%l"
> #else
> #if sizeof(x) == 8
> "%L"
> #else
> #error "Don't know size"
> #endif
> #endif
You can't use sizeof in preprocessor directives. Besides that, the size
of an integer says nothing about its type. For example, a 4 byte integer
can be either int or long on an ILP32 system, and an 8 byte integer can be
long or long long on an LP64 system.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Question regarding sscanf() vs. off_t and similar
Philipp Marek <[EMAIL PROTECTED]> writes: > On Thursday 14 September 2006 15:01 Andreas Schwab wrote: >> Note that "L" is not a valid length modifier for integer formats. > For gnu libc it is: > http://www.gnu.org/software/libc/manual/html_node/Integer-Conversions.html#Integer-Conversions It's better not to depend on non-standard extensions when it is easy to avoid. >> Assuming you meant %llu instead of %Lu you can always add a cast to >> unsigned long long to match the format. > Yes. But that's a bit unclean, and doing that unnecessarily in a loop for > ~30 iterations is something I'd like to avoid. String formatting isn't exactly fast anyway, so the conversion would most likely be lost in the noise. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: unexpected editing of argument to AH_BOTTOM
"John W. Eaton" <[EMAIL PROTECTED]> writes: > Note that the #undef is commented out. The documentation for > AH_BOTTOM says > > ? Macro: AH_BOTTOM (text) > > Include text at the bottom of the header template file. > > so I wasn't expecting the text to be modified. #undef is special in a config header, see (autoconf)Header Templates. That is independent on how the #undef has been put in the template. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: 2.60 and AC_FUNC_GETGROUPS
Bill Moseley <[EMAIL PROTECTED]> writes: > What happened that GETGROUPS_T is no longer defined as gid_t? Don't define GETGROUPS_T yourself. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: using builddir/srcdir at configure time
[EMAIL PROTECTED] (Karl Berry) writes: > I am wondering if there's a reasonable way to use the top_builddir and > top_srcdir values at configure time. As in: > CPPFLAGS="$CPPFLAGS -I$top_builddir/whatever" At configure time $top_builddir == "." and $top_srcdir == $srcdir. They are only different in sub-makefiles. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: After upgrade autoconf from 1.13 to 2.57, I experienced some problems - HELP
Thomas Dickey <[EMAIL PROTECTED]> writes: > On Wed, 6 Dec 2006, Ralf Wildenhues wrote: > >> * Thomas Dickey wrote on Wed, Dec 06, 2006 at 09:15:12PM CET: >>> On Wed, 6 Dec 2006, Ralf Wildenhues wrote: >>> >>>> 2.57 was released six years ago. I don't think you can expect much help >>> >>> four years as of last week. > > agreed that it's been a while. > > In contrast, I can plug current ncurses libraries into a system that's > built with ncurses 5.0, and just assume it'll work. That's from 1999. That's not a useful comparison. How many new features have been added to ncurses in the last 6 years? Also, try compiling the 6 years old code with a state-of-the-art compiler. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: After upgrade autoconf from 1.13 to 2.57, I experienced some problems - HELP
Thomas Dickey <[EMAIL PROTECTED]> writes: > On Thu, 7 Dec 2006, Andreas Schwab wrote: > >> Thomas Dickey <[EMAIL PROTECTED]> writes: >>> In contrast, I can plug current ncurses libraries into a system that's >>> built with ncurses 5.0, and just assume it'll work. That's from 1999. >> >> That's not a useful comparison. How many new features have been added to >> ncurses in the last 6 years? Also, try compiling the 6 years old code > > A lot more than autoconf. Run a diff and compare. A diff doesn't say anything. The NEWS file lists only bug fixes, AFAICS. >> with a state-of-the-art compiler. > > Again, works better than you're insinuating. Doesn't work. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Stack direction check fails with optimizations
Roger While <[EMAIL PROTECTED]> writes:
> Any reason why the following should not work ? -
>
> int
> growsdown (void *x)
> {
> int y;
> return x > (void *)&y;
> }
>
> int
> main()
> {
> int x;
> exit (growsdown(&x));
> }
That could fail exactly the same way if growsdown were inlined by the
compiler.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Use "$(MKDIR_P) sys", not race-prone "test -d sys || mkdir sys".
Bruno Haible <[EMAIL PROTECTED]> writes: > Jim Meyering wrote: >> I wonder which use case made it so using AC_SUBST wasn't an option. > > IIRC, it is when the user specifies > ../path/configure --srcdir=../path > with a relative pathname. Normally you can omit --srcdir, because configure > finds it by itself; then $ac_srcdir is an absolute path; $ac_srcdir will be relative even if you omit --srcdir. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: "has changed since the previous run"
DJ Delorie <[EMAIL PROTECTED]> writes: > They share config.cache, because it saves a lot of time. Not any more. Nowadays every configured subdirectory gets its own cache. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to check type size
Andrew Makhorin <[EMAIL PROTECTED]> writes: > I need to check the size of some generic types, and if the size is > unexpected, the configure script must raise a "configuration error". See AC_CHECK_SIZEOF. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to check type size
Andrew Makhorin <[EMAIL PROTECTED]> writes: > However, AC_CHECK_SIZEOF does *not* that I need. It defines certain > macros to be used later during compilation You can also use AC_COMPUTE_INT to set a shell variable. > while I want the configure script just to raise an error if some types > have unexpected sizes, for example, if 'int' is not of 4 bytes long. If you want fixed sized type you should use the ones from . Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Why "unknown"?
Mike Sharov <[EMAIL PROTECTED]> writes: > Why does config.guess prints "unknown" instead of "pc" for PCs? What is a PC anyway? Is a 32 cpu system a PC? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to substitute variables in script files? (Why is $prefix set to NONE?)
Stefano Sabatini <[EMAIL PROTECTED]> writes:
> Follow a possible implementation of this suggestion:
>
> to put in the input Perl script "script.in" something as:
> my $prefix="@prefix@";
> ...
> my $system_config_file= "@SYSCONF_DIR@/script.conf";
>
> In the resulting "script" file, prefix will be expanded to something as
> "/usr/local", while the last line will appear as:
>
> my $system_config_file= "${prefix}/etc/script.conf";
>
> It happens that *accidentally* the ${prefix} notation is understood by
> Perl, so the script will perform *running time* the right
> substitution.
These substitutions are designed to be used in a makefile where the
variables are recursively expanded.
> Unfortunately it's rather ad-hoc solution and not very clear from the
> point of view of the script.in reader, and it's not applicable to
> other scripting languages that don't support that particular
> shell-like syntax (e.g. lisp).
For other languages besided makefiles it is recommended to do the
substitution not during configuration, but at build time using the
recursively expanded values in the makefile.
> 2) So the corresponding solution will be:
>
> to put in configure.ac:
>
> SYSCONF_DIR=`test "$prefix" = NONE && prefix=$ac_default_prefix; eval echo
> "${sysconfdir}"`
The problem with this approach is that the value is not recursively
expanded. The second level expansion could still refer to other
variables. For example, a recent addition to autoconf is the datarootdir
variable, and datadir is now defined in terms of datarootdir, which in
turn is defined in terms of prefix. A two level expansion of datadir will
no loger lead to a fully expanded value.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: autoreconf warning message: autom4te: cannot lock autom4te.cache/requests with mode 2: Invalid argument
"David Byron" <[EMAIL PROTECTED]> writes: > The subject says it all. I'm getting a warning message running autoreconf > that I've never seen before. Here's the full output: > > $ autoreconf -fvi > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --force -I m4 > autom4te: cannot lock autom4te.cache/requests with mode 2: Invalid argument [...] > I see these warnings on an HP-UX 11 machine. Looks like your perl does not properly implement flock. See sub lock in Autom4te/XFile.pm. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to use variable with translit definitions
Vincent Torri <[EMAIL PROTECTED]> writes: > Hey, > > I've written an m4 macro which is basically: > > > AC_DEFUN([AC_CHECK_ECORE_MODULE], > [ > pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl > > ecore_]DOWN[_libs="" > > AC_SUBST(ecore_]DOWN[_libs) > > popdef([DOWN]) > ]) After AC_DEFUN has been executed the body of AC_CHECK_ECORE_MODULE basically looks like this: pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl ecore_DOWN_libs="" AC_SUBST(ecore_DOWN_libs) popdef([DOWN]) Note that the outer level of quoting has been stripped at the time the AC_DEFUN macro was expanded. > But it seems that I do not use correctly the DOWN variable (ecore_***_libs > is not subsituted). I have tried with DOWN instead of ]DOWN[ without > success. > > Does someone know the correct syntax to do what I want ? What you want is that the body of the macro looks like this: pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl ecore_[]DOWN[]_libs="" AC_SUBST(ecore_[]DOWN[]_libs) popdef([DOWN]) Now put a pair of quotes around it, and you get this: AC_DEFUN([AC_CHECK_ECORE_MODULE], [ pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl ecore_[]DOWN[]_libs="" AC_SUBST(ecore_[]DOWN[]_libs) popdef([DOWN]) ]) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: new line added to a variable passed to a macro
Vincent Torri <[EMAIL PROTECTED]> writes:
> That is, a new line is added. I don't know why. It is annoying as I am
> doing the test on $3 (note that the third parameter is optional). What is
> also strange is that I use that macro several times, and that new line is
> only added when I call:
>
> AC_CHECK_ECORE_MODULE([Ipc],
> ["yes"],
> [${have_ecore_con}]
^^^
The newline is here. m4 does not strip trailing whitespace when gathering
arguments. Either put the closing paren directly after it, or use dnl.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: new line added to a variable passed to a macro
Vincent Torri <[EMAIL PROTECTED]> writes:
> off topic : is it better to use ${have_ecore_con} or $have_ecore_con ?
It does not really matter, but the former is more robust.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Why if test "xSTRING1= "xSTRING2" (the 'x') ?
Jules Colding <[EMAIL PROTECTED]> writes: > Hi, > > I'm wondering why I keep seeing the > > if test "xSTRING1" = "xSTRING2"; then > else > fi > > construction when you want to compare the strings STRING1 and STRING2. This avoids any spurious interpretation as an operator if either string might start with a dash. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Why if test "xSTRING1= "xSTRING2" (the 'x') ?
Keith MARSHALL <[EMAIL PROTECTED]> writes: > Jules Colding wrote: >> I'm wondering why I keep seeing the >> >> if test "xSTRING1" = "xSTRING2" ... > > The common idiom is `if test x$foo = xbar ...', and the `x' is > a placeholder, in case $foo happens to expand to nothing. If $foo happens to expand to multiple words this will fail as well. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Why if test "xSTRING1= "xSTRING2" (the 'x') ?
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Jules Colding on 3/26/2007 7:10 AM:
>> if test "xSTRING1" = "xSTRING2"; then
>> else
>> fi
>>
>> Probably something entirely fundamental that I just forgot...
>
> Portability. Suppose STRING1 is '(' and STRING2 is ')'. Then 'test "x("
> = "x)"' is false, while 'test ( = )' is true.
Note that POSIX mandates that the latter is false as well. May not matter
much, since there are many broken implementations out there.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_ARG_ENABLE: problem with the output of configure --help
Vincent Torri <[EMAIL PROTECTED]> writes: > I've written an m4 macro (see attached file). ENOENT. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_ARG_ENABLE: problem with the output of configure --help
Vincent Torri <[EMAIL PROTECTED]> writes: > if test "x$2" = "xno" ; then > AC_ARG_ENABLE(ecore-[]DOWN, > AS_HELP_STRING( > [--enable-ecore-[]DOWN], > [enable the ecore_[]DOWN module. [[default=disabled]]] > ), > [ want_ecore_[]DOWN=$enableval ], > [ want_ecore_[]DOWN=no ]) > else > AC_ARG_ENABLE(ecore-[]DOWN, > AS_HELP_STRING( > [--disable-ecore-[]DOWN], > [disable the ecore_[]DOWN module. [[default=enabled]]] > ), > [ want_ecore_[]DOWN=$enableval ], > [ want_ecore_[]DOWN=yes ]) > fi You cannot influence the generation of the configure script at runtime for obvious reasons. The expansion of the right AC_ARG_ENABLE must be selected by m4 conditionals. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: passing a macro as an argument of macro
Vincent Torri <[EMAIL PROTECTED]> writes: > dnl i want to use the 1st arg as a macro. Something like that: > > $1([have_xx="yes"], [have_xx="no"]) > > ]) > > MAIN_MACRO would be used that way: > > MAIN_MACRO(MACRO1) > MAIN_MACRO(MACRO2) > > Is it possible ? Sure. > If yes, what is the syntax I should use in MAIN_MACRO ? You've already found out by yourself. :-) Just make sure you properly quote the macro name in the argument, so that it isn't expanded too early. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Configure can't find library but g++ can
astro9672 <[EMAIL PROTECTED]> writes: > # check for libcsv > AC_CHECK_LIB(csv, > main, > LIBS="$LIBS -lcsv", > AC_MSG_ERROR([*** libcsv library not found!]) > ) You should always quote nested macro invocations. AC_CHECK_LIB(csv, main, LIBS="$LIBS -lcsv", [AC_MSG_ERROR([*** libcsv library not found!])] ) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: test in a m4 macro and variable created from pushdef
Vincent Torri <[EMAIL PROTECTED]> writes:
> AC_DEFUN([AS_CREATE_DRIVER], [
>
> pushdef([UP], translit([$1], [a-z], [A-Z]))dnl
> pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl
>
> pushdef([SRCUP], translit([$2], [a-z], [A-Z]))dnl
> pushdef([SRCDOWN], translit([$2], [A-Z], [a-z]))dnl
>
> if test "x${use_]DOWN[_driver}" = "xyes"; then
The outer pairs of quotes are removed before the AC_DEFUN macro is
called, thus the argument does not contain the word DOWN any more, but
rather use_DOWN_driver. You need to fix the quoting that they survive
the first pass of parsing:
if test "x${use_[]DOWN[]_driver}" = "xyes"; then
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: autoreconf vs autogen.sh
Roman Rybalko <[EMAIL PROTECTED]> writes: > when I have to include some m4s in m4 dir how I can specify -I m4 option > to aclocal through autoreconf ? Set ACLOCAL_AMFLAGS in the toplevel Makefile.am. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_PATH_PROG or m4 bug
Roman Rybalko <[EMAIL PROTECTED]> writes: > My m4 in some circumstances generates "fi;\n" instead of ")", therefore > AC_PATH_PROG generates broken code. > Can anybody try test-m4 (generate configure, plz). I attached my > generated configure there. Always quote nested macro invocations. > 2) [CHECK_KRB(5)] instead of CHECK_KRB(5) (in all cases) That's the only part that needs to be fixed. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: conversion to git
Eric Blake <[EMAIL PROTECTED]> writes:
> In the meantime, does anyone know the name of the person behind the following
> user-ids, each of which has made commits to autoconf CVS but which left no
> ChangeLog entry and no name in the CVS log for their actions? The various
> commits were all years ago, and touched either config.{guess,sub} or {make-
> stds,standards}.texi. Also listed is the date of the most recent commit by
> the
> uid in question.
The Emacs CVS has the same history for these files (they where shared
RCS files originally). I think I was able to correctly identify some of
them:
> cks 1994-09-22
> erich 1997-07-16
Erich Stefan Boleyn <[EMAIL PROTECTED]>
> gnu 1997-07-04
> hassey 1993-02-10
John Hassey <[EMAIL PROTECTED]>
> ian 1998-01-28
Ian Lance Taylor <[EMAIL PROTECTED]>
> sac 1993-04-30
> wood1993-04-09
For the others I could not find any traces anywhere.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to compile 32bit library on 64bit x86_64 systems?
"Geeky Jim" <[EMAIL PROTECTED]> writes: > ./configure CPPFLAGS=-m32 LDFLAGS="-m32 -L/usr/lib" I think you should rather set CXX to "g++ -m32" instead of using CPPFLAGS/LDFLAGS. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
