On Sunday, June 15, 2014 14:23:11 Alessandro Ghedini wrote:
> > Fix the problem where header files became platform/architecture dependent
> > (a few years ago), making cross-builds cumbersome even in such a simple
> > scenario as building 32-bit libcurl on a 64-bit Linux system. It would
> > seem to be a better solution to detect bitness and other platform
> > dependent stuff dynamically inside the headers at compile-time. [Sorry if
> > this was sorted out since.]

We do exactly that in Fedora packages, which need to be multilib-ready:

http://pkgs.fedoraproject.org/cgit/curl.git/tree/curlbuild.h

> A while ago I made the Debian libcurl dev packages (those shipping the
> header files) support multi-arch (i.e. the possibility of installing the
> same package from multiple architecture at the same time). This didn't
> quite work as expected partly because of the above reason.
>
> I'm planning to move the libcurl headers from /usr/include to
> /usr/include/<gnu_triplet> but if this could be solved on the libcurl side
> it'd be better I guess.
>
> Another problem I've encountered is that curl-config changes based on the
> architecture it was built on because it embeds the libdir paths (which on
> Debian change from arch to arch because of multi-arch). The --configure
> option is also different. Not sure how this could be fixed though.

You can redirect 'curl-config --configure' to pkg-config as we do on Fedora:

http://pkgs.fedoraproject.org/cgit/curl.git/tree/0101-curl-7.32.0-multilib.patch

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-06-16