On Fri, 16 Sep 2016, Michael Felt wrote:

The solution people have used ever since to produce headers that can be used dynamically for either 32 bit or 64 bit builds is this:

Well, if all I wanted to do was build curl for personal use, that could be okay - but I am trying to package things than depend on curl (today that is git) - and I want to provide libraries in both 32-bit and 64-bit mode. Again, if it was only my project(s) I could modify my include files.

The method I described (or something similar) has been used by libcurl packagers in linux distributions for a long time. Most non-packagers don't care for building multiple versions.

If someone has a good idea of how to tweak libcurl to make this process easier or more streamlined in any way, please let me know.

So, my suggestion would be to do as you suggest above - in the project. The "complexity" may be to generate both 32-bit and 64-bit during the configure phase.

That would be a way but its a road full of obstacles. We'd first need to figure out that we actually need to do it, then we need to find out how we tell the compiler and linker to work on 32bit vs 64bit environments and then finally generate the both sets. And then we need provide backup methods for when we fail to detect or work out the methods.

And there's no portable or POSIX way to do the 32 vs 64 bit dance.

So possible indeed, but tricky.

The most important difference in 32-vs-64 that we need to figure out (which was the driving factor for us switching to the generated public header file), and that would ideally be done with some sort of #ifdef dance in the public header file, so that the curl_off_t type is properly typedef'ed.

But that's not easy and it was a frequent problem to users back in the day that users got one size in their programs but had another size built into libcurl.

So possible indeed, but tricky.


 / daniel.haxx.se
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Reply via email to