On 9/25/16 9:56 AM, Brad House via c-ares wrote:
> On 9/25/16 9:46 AM, Daniel Stenberg wrote:
>> On Sun, 25 Sep 2016, Brad House wrote:
>>
>>> The *type* detection was not modified in any way what-so-ever by my patch set.
>>
>> That's what I'm saying. And until we introduce a way to figure out that type in the public header, we can't remove the
>> build-time generation of the header.
>>
>> So yes, we can remove a lot of pointless defines and types but we can't remove the generated header just yet - which I
>> thought was the major point we were dicussing.
>>
>
> Daniel,
>
> Is this opposite day? It seems like everything I write is taken
> as the *exact* opposite of what I'm saying.
>
> I did NOT remove the build-time generation of the header.
> I did NOT remove the build-time generation of the ares_socklen_t type.
>
> You need proof?
>
> * The ares_socklen_t type is *still* detected by configure.ac via the
> CARES_CONFIGURE_ARES_SOCKLEN_T which is still a defined macro
> in acinclude.m4 after my patch is applied.
> Please see the below (lines referenced are after the patch is applied):
> configure.ac : line 524
> acinclude.m4 : line 1758
> This clearly has NOT been removed.
>
> * ares_build.h.in is still converted by autotools into the distributed
> ares_build.h using this build-time configuration logic via
> AC_CONFIG_HEADERS([ares_config.h ares_build.h])
> in configure.ac
> Pleases see the below line after the patch is applied:
> configure.ac : line 12
> This clearly has NOT been removed.
>
>
> None of what you are saying you are concerned about is changed in any
> way what-so-ever by my patch.
>
>
> -Brad
I should also-recap the GOAL of the patch. The goal is for MacOSX and iOS
to allow multi-arch building. With MacOSX, when you set the CFLAGS to something
like "-arch i386 -arch x86_64" it builds a "fat" binary, which contains
both architectures in the single binary output.
However, prior to my patch, this was NOT possible as you must not do configure-time
detection of the *size* of types, since they can differ for 32bit vs 64bit (long
on 32bit is 4 bytes, but 8 bytes on 64bit). That would mean in order to generate
a "fat" binary on MacOSX previously, you'd need to run ./configure with a single
arch ... twice ... then combine any resulting libraries and executables together
using the 'lipo' tool ... far from elegant.
This is what my patch fixes, and the *only* thing it fixes, it removes *size*
detection at configure time. *type* detection for things like ares_socklen_t
will NEVER vary for the same system when just using different architectures, so
is safe to do at configure time and this logic was left in place as-is!
-Brad
Received on 2016-09-25