On Tue, Apr 12, 2011 at 12:13 PM, William A. Rowe Jr.
<wr...@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.
>> <wr...@rowe-clan.net> wrote:
>>> On 4/11/2011 3:09 PM, Jeff Trawick wrote:
>>>>
>>>> # enableIPv6
>>>> export ac_cv_define_sockaddr_in6=yes
>>>> export ac_cv_working_getaddrinfo=yes
>>>> export ac_cv_working_getnameinfo=yes
>>>> export ac_cv_func_gai_strerror=yes
>>>
>>> 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? It sounds like this gets us the rest of the way there.
>>
>> 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 support
> for CE?
Let's see who crawls out of the woodwork first.
>
>>> could probably simply dodge --disable-ipv6, or let it override the above
>>> values for someone who really insists on trying this. Given the state 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. I'm pondering if we shouldn't switch the default as of 1.4.3. 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
>>> definitions.
>>> It is something we shouldn't (attempt to) override.
>>
>> The work you're consolidating/tweaking/??? has some bearing on this
>> general issue, right? I 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. Windows
> is famous for multiple cl.exe/link.exe flavors each of which produce an
> entirely different result, targeted at a specific processor, compatible with
> different input .lib formats, producing different .pdb results, etc etc etc :)
>
> 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 whatever
> I observed earlier (perhaps their .msi package) doesn't jive with what I'm
> looking at in their -portable .zip package. That one binds perl.exe and
> perl512.dll to msvcrt.dll as well. FWIW, so does ActiveState perl.exe all the
> way through 5.12.3 build 1204.
>
> Grab yourself http://www.dependencywalker.com/ - lots of fun for examining
> 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 the
> 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. This is
> because some of the crt are functions, some are header-defined external data,
> some are inline and some is simply defines. Any of the compile time
> constructs
> which mismatch are likely to lead to segfaults if not more subtle misbehavior.
>
>> 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. (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. I'll have the replacement posted 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 won't
> change this apr-specific quirk). But IIRC there are language with multiple
> lower case representations of the same upper case character, but never visa
> versa? Shouldn't we upcase them the text and match chars, instead?
this is sure buried in a tangential thread ;)
