2009/11/3, John Engelhart wrote:
> Is there a reason why c-ares places 'configure / build' time in various
> headers? For example, in ares_build.h there's CARES_SIZEOF_LONG.
Yes. The ones in ares_build.h are used when c-ares library is created,
and also by programs compiled using the library. At least, this
prevents problems with values which are returned from the c-ares
external API using using a pointer and for which the pointed data type
has different sizes depending on memory model or whatever else.
Check for example ares_expand_name and ares_expand_string, 'enclen'
out pointer. The need for a 32bit binary and a 64bit binary exists
independently of the prototypes provided in ares.h. An application
linked against the wrong library version will get funny results.
So there's already a problem independently of the the existence of
ares_build.h or not.
The ares_build.h 'mechanism' wil not change things on systems which
build or support just one memory model or architecture. On the other
hand it will ensure that those using a multi architecture platform are
aware enough that more than one library must be built and that each
one must have its matching set of external header files.
And even further, if the one building the library has not been aware
of the need to match binary and headers, the user trying to compile
against the library will certainly detect it. Otherwise
compilation/linking against the wrong library would be more easy.
> The reason why I'm asking is I recently tried to build some code in 64-bit
> mode and the compiler started kicking back stuff like:
>
> Source/Headers/C-Ares/ares_rules.h:102: error: size of
> array '__cares_rule_01__' is negative
Great that is the intention. If for any reason, someone overlooks this
issue it gets caught at compilation time, and not when the application
has been released.
> At first glance, this would seem to make it almost impossible to support
> platforms that support more than one type of architecture simultaneously.
The configure script must run for each architecture, and for each
architecture a different set of headers and binaries must be provided.
Some take the different headers and combine them appropriately
depending on architecture, data model or whatever they deem
appropriate. If you want to go this route the only file that you will
need to merge once that you have generated the different versions is
the generated ares_build.h
libcurl library has been using this mechanism for more than one year
now, and problems that were derived of the things that the mechanism
prevents have vanished.
> On Mac OS X, it's possible to simultaneously support big-endian ppc
> (32-bit), ppc64, and little endian i386 (32-bit), x86_64 all at the same
> time, and in the same library (the executable format supports 'fat' binaries
> with an arbitrary number of architectures included in the final binary /
> static library / dynamic library).
We/you are very lucky, Daniel Johnson provided the cURL project with a
Mac OS X shell script that takes care of all the details to make a
four way fat pc/i386/ppc64/x86_64 libcurl.framework. You might get
fine inspiration from it, and maybe adapt/provide one for c-ares.
http://curl.haxx.se/cvs.cgi/curl/MacOSX-Framework?revision=1.2&view=markup
> Having this type of information hard coded in the headers really, really
> complicates things when trying to build universal binaries. I'm now trying
> to figure out a simple way of dealing with this problem, but the easiest
> would seem to be to supply hand hacked versions of ares_rules.h / etc that
> conditionally check and set a lot of the stuff in there depending on various
> compiler preprocessor defines...
Remember, only ares_build.h would need the merging.
> which would seem to defeat the entire
> purpose of having those files (based on the comments).
Ah! yes. As of today your statement is quite true for those who use
'merged' headers. For these cases, additionally, we'll have to
introduce a one-time runtime check, most probably done involving
ares_library_init(), or something else.
-- -=[Yang]=-Received on 2009-11-03