Multilib issue with c-ares
Hello,
I have a problem using c-ares in a multilib environment, for which I
found a patch in Fedora that does not seem to have found its way
upstream. The following minimal code demonstrates the problem:
% cat this.c
#include ares.h
int main() { return 0; }
% x86_64-pc-linux-gnu-gcc -o this -m32 this.c
In file included from /usr/include/ares.h:23:0,
from this.c:2:
/usr/include/ares_rules.h:100:3: error: size of array ‘__cares_rule_01__’
is negative
__cares_rule_01__
^
I.e. using an x86_64 compiler in 32bit mode.
The problem is in ares_build.h and solved by applying this patch (taken
from [1]):
diff -up c-ares-1.10.0/ares_build.h.in.multilib
c-ares-1.10.0/ares_build.h.in
--- c-ares-1.10.0/ares_build.h.in.multilib 2013-05-13
11:40:22.697814087 +0200
+++ c-ares-1.10.0/ares_build.h.in 2013-05-13 11:40:26.236813966 +0200
@@ -96,7 +96,14 @@
#endif
/* The size of `long', as computed by sizeof. */
-#undef CARES_SIZEOF_LONG
+#include bits/wordsize.h
+#if __WORDSIZE == 32
+#define CARES_SIZEOF_LONG 4
+#elif __WORDSIZE == 64
+#define CARES_SIZEOF_LONG 8
+#else
+#error Unknown word size
+#endif
/* Integral data type used for ares_socklen_t. */
#undef CARES_TYPEOF_ARES_SOCKLEN_T
diff -up c-ares-1.10.0/configure.ac.multilib c-ares-1.10.0/configure.ac
--- c-ares-1.10.0/configure.ac.multilib 2013-05-13 11:41:00.480812797 +0200
+++ c-ares-1.10.0/configure.ac 2013-05-13 11:41:17.210812226 +0200
@@ -457,7 +457,6 @@ AC_CHECK_SIZEOF(size_t)
AC_CHECK_SIZEOF(long)
AC_CHECK_SIZEOF(int)
AC_CHECK_SIZEOF(short)
-CARES_CONFIGURE_LONG
AC_CHECK_SIZEOF(time_t)
AC_CHECK_TYPE(long long,
I don't know if this is the correct/prefered solution for the problem,
but it solves the problem for me.
Please consider applying this or a similar patch.
Thank you.
-Markus
[1]
http://pkgs.fedoraproject.org/cgit/c-ares.git/tree/c-ares-1.10.0-multilib.patch
Re: Multilib issue with c-ares
Hello On 8/26/13 4:43 PM, Markus Rothe mar...@unixforces.net wrote: I have a problem using c-ares in a multilib environment, for which I found a patch in Fedora that does not seem to have found its way upstream. In Debian I just installed the ares_build.h header into the arch-specific include path: /usr/include/x86_64-linux-gnu/ares_build.h /usr/include/i386-linux-gnu/ares_build.h But an instruction size clean header would be appreciated. Thanks, Gregor
Re: Multilib issue with c-ares
On Mon, Aug 26, 2013 at 04:28:54PM +, Gregor Jasny wrote: Hello On 8/26/13 4:43 PM, Markus Rothe mar...@unixforces.net wrote: I have a problem using c-ares in a multilib environment, for which I found a patch in Fedora that does not seem to have found its way upstream. Hi, I actually sent the patch upstream: http://c-ares.haxx.se/mail/c-ares-archive-2010-06/0009.shtml After re-reading the discussion 3 years later, it sounds to me like it simply stalled. So for now I keep carrying it as vendor specific c-ares patch. In Debian I just installed the ares_build.h header into the arch-specific include path: /usr/include/x86_64-linux-gnu/ares_build.h /usr/include/i386-linux-gnu/ares_build.h But an instruction size clean header would be appreciated. Thanks, Gregor Well, the Red Hat multiarch approach can be...fun...sometimes. At least for certain definitions of fun. (Think of doxygen documentation that differs in nothing but timestamps etc)
Re: Multilib issue with c-ares
On Mon, 26 Aug 2013, Jakub Hrozek wrote: I have a problem using c-ares in a multilib environment, for which I found a patch in Fedora that does not seem to have found its way upstream. I actually sent the patch upstream: http://c-ares.haxx.se/mail/c-ares-archive-2010-06/0009.shtml After re-reading the discussion 3 years later, it sounds to me like it simply stalled. So for now I keep carrying it as vendor specific c-ares patch. I can't remember why it didn't go in then, quite likely I simply dropped the ball. Now that patch doesn't apply any longer and when I fix it manually it still causes a compiler warning since there's now code using CARES_SIZEOF_LONG. I assume you do something else in Fedora/Red hat? -- / daniel.haxx.se
