Trying to build a 32-bit binary (-m32 GCC flag) that uses libcurl on AMD64 is impossible: /usr/include/curl/curlrules.h:143:41: error: size of array '__curl_rule_01__' is negative /usr/include/curl/curlrules.h:153:53: error: size of array '__curl_rule_02__' is negative Here is a simple test program: #include <curl/curl.h> int main(void) { return 0; } Compile with: gcc -m32 curl_test.c Reproducible: Always
Please post your `emerge --info' output too.
Created attachment 271845 [details] emerge --info
I can confirm this on amd64, trying to build 32bit binary on 64bit fails with reported error.
I met the same problem.
This is because you get amd64-specific headers (CURL_SIZEOF_LONG defined as 8, but it is 4 on x86). Considering you also only have a 64bit shared library, using a different $ROOT for a 32bit curl would make most sense. Upstream seems to suggest using a different prefix for different ABIs: http://curl.haxx.se/mail/lib-2008-09/0051.html
Should be fixed in -r1
Hmm, not god.. =cmake-2.8.5-r2 build fails now with =net-misc/curl-7.21.7-r1 installed on ~x86 System [ 17%] Built target cmsysTestsCxx [ 18%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmCommands.cxx.o In file included from /usr/include/curl/curl.h:35:0, from /var/tmp/portage/dev-util/cmake-2.8.5-r2/work/cmake-2.8.5/Utilities/cm_curl.h:18, from /var/tmp/portage/dev-util/cmake-2.8.5-r2/work/cmake-2.8.5/Source/cmFileCommand.cxx:18, from /var/tmp/portage/dev-util/cmake-2.8.5-r2/work/cmake-2.8.5/Source/cmBootstrapCommands.cxx:46: /usr/include/curl/curlrules.h:153:53: error: size of array '__curl_rule_02__' is negative [ 18%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmCommandArgumentLexer.cxx.o make[2]: *** [Source/CMakeFiles/CMakeLib.dir/cmBootstrapCommands.cxx.o] Error 1 Is it now a curl or cmake Bug?
Created attachment 280551 [details] dev-util/cmake-2.8.5-r2 build.log
Does it fixed? Seems no. My build on ~x86 failed, with the same issue (~amd64 builds fine) Curl checks size of curl_off_t type: typedef char __curl_rule_02__ [CurlchkszEQ(curl_off_t, CURL_SIZEOF_CURL_OFF_T)]; which stringly defined as int64_t: curlbuild.h:171 /* Signed integral data type used for curl_off_t. */ #define CURL_TYPEOF_CURL_OFF_T int64_t /* Data type definition of curl_off_t. */ typedef CURL_TYPEOF_CURL_OFF_T curl_off_t whereas CURL_SIZEOF_CURL_OFF_T differs for 32 and 64 bit: curlbuild.h:186 /* The size of `curl_off_t', as computed by sizeof. */ #ifdef __LP64__ #define CURL_SIZEOF_CURL_OFF_T 8 #else /* !__LP64__ */ #define CURL_SIZEOF_CURL_OFF_T 4 #endif /* __LP64__ */ Locally, I'm changed CURL_SIZEOF_CURL_OFF_T to 8, and cmake builds fine now (do not use this as a fix).
(In reply to comment #9) > Does it fixed? Seems no. My build on ~x86 failed, with the same issue (~amd64 > builds fine) I fixed it several hours before your comment, please sync first
net-misc/curl-7.21.7-r2 fixed it for me on x86, cmake builds now fine. Thank you
this bug is invalid. almost none of the packages installed for amd64 systems are designed to be straight compiled for any other ABI (with like glibc/gcc being the exceptions). the proposed hack doesn't actually make the curl headers usable -- you have no guarantee that the curl libs that happened to be bundled with the emul-xxx have the same ABI as the curl you have installed natively via `emerge curl`. if you want to build for different ABI's, you'll need to do so yourself (like upstream suggested), or use the multilib project (see Bug 145737). Christoph: can i go ahead and drop this ? the `ed` requirement is fairly unusual ...
ncurses and curl need this because of their popularity. We had ncurses, now we also have curl.
i have no idea what you're talking about with ncurses. there is no code in the ebuild to try and do anything like this. if you want to convince upstream curl to try and support multiple ABIs simultaneously, then that's one place to do it. but this hack doesn't belong in any ebuild. any claimed "popularity" is irrelevant.
(In reply to comment #14) > i have no idea what you're talking about with ncurses. I mean that "-m32" works when building a curses application. > there is no code in the ebuild to try and do anything like this. > > if you want to convince upstream curl to try and support multiple ABIs > simultaneously, then that's one place to do it. but this hack doesn't belong > in any ebuild. any claimed "popularity" is irrelevant. It's your job as a distro to get this right. Upstream doesn't need to care.
I don't have a strong opinion on whether to support this, the ed scripts I added are from macports iirc, so they're trying to cross-compile too for some reason. Also I think pacho had problems building the emul-linux packages without it.
(In reply to comment #15) why don't you fully read my first comment. we *are* getting this right. the proposed hack is not the way to do it. (In reply to comment #16) that sounds pretty unusual, and more like something else is going on. i'll poke him to find out what he's doing.
(In reply to comment #17) > (In reply to comment #15) > > why don't you fully read my first comment. we *are* getting this right. the > proposed hack is not the way to do it. Well, it didn't seem to work. Unless there's something I didn't see, no emul-package provided correct headers for curl. (Many others do, if you emerge them with the "development" USE flag set.)
the emul-* packages are not what i'm referring to. please read the aforementioned bug.
I just bumped curl-7.25.0 and I left the ed's in there, but I'd really rather remove them because, if their purpose is to try to mix abi's as in the initial description, that's just asking for trouble and patching some headers is not going to save you. Since I'm just picking up as maintainer here along with gregk, do we have some answer to comments 16 and 17 whether there is some other reason we need to keep these header patches? Otherwise they're gone.
Feel free to remove it then. Gentoo doesn't support multilib anyway. I switched to a 32-bit Debian for building my stuff and binaries run OK.
(In reply to comment #21) > Feel free to remove it then. Gentoo doesn't support multilib anyway. I > switched to a 32-bit Debian for building my stuff and binaries run OK. When/if we have native multilib support as per bug #145737, we can revisit this issue. The next ebuild of curl 7.25-r1 will have the ed's removed. Please reopen this bug if there's any good reason why I shouldn't.