You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2011/04/11 22:09:31 UTC
MinGW status
trunk:
looks pretty good here other than the IPv6 detection; I think the only
test failures are also broken with a Visual Foo build
I build like this:
# enable IPv6
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
./configure --without-iconv --with-expat=/c/MinGW
apr 1.4.x branch:
This is missing trunk fixes for shared library support and the path to
executable files called from testall. I'll look at backporting that
after apr 1.4.3.
# 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
./configure
apr-util 1.3.x branch:
no concerns as far as I know
----/----
How is it at a nitty gritty level? I guess the main concern is with
compatibility with Visual Foo builds.
1. MSVCRT*?
I don't know.
2.Feature set? (APR_HAVE, APR_HAS)
Very, very close. One glitch is that MinGW has a few header files
that, according to apr.hw, Visual Foo is missing.
I guess the default for --enable/disable-ipv6 should match apr.hwfrom
the same branch.
3. ???
Re: MinGW status
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/13/2011 12:53 PM, Jeff Trawick wrote:
>
> After the last commits the main HAVE/HAS differences between apr.hw
> and my MinGW builds of trunk are
>
> Only in apr.h:
> APR_HAVE_DIRENT_H=1
> APR_HAVE_INET_NETWORK=1
> APR_HAVE_SEMAPHORE_H=1
> APR_HAVE_STDINT_H=1
> APR_HAVE_STRCASECMP=1
> APR_HAVE_STRINGS_H=1
> APR_HAVE_STRNCASECMP=1
> APR_HAVE_SYS_TIME_H=1
> APR_HAVE_UNISTD_H=1
These are not true of VC6 through VC9. Therefore I'm guessing that these
are compatibility thunks introduced by gcc/mingw/msys, and they should be
harmless to use if they are detected, and the mingw/msys toolchain gurus
did a good job.
Re: MinGW status
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Apr 12, 2011 at 11:21 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Apr 12, 2011 at 10:55 AM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> APR_HA... excellent! If you can add these other symbols at your leisure,
>> it is good for documentation purposes, even if they have been mismatched
>> for a while. This mingw/msys build should be good to keep them in sync
>> and observe any quirks/differences more regularly! My old method was to
>> ./configure linux and then take a stab at figuring out which was which,
>> and resorting to try to get them aligned. But dozens of configure.in and
>> build/*.m4 patches later, they are going to fall out of alignment again.
>
> I'll see what else I can tweak.
After the last commits the main HAVE/HAS differences between apr.hw
and my MinGW builds of trunk are
Only in apr.h:
APR_HAVE_DIRENT_H=1
APR_HAVE_INET_NETWORK=1
APR_HAVE_SEMAPHORE_H=1
APR_HAVE_STDINT_H=1
APR_HAVE_STRCASECMP=1
APR_HAVE_STRINGS_H=1
APR_HAVE_STRNCASECMP=1
APR_HAVE_SYS_TIME_H=1
APR_HAVE_UNISTD_H=1
Only in apr.hw:
APR_HAVE_DIRENT_H=0
APR_HAVE_INET_NETWORK=0
APR_HAVE_SEMAPHORE_H=0
APR_HAVE_STDINT_H=0
APR_HAVE_STRCASECMP=0
APR_HAVE_STRINGS_H=0
APR_HAVE_STRNCASECMP=0
APR_HAVE_SYS_TIME_H=0
APR_HAVE_UNISTD_H=0
(omitting build-time choices ICONV/IPV6)
No claim here that anything needs to be done about it...
Re: MinGW status
Posted by Jeff Trawick <tr...@gmail.com>.
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 ;)
Re: MinGW status
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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?
Re: MinGW status
Posted by Jeff Trawick <tr...@gmail.com>.
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?
> We
> 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?
> 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.
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.)
> APR_HA... excellent! If you can add these other symbols at your leisure,
> it is good for documentation purposes, even if they have been mismatched
> for a while. This mingw/msys build should be good to keep them in sync
> and observe any quirks/differences more regularly! My old method was to
> ./configure linux and then take a stab at figuring out which was which,
> and resorting to try to get them aligned. But dozens of configure.in and
> build/*.m4 patches later, they are going to fall out of alignment again.
I'll see what else I can tweak.
Re: MinGW status
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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. We
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 ;-)
MSVCRT - that is pretty much defined by the mingw/msys toolchain's definitions.
It is something we shouldn't (attempt to) override.
APR_HA... excellent! If you can add these other symbols at your leisure,
it is good for documentation purposes, even if they have been mismatched
for a while. This mingw/msys build should be good to keep them in sync
and observe any quirks/differences more regularly! My old method was to
./configure linux and then take a stab at figuring out which was which,
and resorting to try to get them aligned. But dozens of configure.in and
build/*.m4 patches later, they are going to fall out of alignment again.
Re: MinGW status
Posted by Jeff Trawick <tr...@gmail.com>.
Oh, how could I forget :)
Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
droplet that looks like this:
75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
(My initial web searches for this issue were not successful, but I
didn't try very hard.)
Re: MinGW status
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/12/2011 10:15 AM, Jeff Trawick wrote:
>>
>> Wondering if it shouldn't just be defined in network_io/win32/sockopt.c
>> if its missing?
>
> I think it should be; I was hoping to see about finding what WSAfoo
> gets returned on a Windows box that doesn't support the option and, if
> seen at runtime once the symbol is always available, map that to
> APR_ENOTIMPL.
Limiting the test to a virgin Windows Vista (SP0) install should do the trick.
Server 2003 was a superset of Vista and the SP's caught Vista back up to 2003.
Re: MinGW status
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Apr 12, 2011 at 11:10 AM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 4/11/2011 7:45 PM, Jeff Trawick wrote:
>> On Mon, Apr 11, 2011 at 4:09 PM, Jeff Trawick <tr...@gmail.com> wrote:
>>> trunk:
>>>
>>> looks pretty good here other than the IPv6 detection; I think the only
>>> test failures are also broken with a Visual Foo build
>>>
>>> I build like this:
>>>
>>> # enable IPv6
>> export CPPFLAGS=-DIPV6_V6ONLY=27
>> ^
>> This is also required with MinGW, as with older MS SDKs.
>> httpd needs that to work.
>
> Isn't this needed on the win32 build as well? I can confirm that
> Microsoft SDK 2003 Feb and v5.0 (XP/2003), and even the VC8 embedded
> sdk (v6.0/Vista?) flavors did not define this value, while v6.0A
> (2008 server flavor) for VC9 and v7.0 did.
>
> Wondering if it shouldn't just be defined in network_io/win32/sockopt.c
> if its missing?
I think it should be; I was hoping to see about finding what WSAfoo
gets returned on a Windows box that doesn't support the option and, if
seen at runtime once the symbol is always available, map that to
APR_ENOTIMPL.
(Yes, I am aware that there are seemingly as many internal patches to
add that def to deal with older MS SDKs as there are distributions of
Apache-based servers ;) )
Re: MinGW status
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Apr 11, 2011 at 4:09 PM, Jeff Trawick <tr...@gmail.com> wrote:
> trunk:
>
> looks pretty good here other than the IPv6 detection; I think the only
> test failures are also broken with a Visual Foo build
>
> I build like this:
>
> # enable IPv6
export CPPFLAGS=-DIPV6_V6ONLY=27
^
This is also required with MinGW, as with older MS SDKs.
httpd needs that to work.
Re: MinGW status
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/11/2011 3:09 PM, Jeff Trawick wrote:
>
> 1. MSVCRT*?
> I don't know.
As a footnote, it is always called msvcrt.lib by Microsoft, whether
it is defining bindings to msvcrt.dll, or msvcr100.dll. mingw/msys
might differ in their conventions, but I doubt it.