You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Guenter Knauf <fu...@apache.org> on 2008/01/21 22:52:58 UTC
problem compiling APR 0.9.x misc/win32/rand.c
Hi,
when I try to compile httpd 2.0.63 with MSCV6 then it breaks in apr/misc/win32/rand.c
because in wincrypt.h the needed stuff is surrounded with:
#if(_WIN32_WINNT >= 0x0400)
...
#endif
in apr/misc/win32/rand.c we include the system headers before our apr-own;
in apr/include/apr.h[w] I see:
#ifndef _WIN32_WINNT
/* Restrict the server to a subset of Windows NT 4.0 header files by default
*/
#define _WIN32_WINNT 0x0400
#endif
now when I move wincrypt.h after the apr header includes it works:
--- apr/misc/win32/rand.c.orig Fri Jun 01 00:53:12 2007
+++ apr/misc/win32/rand.c Mon Jan 21 22:21:18 2008
@@ -14,13 +14,12 @@
* limitations under the License.
*/
-#include <windows.h>
-#include <wincrypt.h>
#include "apr.h"
#include "apr_private.h"
#include "apr_general.h"
#include "apr_portable.h"
#include "apr_arch_misc.h"
+#include <wincrypt.h>
APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
also seems that the windows.h include is not needed here.
Bill, can you please check if the above patch works with your setup?
thanks, Guen.
Re: problem compiling APR 0.9.x misc/win32/rand.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> It's well documented "don't do that".
Actually, httpd is 'so-so documented', apr is hardly.
Something to address shortly, since the new makefile system is
pretty much set to let users do various tricks with nt specific
builds.
Re: problem compiling APR 0.9.x misc/win32/rand.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Hi,
>> That's probably not a good idea for several reasons, the first of
>> which is that we have been around this file a half dozen times. APR
>> deliberately excludes a vast amount of junk from being compiled, very
>> likely including some crypt stuff. By compiling windows.h first, we
>> end up with a very slow compile for one module, but overall we win
>> by orders of magnitude on the rest.
>
> omitting the windows include was only a suggestion since apr.h includeds it
> already, otherwise I dont care about. The important thing was moving the
> wincrypt header include after apr.h to get the _WIN32_WINNT define from it.
You are missing my point, flip them, use more modern headers and it's
broken again. We gain all of apr's preferences to rid ourselves of all
the excessive win32 header-fu (including some that is related to crypt),
or we gain the define. Flipping these is definitely not that answer,
please don't.
> yes, it was on a box where I had only a 'VC6 out-of-the-box'... (not mine);
> but this break was really the only one - after changing the include order
> compilation succeeded; got httpd 2.0.63 compiled, and its running fine so
> far - though not much tested except running some PHP5 apps from it...
For apr, a remote possibility. For apr 1.x (all we really care about)
and apr-util, it's certainly not true. The ldap headers alone provided
with that VC6 are garbage to us, there we flaws in more recent wsock
libs, etc. It's well documented "don't do that".
So don't ;-)
Re: problem compiling APR 0.9.x misc/win32/rand.c
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
> That's probably not a good idea for several reasons, the first of
> which is that we have been around this file a half dozen times. APR
> deliberately excludes a vast amount of junk from being compiled, very
> likely including some crypt stuff. By compiling windows.h first, we
> end up with a very slow compile for one module, but overall we win
> by orders of magnitude on the rest.
omitting the windows include was only a suggestion since apr.h includeds it
already, otherwise I dont care about. The important thing was moving the
wincrypt header include after apr.h to get the _WIN32_WINNT define from it.
> Each successive change has broken this file in a different way in
> different environments, I'm adverse to patching if it's failing with
> VC6 out-of-the-box and missing the modern (2002-2003 timeframe) sdk.
yes, it was on a box where I had only a 'VC6 out-of-the-box'... (not mine);
but this break was really the only one - after changing the include order
compilation succeeded; got httpd 2.0.63 compiled, and its running fine so
far - though not much tested except running some PHP5 apps from it...
Guen.
Re: problem compiling APR 0.9.x misc/win32/rand.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Guenter Knauf wrote:
> Hi,
> when I try to compile httpd 2.0.63 with MSCV6 then it breaks in apr/misc/win32/rand.c
> because in wincrypt.h the needed stuff is surrounded with:
> #if(_WIN32_WINNT >= 0x0400)
> ...
> #endif
>
> in apr/misc/win32/rand.c we include the system headers before our apr-own;
> in apr/include/apr.h[w] I see:
>
> #ifndef _WIN32_WINNT
>
> /* Restrict the server to a subset of Windows NT 4.0 header files by default
> */
> #define _WIN32_WINNT 0x0400
> #endif
>
> now when I move wincrypt.h after the apr header includes it works:
>
> --- apr/misc/win32/rand.c.orig Fri Jun 01 00:53:12 2007
> +++ apr/misc/win32/rand.c Mon Jan 21 22:21:18 2008
> @@ -14,13 +14,12 @@
> * limitations under the License.
> */
>
> -#include <windows.h>
> -#include <wincrypt.h>
> #include "apr.h"
> #include "apr_private.h"
> #include "apr_general.h"
> #include "apr_portable.h"
> #include "apr_arch_misc.h"
> +#include <wincrypt.h>
>
>
> APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
>
> also seems that the windows.h include is not needed here.
>
> Bill, can you please check if the above patch works with your setup?
Which SDK? Minimally from late 2002? APR absolutely does not build
with more ancient flavors. Including windows should default the SDK
to something of 0x400 or higher.
That's probably not a good idea for several reasons, the first of
which is that we have been around this file a half dozen times. APR
deliberately excludes a vast amount of junk from being compiled, very
likely including some crypt stuff. By compiling windows.h first, we
end up with a very slow compile for one module, but overall we win
by orders of magnitude on the rest.
Each successive change has broken this file in a different way in
different environments, I'm adverse to patching if it's failing with
VC6 out-of-the-box and missing the modern (2002-2003 timeframe) sdk.
Bill