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
