Hi,
There's an error on the select() function:
int
rpl_select (int nfds, fd_set *rfds, fd_set *wfds, fd_set *xfds,
struct timeval *timeout)
{
static struct timeval tv0;
static HANDLE hEvent;
HANDLE h, handle_array[FD_SETSIZE + 2];
fd_set handle_rfds, handle_wfds, handle_xfds;
Bruno Haible writes:
> At this point, it would be a good idea to mark all AC_FUNC_* macros that
> request an AC_LIBOBJ replacement as obsolete and refer the user to Gnulib
> for both the macro and the workaround code (and the documentation).
> Except maybe AC_FUNC_MALLOC and AC_FUNC_REALLOC, beca
Bruno Haible writes:
> So, I would propose
> 1) to apply the patch below,
> 2) to use the common idiom
> if test $HAVE_STRTOD = 0 || test $REPLACE_STRTOD = 1; then
> like you did above,
> 3) to improve the cross-compiling guess.
Good ideas. Here is #2. I'll follow up with #3
Bruno Haible writes:
> 1) to apply the patch below,
> 2) to use the common idiom
> if test $HAVE_STRTOD = 0 || test $REPLACE_STRTOD = 1; then
> like you did above,
> 3) to improve the cross-compiling guess.
Here is #3:
>From 60471b91b5dbdf2c24c258640cee6dfdb32c4d6f Mon Sep 17
() Eric Blake
() Mon, 14 Jun 2010 14:37:07 -0600
Since gnulib still maintains ChangeLog in the repository (you _are_
using the git-merge-changelog program, right?), it is appropriate to
include ChangeLog edits as part of your git commit.
OK, thanks for the reminder (yes, i use git-merge
On 06/14/2010 02:25 PM, Thien-Thi Nguyen wrote:
> BTW, gnulib folks: Here is a suitable ChangeLog entry:
>
> 2010-06-14 Thien-Thi Nguyen(tiny change)
>
> git-version-gen: Init shell var to avoid env var influence.
> * build-aux/git-version-gen (v): Init shell var to empty.
Sin
On 06/14/2010 01:56 PM, Bruno Haible wrote:
>> Or even better, why not push those two tests upstream into autoconf,
>> then have gnulib override AC_FUNC_STRTOD if it detects older autoconf,
>> so that everyone using upstream AC_FUNC_STRTOD can reliably detect these
>> same bugs?
>
> I don't think
Progress report from the "energetic (ha!) curmudgeon"
I have
- upgraded my computer from Etch to Lenny;
- installed the requisite support packages, except for libtool (libltdl)
and libunistring, which are installed under prefix /home/ttn/local;
- done a "git pull" earlier today;
- successful
Hi Eric,
> > With two old old old tests and no reasonable cross-compiling behaviour I
> > would say that the best thing to do is to move these two blocks of C
> > code
> > into gl_FUNC_STRTOD's test, and stop using AC_FUNC_STRTOD. Then the
> > autoconf documentation can mark this
Jan Andersen wrote on bug-tar:
> I am trying to build tar from source on AIX 5L, but it fails with:
>
> CC priv-set.o
> In file included from priv-set.c:23:
> priv-set.h:24:19: error: priv.h: A file or directory in the path name does
> not exist.
> ...
>
> I have tried to #undef HAVE_PRIV
Hi Ben,
* Ben Pfaff wrote on Mon, Jun 14, 2010 at 06:36:17PM CEST:
> Here is another approach that I had not thought of before.
> What if we added the following to
> modules/relocatable-prog-wrapper:
> *) cd $(top_builddir) && \
> $(MAKE) $(AM_MAKEFLAGS) EXEEXT=.bin$(EXEEXT
Eric Blake writes:
> Or even better, why not push those two tests upstream into autoconf,
> then have gnulib override AC_FUNC_STRTOD if it detects older autoconf,
> so that everyone using upstream AC_FUNC_STRTOD can reliably detect these
> same bugs?
The strtod() tests that are currently in gl_F
On 06/14/2010 12:01 PM, Ben Pfaff wrote:
> Eric Blake writes:
>
>> Or even better, why not push those two tests upstream into autoconf,
>> then have gnulib override AC_FUNC_STRTOD if it detects older autoconf,
>> so that everyone using upstream AC_FUNC_STRTOD can reliably detect these
>> same bug
[adding bug-autoconf]
On 06/13/2010 05:43 PM, Bruno Haible wrote:
> Hi Ben,
>
>> The problem is that AC_FUNC_STRTOD assumes that strtod does not
>> exist when cross-compiling, which in turn makes the strtod module
>> assume that it does not need to handle an existing declaration.
>
> Ah, so AC_F
Bruno Haible writes:
>> +uninstall-hook: uninstall-relocwrapper
>> +uninstall-relocwrapper:
>> +if RELOCATABLE_VIA_LD
>> +@:
>> +else
>> +if test $(RELOCATABLE) = yes; then \
>> +case '$(EXEEXT)' in \
>> +.bin*) ;; \
>> +*) $(MAKE) uninstall EXEEXT=.bin$(EX
() Bruno Haible
() Sun, 13 Jun 2010 15:57:00 +0200
For me, it's a bit different: I don't think the number of modules
has a lot of information.
Perhaps it's just my (personal) gnulib-newbie fear...
There are some modules, like 'stdint', which provide hardly any code,
and 'regex', whi
16 matches
Mail list logo
