[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memcmp and cross-compilation
From: |
Simon Josefsson |
Subject: |
Re: memcmp and cross-compilation |
Date: |
Tue, 20 May 2008 10:15:09 +0200 |
User-agent: |
Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) |
Simon Josefsson <address@hidden> writes:
> Simon Josefsson <address@hidden> writes:
>
>> Simon Josefsson <address@hidden> writes:
>>
>>> MinGW apparently needs gnulib's memcmp module
>>
>> That was rather surprising to me, so I started investigating why that is
>> the case.
>
> The reason was that Autoconf's AC_FUNC_MEMCMP uses AC_RUN_IFELSE with a
> cross-compile default of no. I prefer to assume memcmp exists on
> cross-compile targets since I assume C89 or later in my projects. That
> is probably not the right choice for autoconf, but I think it is for
> gnulib. Thus it seems gnulib needs to extend autoconf's test somewhat?
> I'll suggest something for review.
The patch below works in the sense that, for cross-compilations only, it
will assume that memcmp works when it is declared. This works better
for MinGW.
However, I'm not sure this is the right thing -- the memcmp module is
listed in gnulib as a compatibility module for systems lacking ANSI C89.
It could be argued that if one is cross-compiling to one of the systems
that has memcmp but would fail the run-time tests of memcmp in the
autoconf check (i.e., Next x86 OpenStep and non-8-bit clean
implementations), that person would expect gnulib to pull in the
replacement module.
On the other hand, we don't know if such cross-compile targets exists.
We can take the lazy evaluation approach to install the patch and wait
until someone reports a problem and solve it then. When that happens,
we could see if we can make the cross-compile check smarter, so that it
works for both MinGW and for the hypothetical cross-compile target with
a broken memcmp.
Jim, what do you think?
(An alternative solution would be to teach Autoconf AC_RUN_IFELSE that
it _can_ run cross-compiled EXE binaries. That is probably more
complicated..)
/Simon
diff --git a/m4/memcmp.m4 b/m4/memcmp.m4
index 099b141..1c3d1fc 100644
--- a/m4/memcmp.m4
+++ b/m4/memcmp.m4
@@ -1,11 +1,23 @@
-# memcmp.m4 serial 12
-dnl Copyright (C) 2002, 2003, 2004, 2007 Free Software Foundation, Inc.
+# memcmp.m4 serial 13
+dnl Copyright (C) 2002, 2003, 2004, 2007, 2008 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
AC_DEFUN([gl_FUNC_MEMCMP],
[
+ if test $cross_compiling != no; then
+ # AC_FUNC_MEMCMP as of 2.62 defaults to 'no' when cross compiling.
+ # We default to yes if memcmp appears to exist, which works
+ # better for MinGW.
+ AC_CACHE_CHECK([whether cross-compiling target has memcmp],
+ [ac_cv_func_memcmp_working],
+ [AC_LINK_IFELSE([
+ AC_LANG_PROGRAM([[#include <string.h>
+ ]], [[int ret = memcmp ("foo", "bar", 0)]])],
+ [ac_cv_func_memcmp_working=yes],
+ [ac_cv_func_memcmp_working=no])])
+ fi
AC_FUNC_MEMCMP
dnl Note: AC_FUNC_MEMCMP does AC_LIBOBJ(memcmp).
if test $ac_cv_func_memcmp_working = no; then
Re: rpl_memcmp on mingw with g++?, Bruno Haible, 2008/05/20