2010/6/16, Jakub Hrozek wrote:
> Using size constants in public headers causes problems because the
> public headers for 32bit and 64bit x86 architecture are different and
> cannot be installed in parallel.
>
> For more context, kindly refer to
> https://bugzilla.redhat.com/show_bug.cgi?id=602880
If a packager wishes to distribute two, three or four different
versions of the c-ares library, the packager will have to build each
version he wants to distribute in clean and different trees, allowing
each version to generate its own ares_build.h files.
If the packager wants to install different c-ares versions in parallel
with a single set of external headers, the packager will have to
combine the different ares_build.h generated files into a single one
using appropriate preprocessor symbol definition checks.
On some systems differences in ares_build.h only depend on 32 vs 64
bit build target. These should be very easy for the packager to come
up with a unified ares_build.h.
But there are other systems on which it is not only a matter of 32 vs
64 bit. socklen_t data type (and size) depends on interface or socket
library being used. HPUX comes to my mind in this moment. So in order
to allow proper usage we have to live with this stuff.
It might be a little inconvenience for those wishing to distribute a
single set of headers for different versions of the library. But it
allows us the widest portability.
-- -=[Yang]=-Received on 2010-06-16