You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jorge Schrauwen <jo...@gmail.com> on 2008/11/03 00:18:58 UTC
httpd win64 binaries
Hi All,
I was running a bit late about compiling the 64-bit windows binaries I
have on my site this month and mentioned on #apache-helpdesk how much
a pain it was.
The subject of not having an official binary package was brought up.
We couldn't think of a reason why not except no body wants or has the
time to do it.
Today I was checking some stats on my server and i though i'd share them:
Filename - downloads - last download
httpd/httpd-2.2.4_x64.exe 4859 2008/02/02 10:37:53
httpd/httpd-2.2.9-win64.zip 2666 2008/10/26 12:10:08
httpd/httpd-2.2.8-win64.zip 2181 2008/06/18 12:21:25
httpd/httpd-2.2.10-win64.zip 186 2008/11/02 22:59:47
httpd/httpd-2.2.9-win64_debug_symbols.rar 296 2008/10/25 21:20:37
httpd/httpd-2.2.8-win64_debug_symbols.zip 226 2008/06/18 12:21:32
httpd/httpd-2.2.10-win64_debug_symbols.zip 21 2008/11/02 08:59:34
httpd/mod_security2.1.1_x64.zip 1444 2008/11/02 08:59:57
httpd/mod_auth_xml_x64.zip 1408 2008/11/02 09:00:14
httpd/mod_jk1.2.22_x64.zip 1356 2008/11/02 09:00:04
httpd/mod_macro1.1.8_x64.zip 948 2008/02/02 07:44:45
httpd/mod_log_rotate_x64.zip 763 2008/11/02 09:00:21
httpd/mod_macro1.1.10_x64.zip 400 2008/11/02 08:59:49
I'm not sure what the 32-bit binaries have as download count but I
think around 2000-2500 isn't bad for binaries I host on my personal
website*.
So the question is... why are there no official binaries? There
definitely is some interest in this.
Also the fact that people mail and complain why I haven't released the
latest version when I'm late seems to suggest they do want them bad
and they are to lazy or can't compile them, themselves.
* sadly these binaries aren't complete and things like the apr-util
mysql driver are still missing. mod_deflate and mod_ssl are included
though.
Jorge Schrauwen
Re: httpd win64 "project" sources/makefiles [was:...binaries]
Posted by Bing Swen <bs...@pku.edu.cn>.
"Dan Poirier" <po...@pobox.com>　wrote on 2008-11-3 21:13
> William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM:
>>
>> Lets look to supporting [name your favorite IDE] as a bigger picture
>> item not specific to windows, and to transition away from .dsp for
>> the build/ide view support.
>
> Re: windows, aren't there one or more ports of gcc? Would something like
> that be worth considering as a more stable build solution than MS's tools?
There is a runtime library issue. Most GCC ports do not generate object code
that can be linked with the necessary WinAPI runtime lib's. e.g, httpd needs
to link to lots of MS C startup libraris to use the file system, socket API,
IOCP, etc.
Bing
Re: httpd win64 "project" sources/makefiles [was:...binaries]
Posted by Dan Poirier <po...@pobox.com>.
William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM:
> But studio (or eclipse or codewarrior or [name your IDE]) users would
> appreciate a perspective into the sources. The IDE-accessible nature
> of the original Win32 port is what made it so easy for me to jump in,
> understand and substantially refactor the win32 support. Without the
> IDE view, would I have done that? Maybe - but at that time in my
> development patterns - more likely not.
>
> Lets look to supporting [name your favorite IDE] as a bigger picture
> item not specific to windows, and to transition away from .dsp for
> the build/ide view support.
I'm still getting my head around how all the parts of Apache work
together, and would love to be able to dive into it using Eclipse and
explore. The advantage of Eclipse would be that it's more
cross-platform than most of the alternatives that I'm aware of.
Re: windows, aren't there one or more ports of gcc? Would something
like that be worth considering as a more stable build solution than MS's
tools?
Dan
Re: httpd win64 "project" sources/makefiles [was:...binaries]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
>>
> I compiled them on vs2008 IIRC (not sure only boot into the vm when
> need to compile)
> Sadly the exact same version is needed or else it refuses to load.
> That is what wrowe mentioned above with all the minor version bumps
> here and there.
Precisely. Also note; VC2008 studio file cannot load in studio 2005.
This might also be true of SP bumps.
Today, it's VC6 dsw/dsp's only because that was the last version able
to export a set of non-studio Makefiles. If we eliminate the need to
export win32's makefiles, we eliminate dsp's altogether.
So as far as .sln's are concerned, if we can emit, from our build
schema, either .vcproj elements or makefiles or both, then we can
forever drop VC6 files. VC6 certainly would still compile, but using
the command line. I can't seriously believe that we should support
the IDE itself forever.
But studio (or eclipse or codewarrior or [name your IDE]) users would
appreciate a perspective into the sources. The IDE-accessible nature
of the original Win32 port is what made it so easy for me to jump in,
understand and substantially refactor the win32 support. Without the
IDE view, would I have done that? Maybe - but at that time in my
development patterns - more likely not.
Lets look to supporting [name your favorite IDE] as a bigger picture
item not specific to windows, and to transition away from .dsp for
the build/ide view support.
Bill
Re: httpd win64 binaries
Posted by Jorge Schrauwen <jo...@gmail.com>.
On Mon, Nov 3, 2008 at 10:23 AM, Bing Swen <bs...@pku.edu.cn> wrote:
> Jorge Schrauwen <jo...@gmail.com> wrote on 2008-11-3 16:26
>
>> On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote:
>>
>>> Jorge Schrauwen wrote:
>>>>
>>>> The subject of not having an official binary package was brought up.
>>>> We couldn't think of a reason why not except no body wants or has the
>>>> time to do it.
>>>
>>> That's not it.
>>>
>>> The problem is MS's creation. We can either ship an 'official'
>>> msvcrt.dll
>>> based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008
>>> or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an
>>> approach to a C runtime.
>>>
>>
>> Now that you mention it I do seem to vaguely remember something about
>> this.
>> So unless the MS gets there act together (which I doubt will happen in
>> anytime soon) we won't see any 64-bit binaries?
>>
>
> Though we are eager to see an 'official' 64-bit Windows httpd release, but
> if not binaries, why shouldn't there be an x64 configured Apache.sln? It
> will be already great to let people have the chance to do their own x64
> compilation.
>
Currently there is only a .dsw and no sln's, they get generated on import.
For some project on import there is a x64 platform available but not all.
I'm not sure how doable that would be? If it was easy I'm sure someone
(wrowe) would probably have done this already. Easiest way to do it
with the current dsw/sln is to remove the project that have and x64
targets, then create a new x64 target for the entire solution.
> It was made clear that 32-bit will soon be over at the Windows server end
> (http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx).
> I guess most of us still think that Windows Server remains as an important
> platform for Apache. So it's really time to make this "little" step further.
>
>
>>
>> So selecting a version that is most popular say 2005(sp1) and only
>> using that one is out of the question?
>>
>
> Jorge's Win64 binaries already seem to work perfectly on mainstream Windows
> versions. Shouldn't it be able to improve to be "offical"?
> (I just found it can not load some modules built with VS005/Win008, though).
>
I compiled them on vs2008 IIRC (not sure only boot into the vm when
need to compile)
Sadly the exact same version is needed or else it refuses to load.
That is what wrowe mentioned above with all the minor version bumps
here and there.
>
> Bing
>
Jorge
Re: httpd win64 binaries
Posted by Bing Swen <bs...@pku.edu.cn>.
Jorge Schrauwen <jo...@gmail.com> wrote on 2008-11-3 16:26
> On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote:
>
>> Jorge Schrauwen wrote:
>>>
>>> The subject of not having an official binary package was brought up.
>>> We couldn't think of a reason why not except no body wants or has the
>>> time to do it.
>>
>> That's not it.
>>
>> The problem is MS's creation. We can either ship an 'official'
>> msvcrt.dll
>> based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008
>> or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an
>> approach to a C runtime.
>>
>
> Now that you mention it I do seem to vaguely remember something about
> this.
> So unless the MS gets there act together (which I doubt will happen in
> anytime soon) we won't see any 64-bit binaries?
>
Though we are eager to see an 'official' 64-bit Windows httpd release, but
if not binaries, why shouldn't there be an x64 configured Apache.sln? It
will be already great to let people have the chance to do their own x64
compilation.
It was made clear that 32-bit will soon be over at the Windows server end
(http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx).
I guess most of us still think that Windows Server remains as an important
platform for Apache. So it's really time to make this "little" step further.
>
> So selecting a version that is most popular say 2005(sp1) and only
> using that one is out of the question?
>
Jorge's Win64 binaries already seem to work perfectly on mainstream Windows
versions. Shouldn't it be able to improve to be "offical"?
(I just found it can not load some modules built with VS005/Win008, though).
Bing
Re: httpd win64 binaries
Posted by Jorge Schrauwen <jo...@gmail.com>.
On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Jorge Schrauwen wrote:
>>
>> The subject of not having an official binary package was brought up.
>> We couldn't think of a reason why not except no body wants or has the
>> time to do it.
>
> That's not it.
>
> The problem is MS's creation. We can either ship an 'official' msvcrt.dll
> based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008
> or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an
> approach to a C runtime.
>
Now that you mention it I do seem to vaguely remember something about this.
So unless the MS gets there act together (which I doubt will happen in
anytime soon) we won't see any 64-bit binaries?
> I'm likely to ship that DDK built flavor if only to help ensure compatibility,
> and let the Studio team know that they don't know what they are doing. They
> deliver a fun product for building something. I know, I used it almost for
> 2 decades.
>
So selecting a version that is most popular say 2005(sp1) and only
using that one is out of the question?
> They are entirely clueless at delivering a product to be used across multiple
> developers from multiple organizations to accomplish multiple purposes. They
> just can't grok that much multiplicity, and observe the central MS tenant of
> forcing to upgrade early and upgrade often. This isn't compatible with open
> source binaries. Just look at how frequently gcc is willing to bump the ver
> major.... like next to never.
>
>
But I have to agree, MS's vs 2005+ series is a mess with all the
.manifest and .local and bah!
~Jorge
Re: httpd win64 binaries
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
>
> The subject of not having an official binary package was brought up.
> We couldn't think of a reason why not except no body wants or has the
> time to do it.
That's not it.
The problem is MS's creation. We can either ship an 'official' msvcrt.dll
based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008
or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an
approach to a C runtime.
I'm likely to ship that DDK built flavor if only to help ensure compatibility,
and let the Studio team know that they don't know what they are doing. They
deliver a fun product for building something. I know, I used it almost for
2 decades.
They are entirely clueless at delivering a product to be used across multiple
developers from multiple organizations to accomplish multiple purposes. They
just can't grok that much multiplicity, and observe the central MS tenant of
forcing to upgrade early and upgrade often. This isn't compatible with open
source binaries. Just look at how frequently gcc is willing to bump the ver
major.... like next to never.