Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.214.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=SwH5a2OPffu1iggW1zzGCuAnn60cqsxFp1FHv+I4XUokVZilxbV3WQYydK/EI6EbTQ
         4w0LGLdt8OEvxeOd2Ke7KcATsa8hQpslAP7+de9St83NKdA5yUyYj68TaqNQrLK6MdYi
         5kb+2nGmnuv5Znqz4GsojTB1Log+sl8lPgC2I=
MIME-Version: 1.0
In-Reply-To: <4DA47A46.5060904@rowe-clan.net>
References: <BANLkTimZWUw2_iZ4BwZM6=Cr+D8i-hM3rA@mail.gmail.com>
	<4DA467CA.4080900@rowe-clan.net>
	<BANLkTikj-KdM56H-JG2+h=0T2AXk8U9F6g@mail.gmail.com>
	<4DA47A46.5060904@rowe-clan.net>
Date: Tue, 12 Apr 2011 12:22:48 -0400
Message-ID: <BANLkTi=v8nupH0+0u=bsR0QmiqAm=K7WqA@mail.gmail.com>
Subject: Re: MinGW status
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 12, 2011 at 12:13 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> On 4/12/2011 10:21 AM, Jeff Trawick wrote:
>> On Tue, Apr 12, 2011 at 10:55 AM, William A. Rowe Jr.
>> <wrowe@rowe-clan.net> wrote:
>>> On 4/11/2011 3:09 PM, Jeff Trawick wrote:
>>>>
>>>> # enableIPv6
>>>> export ac_cv_define_sockaddr_in6=3Dyes
>>>> export ac_cv_working_getaddrinfo=3Dyes
>>>> export ac_cv_working_getnameinfo=3Dyes
>>>> export ac_cv_func_gai_strerror=3Dyes
>>>
>>> Since *every* version of Windows we support (post-2000 server, eol last=
 year)
>>> now ships the IPv6 feature set (and driver stack), can we override this=
 list
>>> in ./configure? =A0It sounds like this gets us the rest of the way ther=
e.
>>
>> I will add.
>>
>> Any clue if WinCE has this?
>
> OS Versions: Windows CE .NET 4.1 and later.
> Header: Ws2tcpip.h.
> Link Library: Ws2.lib.
>
> Here again we have to ponder how many revisions backwards we want to supp=
ort
> for CE?

Let's see who crawls out of the woodwork first.

>
>>> could probably simply dodge --disable-ipv6, or let it override the abov=
e
>>> values for someone who really insists on trying this. =A0Given the stat=
e of
>>> addressing allocations, it isn't something we should encourage ;-)
>>
>> We can punt at least until compatibility becomes more of an issue.
>
> :)
>
>> Trunk's apr.hw can default it to enable, right?
>
> Yes. =A0I'm pondering if we shouldn't switch the default as of 1.4.3. =A0=
I'm
> absolutely going to switch it for httpd 2.3 beta builds, and wonder if we
> should not enable it for an httpd 2.2.18, if and when.

1.4.x's apr sockaddr:

struct apr_sockaddr_t {
...
    /** Union of either IPv4 or IPv6 sockaddr. */
    union {
        /** IPv4 sockaddr structure */
        struct sockaddr_in sin;
#if APR_HAVE_IPV6
        /** IPv6 sockaddr structure */
        struct sockaddr_in6 sin6;
#endif
#if APR_HAVE_SA_STORAGE
        /** Placeholder to ensure that the size of this union is not
         * dependent on whether APR_HAVE_IPV6 is defined. */
        struct sockaddr_storage sas;
#endif
    } sa;
};

no APR_HAVE_SA_STORAGE for the Windows build, so the size changes when
you toggle APR_HAVE_IPV6

>>> MSVCRT - that is pretty much defined by the mingw/msys toolchain's defi=
nitions.
>>> It is something we shouldn't (attempt to) override.
>>
>> The work you're consolidating/tweaking/??? has some bearing on this
>> general issue, right? =A0I also see some hints that MinGW relies on the
>> real MSVCRT (which one? urban legend?) but haven't delved into that at
>> all.
>
> It is a matter of how we build, more than what the .dsp files say. =A0Win=
dows
> is famous for multiple cl.exe/link.exe flavors each of which produce an
> entirely different result, targeted at a specific processor, compatible w=
ith
> different input .lib formats, producing different .pdb results, etc etc e=
tc :)
>
> My particular win32 flavor of gcc version 3.4.5 (mingw-vista special r3),
> gcc.exe itself depends exclusively on msvcrt.dll (the Microsoft Windows
> System Library, always present and somewhat eternal).
>
> I'm looking again at Strawberry perl, also built with mingw/msys, and wha=
tever
> I observed earlier (perhaps their .msi package) doesn't jive with what I'=
m
> looking at in their -portable .zip package. =A0That one binds perl.exe an=
d
> perl512.dll to msvcrt.dll as well. =A0FWIW, so does ActiveState perl.exe =
all the
> way through 5.12.3 build 1204.
>
> Grab yourself http://www.dependencywalker.com/ - lots of fun for examinin=
g
> build results, although I wish my mingw toolchain included good old ldd ;=
-)
> If you get to playing in 64-bit, you'll need a different binary (they are
> distinct for 32 and 64 bits due to the loading games they play).
>
> In the end, it's the msvcrt.lib file that rules all, so whatever is in th=
e
> LIB path is going to define the binding, and the INCLUDE path at compile =
time
> had better have corresponded to the library being linked, or YMMV. =A0Thi=
s is
> because some of the crt are functions, some are header-defined external d=
ata,
> some are inline and some is simply defines. =A0Any of the compile time co=
nstructs
> which mismatch are likely to lead to segfaults if not more subtle misbeha=
vior.
>
>> If it becomes a concern, it will only be after more people start using
>> a reasonably working apr+httpd+??? and start flushing out corner
>> cases. =A0(But I speculate that the more surprising change will be more
>> patches for base Windows issues.)
>
> If that happens, I'll be very happy!
>
> Just a footnote, I found three more inconsistencies in fnmatch's range
> processing to IEEE Std 1003.1-2008 (and customary behavior where the spec
> leaves things open), so I ended up tossing rangematch() as well before I =
was
> tangled in family events this weekend. =A0I'll have the replacement poste=
d up
> later today, sorry for the hassle.
>
> There is only one dev question for fnmatch() - today we lowercase the two
> characters (and don't support case-insensitive range matches at all, I wo=
n't
> change this apr-specific quirk). =A0But IIRC there are language with mult=
iple
> lower case representations of the same upper case character, but never vi=
sa
> versa? =A0Shouldn't we upcase them the text and match chars, instead?

this is sure buried in a tangential thread ;)