Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 365375 - net-misc/curl: Impossible to build 32-bit programs using libcurl on AMD64
Summary: net-misc/curl: Impossible to build 32-bit programs using libcurl on AMD64
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-30 05:49 UTC by Nikos Chantziaras
Modified: 2012-04-07 14:27 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge--info,4.75 KB, text/plain)
2011-05-02 07:02 UTC, Nikos Chantziaras
Details
dev-util/cmake-2.8.5-r2 build.log (build.log,45.26 KB, text/plain)
2011-07-21 20:40 UTC, josef.95
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Chantziaras 2011-04-30 05:49:33 UTC
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
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2011-05-02 01:53:52 UTC
Please post your `emerge --info' output too.
Comment 2 Nikos Chantziaras 2011-05-02 07:02:08 UTC
Created attachment 271845 [details]
emerge --info
Comment 3 Tomáš "tpruzina" Pružina (amd64 [ex]AT) 2011-07-18 12:23:59 UTC
I can confirm this on amd64, trying to build 32bit binary on 64bit fails with reported error.
Comment 4 Liang 2011-07-21 02:52:47 UTC
I met the same problem.
Comment 5 Christoph Mende (RETIRED) gentoo-dev 2011-07-21 08:34:38 UTC
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
Comment 6 Christoph Mende (RETIRED) gentoo-dev 2011-07-21 11:28:58 UTC
Should be fixed in -r1
Comment 7 josef.95 2011-07-21 20:37:05 UTC
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?
Comment 8 josef.95 2011-07-21 20:40:06 UTC
Created attachment 280551 [details]
dev-util/cmake-2.8.5-r2 build.log
Comment 9 k0l0b0k 2011-07-22 04:49:37 UTC
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).
Comment 10 Christoph Mende (RETIRED) gentoo-dev 2011-07-22 07:51:26 UTC
(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
Comment 11 josef.95 2011-07-22 11:21:05 UTC
net-misc/curl-7.21.7-r2 fixed it for me on x86, cmake builds now fine.

Thank you
Comment 12 SpanKY gentoo-dev 2011-12-05 21:19:55 UTC
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 ...
Comment 13 Nikos Chantziaras 2011-12-05 23:47:12 UTC
ncurses and curl need this because of their popularity. We had ncurses, now we also have curl.
Comment 14 SpanKY gentoo-dev 2011-12-06 03:24:08 UTC
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.
Comment 15 Nikos Chantziaras 2011-12-06 10:16:33 UTC
(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.
Comment 16 Christoph Mende (RETIRED) gentoo-dev 2011-12-06 16:57:48 UTC
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.
Comment 17 SpanKY gentoo-dev 2011-12-08 00:04:22 UTC
(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.
Comment 18 Nikos Chantziaras 2011-12-08 11:17:03 UTC
(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.)
Comment 19 SpanKY gentoo-dev 2011-12-09 04:44:24 UTC
the emul-* packages are not what i'm referring to.  please read the aforementioned bug.
Comment 20 Anthony Basile gentoo-dev 2012-03-24 21:28:01 UTC
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.
Comment 21 Nikos Chantziaras 2012-03-24 21:35:10 UTC
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.
Comment 22 Anthony Basile gentoo-dev 2012-04-07 14:27:09 UTC
(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.