https://bugs.launchpad.net/ubuntu/+source/curl/+bug/723739
Cross compiling (-m32) a 32-bit application that relies on libcurl in a 64-bit host fails with:
In file included from /usr/include/curl/curl.h:35,
from ....:
/usr/include/curl/curlrules.h:143: error: size of array '__curl_rule_01__' is negative
/usr/include/curl/curlrules.h:153: error: size of array '__curl_rule_02__' is negative
curl version information
xubuntu$ curl -V
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
xubuntu$ uname -a
Linux xubuntu 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
libcurl is designed to be built and installed with one architecture per install path. If you try to use that install path with a compiler with a different architecture, all bets are off. It's impossible for libcurl to know about what combinations of architectures a user might want to install together, so it can't provide for that in the general case. The approach taken by Fedora (as mentioned in the bug) is the right one, and it's done by the right entity (the packager).
Having said that, there was a recent suggestion on the curl-library mailing list about making the include files more architecture independent, but that's impossible to do in the general case and doesn't come without a down side even if it were done.
Thanks Dan. Indeed, I thought it was maybe possible to build in a more system independent way, but if there are too many draw backs, better leave it to the packaging team as you mentioned.
Thanks, as explained this is basically by design and generating multiple headers for multiple architectures/platforms is possible but requires a little hands on.