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? >> 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. >> 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?
