You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2011/04/14 16:45:33 UTC
Status of MinGW (httpd)
I know others have played on MinGW before, but I don't know how long
ago or what was attempted. Here are my observations:
Trunk:
I've been building/running this with shared library builds of apr trunk.
* Only statically linked modules work AFAIK.
* If you build any of the modules that have their own
foo_DECLARE_EXPORT logic you need to add foo_DECLARE_EXPORT to
CPPFLAGS (kludge).
* I haven't tried with many different modules, especially not with
those which require extra third-party libraries (OpenSSL, Lua, etc.).
* There's a trunk-specific problem linking to PCRE because the PCRE
libs are specified within LDFLAGS; I don't have a fix for this yet,
and use a hack to relink it with "-L/path/to/pcre -lpcre" moved to a
later point in the command.
2.2.18-dev:
I've been building/running this with static library builds of apr
1.4.x/apr-util 1.3.x.
Differences from trunk:
* pcre linking problem does not exist (no issue)
* needs a couple of patches listed in STATUS to build practically
(each needs one more vote)
* needs another patch I'll post later to clean up boatloads of gcc
warnings in Windows code which drive some people crazy
Re: Status of MinGW (httpd)
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Apr 14, 2011 at 2:53 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 4/14/2011 1:47 PM, William A. Rowe Jr. wrote:
>>
>>> * If you build any of the modules that have their own
>>> foo_DECLARE_EXPORT logic you need to add foo_DECLARE_EXPORT to
>>> CPPFLAGS (kludge).
>>
>> That would be kludged in the config.m4 magic, we simply need to add
>> this -D'efine to the appropriate
>
> ...target-specific cflags. Perhaps something like;
>
> mod_proxy.lo: mod_proxy.c
> $(LT_COMPILE) $(mod_proxy_CFLAGS)
> ...
>
> etc, similar to how we have module_LDFLAGS today?
yep, something like that
core_CPPFLAGS, proxy_CPPFLAGS, and so on
Re: Status of MinGW (httpd)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/14/2011 1:47 PM, William A. Rowe Jr. wrote:
>
>> * If you build any of the modules that have their own
>> foo_DECLARE_EXPORT logic you need to add foo_DECLARE_EXPORT to
>> CPPFLAGS (kludge).
>
> That would be kludged in the config.m4 magic, we simply need to add
> this -D'efine to the appropriate
...target-specific cflags. Perhaps something like;
mod_proxy.lo: mod_proxy.c
$(LT_COMPILE) $(mod_proxy_CFLAGS)
...
etc, similar to how we have module_LDFLAGS today?
Re: Status of MinGW (httpd)
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Apr 14, 2011 at 2:47 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 4/14/2011 9:45 AM, Jeff Trawick wrote:
>> I know others have played on MinGW before, but I don't know how long
>> ago or what was attempted. Here are my observations:
>>
>> Trunk:
>>
>> I've been building/running this with shared library builds of apr trunk.
>>
>> * Only statically linked modules work AFAIK.
>
> Something interesting is going on with apr_dso_ here... does depends.exe
> shed any insight? (Comparing win32 to mingw build, that is).
>
>> * If you build any of the modules that have their own
>> foo_DECLARE_EXPORT logic you need to add foo_DECLARE_EXPORT to
>> CPPFLAGS (kludge).
>
> That would be kludged in the config.m4 magic, we simply need to add
> this -D'efine to the appropriate
I haven't looked at exactly what it takes to get the right
foo_DECLARE_EXPORT in all the right places (and only there), and not
leaking to apxs builds.
>
>> * I haven't tried with many different modules, especially not with
>> those which require extra third-party libraries (OpenSSL, Lua, etc.). :)
>> * There's a trunk-specific problem linking to PCRE because the PCRE
>> libs are specified within LDFLAGS; I don't have a fix for this yet,
>> and use a hack to relink it with "-L/path/to/pcre -lpcre" moved to a
>> later point in the command.
>
> Interesting (an alternate expression for 'frustrating' :)
This simple patch works for me... I just need to test on a couple of
other platforms (rjung mentioned at the time that the prior change
fixed an issue on OS X).
Index: configure.in
===================================================================
--- configure.in (revision 1092430)
+++ configure.in (working copy)
@@ -204,10 +204,8 @@
AC_MSG_ERROR([pcre-config for libpcre not found. PCRE is required
and available from http://pcre.org/])
fi
APACHE_SUBST(PCRE_LIBS)
+APR_ADDTO(AP_LIBS, [\$(PCRE_LIBS)])
-dnl Add PCRE_LIBS to HTTPD_LDFLAGS
-APR_ADDTO(HTTPD_LDFLAGS, [\$(PCRE_LIBS)])
-
echo $ac_n "${nl}Configuring Apache httpd ...${nl}"
dnl If the source dir is not equal to the build dir,
> All of your experiments have been on Windows mingw/msys toolchain, right?
> I want to take the revised apr/-util/httpd code once through the fedora 14
> mingw toolchain, just to see if anything interesting pops up. I don't
> really care if the end result works under Wine, though :)
That would be cool; I'm sure the build cycle is a lot faster. (But
you wouldn't believe how many meetings have been more productive
lately since I can tweak something in httpd, kick off a complete
build, and see that something gets better amidst all the jabbering.)
Re: Status of MinGW (httpd)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/14/2011 9:45 AM, Jeff Trawick wrote:
> I know others have played on MinGW before, but I don't know how long
> ago or what was attempted. Here are my observations:
>
> Trunk:
>
> I've been building/running this with shared library builds of apr trunk.
>
> * Only statically linked modules work AFAIK.
Something interesting is going on with apr_dso_ here... does depends.exe
shed any insight? (Comparing win32 to mingw build, that is).
> * If you build any of the modules that have their own
> foo_DECLARE_EXPORT logic you need to add foo_DECLARE_EXPORT to
> CPPFLAGS (kludge).
That would be kludged in the config.m4 magic, we simply need to add
this -D'efine to the appropriate
> * I haven't tried with many different modules, especially not with
> those which require extra third-party libraries (OpenSSL, Lua, etc.). :)
> * There's a trunk-specific problem linking to PCRE because the PCRE
> libs are specified within LDFLAGS; I don't have a fix for this yet,
> and use a hack to relink it with "-L/path/to/pcre -lpcre" moved to a
> later point in the command.
Interesting (an alternate expression for 'frustrating' :)
All of your experiments have been on Windows mingw/msys toolchain, right?
I want to take the revised apr/-util/httpd code once through the fedora 14
mingw toolchain, just to see if anything interesting pops up. I don't
really care if the end result works under Wine, though :)