MKDIR_P discovered by configure but not substituted in the Makefile

If I check out gnulib at e190c6630d13363e72ec421e4734ae255c70fbc5 and run ... ./gnulib-tool --create-testdir --dir=/tmp/testdir456 sys_stat cd /tmp/testdir456 ./configure make I get this result :- $ make make all-recursive make[1]: Entering directory `/tmp/testdir456' Making all in gllib make[2

Re: dlfcn.h

On 5/19/07, Eric Blom <[EMAIL PROTECTED]> wrote: Results said, report this bug, so I am. Thanks, Eric > ./z_psocdeve_config.sh checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for egrep... grep -E checking for a sed that does not truncate

Re: re_compile_pattern change

On 12/25/06, Paul Eggert <[EMAIL PROTECTED]> wrote: The 'tar' version is correct. But this is not an Autoconf issue; it is a gnulib version issue. The gnulib fix (dated March 25) is here: http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/m4/regex.m4?r1=1.50&r2=1.51 but apparently findutils is

Re: getloadavg module broken

On 5/19/06, Bruno Haible <[EMAIL PROTECTED]> wrote: Jim Meyering wrote: > may cause trouble for people who put the libobj directory elsewhere. > If any of you know of such a package, please let me know. There are many such packages: - gettext: both libgrep and lib (not just one directory). -

Re: Recommended alloca declaration breaks on alloca.c

On Sun, Apr 10, 2005 at 02:02:20PM +0200, Hrvoje Niksic wrote: > It turns out that the alloca declaration that the Autoconf manual[1] > recommends for config.h declares alloca() as returning char *, whereas > the C implementation I use declares it as returning void *. But > regardless of alloca.c,

Re: Report this to bug-autoconf@gnu.org

On Fri, Mar 04, 2005 at 08:24:24AM +0100, Stepan Kasal wrote: > you should report this bug to the bug report address of the "grip" > project. Tell them to read the section "Present But Cannot Be Compiled" > of the manual to autoconf-2.59. In retrospect it would have saved many emails to this mai

Re: Portability issue with `putenv'

On Tue, Feb 22, 2005 at 04:45:42PM +0100, Sam Lauber wrote: > [ James Youngman wrote: ] > > > You're right, I hadn't thought of that. According to the POSIX > > standard (IEEE Std 1003.1, 2003 Edition), > > > >| The 'string' ar

Re: Portability issue with `putenv'

On Tue, Feb 22, 2005 at 08:24:07AM +0100, Tim Van Holder wrote: > 3) I'm not 100% sure, but I _think_ it is allowed to >modify the string you passed to putenv later, and that >such changes will have effect on future getenv() calls; >that behaviour is broken by your version of putenv().

Re: Portability issue with `putenv'

On Mon, Feb 21, 2005 at 07:23:20PM +0100, Sam Lauber wrote: > > > > > > A good replacement for a broken putenv() is (assuming that `putenv' > > > is defined as `rpl_putenv'): > > > > > > #undef putenv > > > int rpl_putenv(s) > > > char *s; > > > { > > > char *t; > > > strcpy(t, s); > > >

Re: Portability issue with `putenv'

On Sun, Feb 20, 2005 at 10:45:37PM +0100, Sam Lauber wrote: > A good replacement for a broken putenv() is (assuming that `putenv' > is defined as `rpl_putenv'): > > #undef putenv > int > rpl_putenv(s) > char *s; > { > char *t; > strcpy(t, s); > return putenv(t); > } The strcpy() call ha

Re: Problem with cl and autoconf

On Thu, Feb 10, 2005 at 04:42:44PM -0800, Paul Eggert wrote: > * lib/autoconf/general.m4 (_AC_PREPROC_IFELSE, _AC_COMPILE_IFELSE, > _AC_LINK_IFELSE): Redirect stdin to /dev/null, in an attempt to > avoid thinking that Allegro Common Lisp's "cl" command is a C++ > compiler.