cURL / Mailing Lists / curl-library / Single Mail


Re: [Survey] What people want us to do next

From: Kamil Dudka <>
Date: Mon, 16 Jun 2014 10:35:51 +0200

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:

> 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:

List admin:
Received on 2014-06-16