You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by John Mark Vandenberg <ja...@gmail.com> on 2006/04/15 03:41:18 UTC
[patch 00/17] successful msys/mingw build
This series of patches allows apr to be built using MSYS and MinGW, but only with CFLAGS=" -O0 ". Compared with tests using MS VC++ builds, only the dso functions appear to have problems specific to msys builds.
Failed Tests Total Fail Failed %
===================================================
testdso 5 4 80.00%
testpipe 9 2 22.22%
testsock 7 1 14.29%
Curiously, the results differ when testall is run from msys rather than CMD.
Failed Tests Total Fail Failed %
===================================================
testdso 5 4 80.00%
testnames 13 1 7.69%
testpipe 9 2 22.22%
testsock 7 1 14.29%
In a lovely coincidence, Davi Arnaut posted patches to bug 33490 (APR does not compile with Borland C++) whilst I prepared the series for submission.
Libtool
-------
Something to be wary of .. msys installers may have installed libtool 1.4e
$ libtool --version
ltmain.sh (GNU libtool) 1.4e (1.1162 2002/11/22 22:36:25)
Re-running autoconf with libtool 1.4e will complain with:
configure.in:186: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
To resolve this, download libtool-1.5 from the mingw project files, and unpack it so the m4 files are in the aclocal directory; usually /share/aclocal/ or /share/aclocal-1.7/
--
John
Re: [patch 00/17] successful msys/mingw build
Posted by Davi Arnaut <da...@haxent.com.br>.
On Sat, 15 Apr 2006 11:41:18 +1000
John Mark Vandenberg <ja...@gmail.com> wrote:
> This series of patches allows apr to be built using MSYS and MinGW,
> but only with CFLAGS=" -O0 ". Compared with tests using MS VC++ builds,
> only the dso functions appear to have problems specific to msys builds.
> ...
Wow, nice work! Thanks for sharing.
Davi Arnaut
Re: [patch 17/17] Uuid
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Include librpcrt4.a.
>
> Include <windows.h> & <wincrypt.h> first. Without this, the symbols
> used from librpcrt4.a dont include the @<arg count>, causing the link
> to fail.
Committed in r421805. Thanks! -- justin
[patch 17/17] Uuid
Posted by John Mark Vandenberg <ja...@gmail.com>.
Include librpcrt4.a.
Include <windows.h> & <wincrypt.h> first. Without this, the symbols
used from librpcrt4.a dont include the @<arg count>, causing the link
to fail.
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -1916,6 +1916,8 @@ echo "${nl}Checking for OS UUID Support.
AC_CHECK_HEADERS(uuid.h uuid/uuid.h sys/uuid.h, break)
+AX_CHECK_DLL_FUNC(rpcrt4,UuidCreate@4)
+
apr_revert_save_LIBS=$LIBS
# Prefer the flavor(s) that live in libc;
Index: misc/win32/rand.c
===================================================================
--- misc/win32/rand.c.orig
+++ misc/win32/rand.c
@@ -14,12 +14,13 @@
* 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,
--
Re: [patch 08/17] off64_t vs __int64
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> mingw/cl headers dont provide off64_t. use __int64 instead.
mingw 5.0.3 provides off64_t, so this patch isn't needed now, AFAICT.
Thanks! -- justin
[patch 08/17] off64_t vs __int64
Posted by John Mark Vandenberg <ja...@gmail.com>.
mingw/cl headers dont provide off64_t. use __int64 instead.
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -1321,6 +1321,8 @@ else
fi
APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], off_t, 8)
+APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], off64_t, 8)
+APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], __int64, 8)
if test "${ac_cv_sizeof_off_t}${apr_cv_use_lfs64}" = "4yes"; then
# Enable LFS
@@ -1334,7 +1336,13 @@ AC_MSG_CHECKING([which type to use for a
if test "${ac_cv_sizeof_off_t}${apr_cv_use_lfs64}" = "4yes"; then
# LFS is go!
off_t_fmt='#define APR_OFF_T_FMT APR_INT64_T_FMT'
- off_t_value='off64_t'
+ if test "${ac_cv_sizeof_off64_t}" = "8"; then
+ off_t_value='off64_t'
+ elif test "${ac_cv_sizeof___int64}" = "8"; then
+ off_t_value='__int64'
+ else
+ off_t_value='off64_t'
+ fi
off_t_strfn='apr_strtoi64'
elif test "${ac_cv_sizeof_off_t}x${ac_cv_sizeof_long}" = "4x4"; then
# Special case: off_t may change size with _FILE_OFFSET_BITS
--
Re: [patch 05/17] win32api support
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> The include paths are automaticly set up to be:
> -I./include
> -I/path/to/apr/include/arch/win32
> -I./include/arch/unix
> -I/path/to/apr/include
>
> This patch sets up the MINGW header arrangement as follows:
>
> include/apr.h.in -> apr.h includes
> windows.h
> winsock2.h
>
> include/arch/win32/apr_private.h
> as per MS VC++ builds
>
> include/arch/unix/apr_private.h.in include/arch/unix/apr_private.h
> not used. In order to achieve this, AH_TOP & AH_BOTTOM add a
> condition around this generated file to prevent it from being
> included.
I think the better thing to do is just toss arch/unix/apr_private.h
instead. This way there is no confusion by the preprocessor. I'm
going to try to go down that route and see how far I get. I realize
we may need to re-evaluate that decision later, but I'm hopeful... =)
I've committed the other bits from this set - suitably tweaked - in r421063.
Thanks! -- justin
[patch 05/17] win32api support
Posted by John Mark Vandenberg <ja...@gmail.com>.
The include paths are automaticly set up to be:
-I./include
-I/path/to/apr/include/arch/win32
-I./include/arch/unix
-I/path/to/apr/include
This patch sets up the MINGW header arrangement as follows:
include/apr.h.in -> apr.h includes
windows.h
winsock2.h
include/arch/win32/apr_private.h
as per MS VC++ builds
include/arch/unix/apr_private.h.in include/arch/unix/apr_private.h
not used. In order to achieve this, AH_TOP & AH_BOTTOM add a
condition around this generated file to prevent it from being
included.
This set up requires careful ordering of includes. Includes from
a unix header will result in the unix copy being included even if
a win32 copy exists.
for example, apr_private.h will exist in include/arch/win32/ and
include/arch/unix/, requiring that apr_private.h is included very
early to prevent a unix header including it.
locks/unix/global_mutex.c illistrates why this probably needs to be
improved before check. Without the changes in this patch:
global_mutex.c
...
include/arch/unix/apr_arch_global_mutex.h
...
include/arch/unix/apr_arch_thread_mutex.h <- wrong
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -21,6 +21,15 @@ sinclude(build/apr_hints.m4)
sinclude(build/libtool.m4)
sinclude(build/ltsugar.m4)
+dnl For win32, we need to be sure that arch/win32/apr_private.h is
+dnl included first, and the unix one cant be included
+AH_TOP([
+
+#ifndef APR_PRIVATE_H
+#define APR_PRIVATE_H
+
+])
+
dnl Hard-coded inclusion at the tail end of apr_private.h:
AH_BOTTOM([
/* switch this on if we have a BeOS version below BONE */
@@ -34,6 +43,8 @@ AH_BOTTOM([
* Include common private declarations.
*/
#include "../apr_private_common.h"
+
+#endif /* APR_PRIVATE_H */
])
dnl Save user-defined environment settings for later restoration
@@ -1058,6 +1069,8 @@ APR_FLAG_HEADERS(
unix.h \
arpa/inet.h \
kernel/OS.h \
+ windows.h \
+ winsock2.h \
net/errno.h \
netinet/in.h \
netinet/sctp.h \
@@ -1134,6 +1147,8 @@ AC_SUBST(signalh)
AC_SUBST(sys_waith)
AC_SUBST(pthreadh)
AC_SUBST(semaphoreh)
+AC_SUBST(windowsh)
+AC_SUBST(winsock2h)
# Checking for h_errno in <netdb.h>
if test "$netdbh" = "1"; then
Index: include/apr.h.in
===================================================================
--- include/apr.h.in.orig
+++ include/apr.h.in
@@ -102,6 +102,8 @@
#define APR_HAVE_SYS_WAIT_H @sys_waith@
#define APR_HAVE_TIME_H @timeh@
#define APR_HAVE_UNISTD_H @unistdh@
+#define APR_HAVE_WINDOWS_H @windowsh@
+#define APR_HAVE_WINSOCK2_H @winsock2h@
/** @} */
@@ -109,6 +111,14 @@
* or the extern "C" namespace
*/
+#if defined(APR_HAVE_WINDOWS_H)
+#include <windows.h>
+#endif
+
+#if defined(APR_HAVE_WINSOCK2_H)
+#include <winsock2.h>
+#endif
+
#if APR_HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
Index: atomic/win32/apr_atomic.c
===================================================================
--- atomic/win32/apr_atomic.c.orig
+++ atomic/win32/apr_atomic.c
@@ -15,6 +15,7 @@
*/
#include "apr.h"
+#include "apr_private.h"
#include "apr_atomic.h"
#include "apr_thread_mutex.h"
Index: misc/win32/apr_app.c
===================================================================
--- misc/win32/apr_app.c.orig
+++ misc/win32/apr_app.c
@@ -34,12 +34,12 @@
*/
#include "apr_general.h"
+#include "apr_private.h"
#include "ShellAPI.h"
#include "crtdbg.h"
#include "wchar.h"
#include "apr_arch_file_io.h"
#include "assert.h"
-#include "apr_private.h"
#include "apr_arch_misc.h"
/* This symbol is _private_, although it must be exported.
Index: locks/unix/global_mutex.c
===================================================================
--- locks/unix/global_mutex.c.orig
+++ locks/unix/global_mutex.c
@@ -16,6 +16,10 @@
#include "apr.h"
#include "apr_strings.h"
+// horrible hack to force win32 header inclusion
+#include "apr_private.h"
+#include "apr_arch_thread_mutex.h"
+
#include "apr_arch_global_mutex.h"
#include "apr_proc_mutex.h"
#include "apr_thread_mutex.h"
--
Re: [patch 02/17] Windows library dependencies
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Windows symbols may a suffix of @<arg count>.
>
> A new macro AX_CHECK_DLL_FUNC looks for a @ sign in the function name; when
> present it will verify a symbol exists with the correct argument count.
> Otherwise, AX_CHECK_DLL_FUNC falls back to emulating AC_CHECK_LIB.
>
> Enables native threads, locking, DSO loading and shared memory.
Committed with some minor tweaks in r421013.
Thanks! -- justin
[patch 02/17] Windows library dependencies
Posted by John Mark Vandenberg <ja...@gmail.com>.
Windows symbols may a suffix of @<arg count>.
A new macro AX_CHECK_DLL_FUNC looks for a @ sign in the function name; when
present it will verify a symbol exists with the correct argument count.
Otherwise, AX_CHECK_DLL_FUNC falls back to emulating AC_CHECK_LIB.
Enables native threads, locking, DSO loading and shared memory.
Index: build/apr_win32.m4
===================================================================
--- /dev/null
+++ build/apr_win32.m4
@@ -0,0 +1,33 @@
+
+dnl if $2 contains '@dd', links against mingw symbols
+dnl otherwise calls AC_CHECK_LIB
+AC_DEFUN([AX_CHECK_DLL_FUNC],[
+m4_define($1_function_name,m4_substr($2,0,m4_index($2,[@])))
+m4_define($1_function_arglength,m4_substr($2,m4_incr(m4_index($2,[@]))))
+m4_define($1_[function_name]_arglength,m4_substr($2,m4_incr(m4_index($2,[@]))))
+dnl m4_define(ax_check_dll_id,$1_m4_defn($1_function_name))
+
+AC_CACHE_CHECK([for $2 in $1],[ac_cv_lib_$1_]$1_function_name,[
+
+ac_func_search_save_LIBS=$LIBS
+LIBS="$LIBS -l$1"
+
+AC_TRY_LINK([
+#pragma pack(1)
+struct x {
+]m4_for([byte_id], 1, m4_defn([$1_function_name_arglength]), 1,[[ char c]]byte_id;
+)[};
+__stdcall ]$1_function_name[(]struct x[);],[
+struct x s = {0};
+]$1_function_name[(s)],
+[ac_cv_lib_$1_]$1_function_name[=yes],[ac_cv_lib_$1_]$1_function_name[=no])
+LIBS=$ac_func_search_save_LIBS
+])dnl AC_CACHE_CHECK
+
+AS_IF([test $ac_cv_lib_$1_]$1_function_name[ = yes],
+ [m4_default([$3], [AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_LIB$1),,Enable if this library is available)
+ LIBS="-l$1 $LIBS"
+])],
+ [$4])dnl
+])
+
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -14,6 +14,7 @@ dnl
dnl Include our own M4 macros along with those for libtool
dnl
sinclude(build/apr_common.m4)
+sinclude(build/apr_win32.m4)
sinclude(build/apr_network.m4)
sinclude(build/apr_threads.m4)
sinclude(build/apr_hints.m4)
@@ -319,6 +320,7 @@ AC_ARG_ENABLE(pool-debug,
fi
])
+dnl Electric Fence malloc checker.
if test "$host" = "i586-pc-beos"; then
AC_ARG_ENABLE(malloc-debug,[ --enable-malloc-debug Switch on malloc_debug for BeOS],
APR_REMOVEFROM(CFLAGS, -O2)
@@ -347,6 +349,9 @@ case "$host:$CC" in
APR_SETVAR(CC,mwcc)
APR_SETVAR(AR,ar)
;;
+ *-mingw*:gcc )
+ APR_ADDTO(LDFLAGS,[-Wl,--enable-auto-import,--subsystem,console])
+ ;;
esac
dnl Check the depend program we can use
@@ -404,6 +409,12 @@ case $host in
OSDIR="as400"
eolstr="\\n"
;;
+ *mingw*)
+ OSDIR="win32"
+ enable_threads="system_threads"
+ eolstr="\\n"
+ OBJECTS_PLATFORM='$(OBJECTS_win32)'
+ ;;
*cygwin*)
OSDIR="unix"
APR_ADDTO(CPPFLAGS,-DCYGWIN)
@@ -520,12 +531,25 @@ dnl Note: Autoconf will always append LI
dnl It should check for LIBS being empty and set LIBS equal to the new value
dnl without the extra " " in that case, but they didn't do that. So, we
dnl end up LIBS="-lm -lcrypt -lnsl -ldl" which is an annoyance.
-AC_SEARCH_LIBS(gethostbyname, nsl)
-AC_SEARCH_LIBS(gethostname, nsl)
-AC_SEARCH_LIBS(socket, socket)
-AC_SEARCH_LIBS(crypt, crypt ufc)
-AC_CHECK_LIB(truerand, main)
-AC_SEARCH_LIBS(modf, m)
+case $host in
+ *mingw*)
+ dnl APR_ADDTO(LIBS,[-lmsvcrt --lshell32 -ladvapi32 -lws2_32])
+
+ AC_CHECK_LIB(msvcrt,getpid)
+ AX_CHECK_DLL_FUNC(kernel32,SetErrorMode@4)
+ AX_CHECK_DLL_FUNC(advapi32,GetSecurityInfo@32)
+ AX_CHECK_DLL_FUNC(ws2_32,gethostbyname@4)
+ AX_CHECK_DLL_FUNC(shell32,CommandLineToArgvW@8)
+ ;;
+ *)
+ AC_SEARCH_LIBS(gethostbyname, nsl)
+ AC_SEARCH_LIBS(gethostname, nsl)
+ AC_SEARCH_LIBS(socket, socket)
+ AC_SEARCH_LIBS(crypt, crypt ufc)
+ AC_CHECK_LIB(truerand, main)
+ AC_SEARCH_LIBS(modf, m)
+ ;;
+esac
dnl ----------------------------- Checking for Threads
echo "${nl}Checking for Threads..."
@@ -692,9 +716,16 @@ case $host in
#endif";;
esac
-AC_CHECK_HEADERS([sys/types.h sys/mman.h sys/ipc.h sys/mutex.h sys/shm.h sys/file.h kernel/OS.h os2.h])
+AC_CHECK_HEADERS([sys/types.h sys/mman.h sys/ipc.h sys/mutex.h sys/shm.h sys/file.h kernel/OS.h os2.h windows.h])
AC_CHECK_FUNCS([mmap munmap shm_open shm_unlink shmget shmat shmdt shmctl \
create_area])
+case $host in
+ *mingw*)
+ AX_CHECK_DLL_FUNC(kernel32,[CreateFileMappingA@24],
+ [ac_cv_func_CreateFileMapping=$ac_cv_lib_kernel32_CreateFileMappingA])
+ ;;
+esac
+
APR_CHECK_DEFINE(MAP_ANON, sys/mman.h)
APR_CHECK_FILE(/dev/zero)
@@ -754,6 +785,10 @@ APR_IFALLYES(header:kernel/OS.h func:cre
[havebeosshm="1"
APR_DECIDE(USE_SHMEM_BEOS_ANON,
[BeOS areas])])
+APR_IFALLYES(header:windows.h func:CreateFileMapping,
+ [havewin32shm="1"
+ APR_DECIDE(USE_SHMEM_WIN32_ANON,
+ [Windows CreateFileMapping()])])
case $host in
*linux* )
# Linux has problems with MM_SHMT_MMANON even though it reports
@@ -800,6 +835,7 @@ havemmapshm="0"
haveshmget="0"
havebeosarea="0"
haveos2shm="0"
+havewin32shm="0"
APR_BEGIN_DECISION([namebased memory allocation method])
APR_IFALLYES(header:sys/mman.h func:mmap func:munmap,
[havemmaptmp="1"
@@ -820,6 +856,9 @@ APR_IFALLYES(header:kernel/OS.h func:cre
APR_IFALLYES(header:os2.h,
[haveos2shm="1"
APR_DECIDE(USE_SHMEM_OS2, [OS/2 DosAllocSharedMem()])])
+APR_IFALLYES(header:windows.h,
+ [havewin32shm="1"
+ APR_DECIDE(USE_SHMEM_WIN32, [Windows shared memory])])
case $host in
*linux* )
# Linux has problems with MM_SHMT_MMANON even though it reports
@@ -840,6 +879,7 @@ usemmapshm="0"
useshmget="0"
usebeosarea="0"
useos2shm="0"
+usewin32shm="0"
case $ac_decision in
USE_SHMEM_MMAP_TMP )
@@ -857,10 +897,13 @@ case $ac_decision in
USE_SHMEM_OS2 )
useos2shm="1"
;;
+ USE_SHMEM_WIN32 )
+ usewin32shm="1"
+ ;;
esac
# Do we have any shared memory support?
-if test "$usemmaptmp$usemmapshm$usemmapzero$useshmget$usemmapanon$usebeosarea$useos2shm" = "0000000"; then
+if test "$usemmaptmp$usemmapshm$usemmapzero$useshmget$usemmapanon$usebeosarea$useos2shm$usewin32shm" = "00000000"; then
sharedmem="0"
else
sharedmem="1"
@@ -871,11 +914,13 @@ AC_SUBST(usemmapshm)
AC_SUBST(useshmget)
AC_SUBST(usebeosarea)
AC_SUBST(useos2shm)
+AC_SUBST(usewin32shm)
AC_SUBST(havemmaptmp)
AC_SUBST(havemmapshm)
AC_SUBST(haveshmget)
AC_SUBST(havebeosarea)
AC_SUBST(haveos2shm)
+AC_SUBST(havewin32shm)
AC_SUBST(sharedmem)
dnl ----------------------------- Checks for Any required Functions
@@ -1448,7 +1493,7 @@ if test "$dsotype" = "any"; then
# Everything else:
if test "$dsotype" = "any"; then
case $host in
- *os390|*-os2*|*os400|*-aix*) dsotype=other ;;
+ *os390|*-os2*|*os400|*-aix*|*mingw*) dsotype=other ;;
esac
fi
fi
@@ -1644,6 +1689,11 @@ APR_IFALLYES(header:OS.h func:create_sem
if test "x$apr_lock_method" != "x"; then
APR_DECISION_FORCE($apr_lock_method)
fi
+case "$host" in
+ *mingw* )
+ APR_DECISION_FORCE(win32)
+ ;;
+esac
APR_END_DECISION
AC_DEFINE_UNQUOTED($ac_decision)
--
Re: [patch 03/17] build conf
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> The changes to gen-build.py permit any platform to inherit files from the
> platforms specified in the second parameter in MAKE_PLATFORMS.
>
> This patch needs more work before it is committed.
I went a different route - reading the libapr.dsp file instead, but
this general concept is now in r421038.
Thanks. -- justin
[patch 03/17] build conf
Posted by John Mark Vandenberg <ja...@gmail.com>.
The changes to gen-build.py permit any platform to inherit files from the
platforms specified in the second parameter in MAKE_PLATFORMS.
This patch needs more work before it is committed.
Index: build.conf
===================================================================
--- build.conf.orig
+++ build.conf
@@ -24,3 +24,24 @@ headers = include/*.h
# we have a recursive makefile for the test files (for now)
# test/*.c
+
+[win32]
+
+inherit =
+ filepath_util
+ fullrw
+ fileacc
+ copy
+ tempdir
+ mktemp
+ errorcodes
+ getopt
+ inet_pton
+ inet_ntop
+ sockaddr
+ select
+ apr_pools # the empty memory/win32 directory makes this necessary
+ global_mutex
+ version
+ otherchild
+
Index: build/gen-build.py
===================================================================
--- build/gen-build.py.orig
+++ build/gen-build.py
@@ -29,6 +29,7 @@ MAKE_PLATFORMS = [
('beos', 'unix'),
('os2', 'unix'),
('os390', 'unix'),
+ ('win32', 'unix'),
]
# note: MAKE_PLATFORMS is an ordered set. we want to generate unix symbols
# first, so that the later platforms can reference them.
@@ -66,8 +67,29 @@ def main():
group = [ '$(OBJECTS_all)' ]
for subdir in string.split(parser.get('options', 'platform_dirs')):
+ try:
+ inherit = string.split(parser.get(platform, 'inherit'))
+ except ConfigParser.NoSectionError:
+ inherit = None;
+
+ inherited_files = []
+ inherited_objects = []
+ if inherit:
+ path = '%s/%s' % (subdir, parent)
+ if os.path.exists(path):
+ for file in inherit:
+ file = '%s/%s.c' % (path,file)
+ if os.path.isfile(file):
+ inherited_files.append(file)
+ if inherited_files:
+ inherited_objects, _unused = write_objects(f, legal_deps, h_deps, inherited_files)
+ inherited_symname = 'OBJECTS_%s_%s_inherit' % (subdir, platform)
+ f.write('\n%s = %s\n\n' % (inherited_symname, string.join(inherited_objects)))
+ group.append('$(%s)' % inherited_symname)
+
path = '%s/%s' % (subdir, platform)
- if not os.path.exists(path):
+
+ if not inherited_files and not os.path.exists(path):
# this subdir doesn't have a subdir for this platform, so we'll
# use the parent-platform's set of symbols
if parent:
@@ -164,7 +186,8 @@ def resolve_deps(header_deps):
def get_files(patterns):
files = [ ]
for pat in string.split(patterns):
- files.extend(glob.glob(pat))
+ for file in glob.glob(pat):
+ files.extend([file.replace('\\','/')])
return files
--
Re: [patch 07/17] Win32 LFS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> On Sat, Apr 15, 2006 at 11:41:25AM +1000, John Mark Vandenberg wrote:
>
>>Windows 98+ provides a LFS API that is not POSIX compatible.
Another reason, al la "Doctor, it hurts when I bend this way", that it's absurd
to stack apr compatibility layers on the cygwin/mingw posix APIs - this simply
isn't an issue on the Win32 code path.
Re: [patch 07/17] Win32 LFS
Posted by Joe Orton <jo...@redhat.com>.
On Sat, Apr 15, 2006 at 11:41:25AM +1000, John Mark Vandenberg wrote:
> Windows 98+ provides a LFS API that is not POSIX compatible.
Test results which have to be "forced" like this should be set via
apr_hints.m4 - add a *-mingw* case in there, and do them all in one go
like:
APR_SETIFNULL(apr_cv_foo, [yes])
...
joe
> Index: configure.in
> ===================================================================
> --- configure.in.orig
> +++ configure.in
> @@ -450,7 +450,16 @@ AC_SUBST(OBJECTS_PLATFORM)
> AC_ARG_ENABLE(lfs,[ --disable-lfs Disable large file support on 32-bit platforms],
> [apr_lfs_choice=$enableval], [apr_lfs_choice=yes])
>
> +# Windows 98+ provides a LFS API that is not POSIX compatible.
> +# The following test for LFS is not suitable, and changing it isnt warrented.
> if test "$apr_lfs_choice" = "yes"; then
> + case $host in
> + *mingw*) apr_cv_use_lfs64=yes
> + ;;
> + esac
> +fi
> +
> +if test "$apr_lfs_choice" = "yes" -a "x$apr_cv_use_lfs64" != "xyes"; then
> # Check whether the transitional LFS API is sufficient
> AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [apr_cv_use_lfs64], [
> apr_save_CPPFLAGS=$CPPFLAGS
>
> --
Re: [patch 07/17] Win32 LFS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Windows 98+ provides a LFS API that is not POSIX compatible.
Committed a variant of this in r421800. Thanks! -- justin
[patch 07/17] Win32 LFS
Posted by John Mark Vandenberg <ja...@gmail.com>.
Windows 98+ provides a LFS API that is not POSIX compatible.
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -450,7 +450,16 @@ AC_SUBST(OBJECTS_PLATFORM)
AC_ARG_ENABLE(lfs,[ --disable-lfs Disable large file support on 32-bit platforms],
[apr_lfs_choice=$enableval], [apr_lfs_choice=yes])
+# Windows 98+ provides a LFS API that is not POSIX compatible.
+# The following test for LFS is not suitable, and changing it isnt warrented.
if test "$apr_lfs_choice" = "yes"; then
+ case $host in
+ *mingw*) apr_cv_use_lfs64=yes
+ ;;
+ esac
+fi
+
+if test "$apr_lfs_choice" = "yes" -a "x$apr_cv_use_lfs64" != "xyes"; then
# Check whether the transitional LFS API is sufficient
AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [apr_cv_use_lfs64], [
apr_save_CPPFLAGS=$CPPFLAGS
--
Re: [patch 16/17] win32api omission
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/12/06, John Vandenberg <ja...@gmail.com> wrote:
> I was using win32api-2.4, which comes with MinGW-3.1.0-1.exe.
>
> I'll upgrade to the candidate installer MinGW-5.0.3.exe and try building trunk.
Note that I'm not done incorporating all of your patches yet... =)
And, yes, I used the mingw 5.0.3 installer.
Thanks for all of your patches - it makes this job a *lot* easier! -- justin
Re: [patch 16/17] win32api omission
Posted by John Vandenberg <ja...@gmail.com>.
On 7/13/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> > LOGON32_LOGON_NETWORK is not defined in win32api headers.
> >
> > threadproc/win32/proc.c: In function `apr_procattr_user_set':
> > threadproc/win32/proc.c:269: `LOGON32_LOGON_NETWORK' undeclared
> > (first use in this function)
>
> My version of mingw has this symbol defined now, so there's no need to
> apply this patch.
I was using win32api-2.4, which comes with MinGW-3.1.0-1.exe.
I'll upgrade to the candidate installer MinGW-5.0.3.exe and try building trunk.
--
John
Re: [patch 16/17] win32api omission
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> LOGON32_LOGON_NETWORK is not defined in win32api headers.
>
> threadproc/win32/proc.c: In function `apr_procattr_user_set':
> threadproc/win32/proc.c:269: `LOGON32_LOGON_NETWORK' undeclared (first use in this function)
My version of mingw has this symbol defined now, so there's no need to
apply this patch.
Thanks! -- justin
[patch 16/17] win32api omission
Posted by John Mark Vandenberg <ja...@gmail.com>.
LOGON32_LOGON_NETWORK is not defined in win32api headers.
threadproc/win32/proc.c: In function `apr_procattr_user_set':
threadproc/win32/proc.c:269: `LOGON32_LOGON_NETWORK' undeclared (first use in this function)
Index: threadproc/win32/proc.c
===================================================================
--- threadproc/win32/proc.c (revision 387026)
+++ threadproc/win32/proc.c (working copy)
@@ -32,6 +32,10 @@
#include <process.h>
#endif
+#ifndef LOGON32_LOGON_NETWORK
+#define LOGON32_LOGON_NETWORK 3
+#endif
+
#ifdef _WIN32_WCE
#ifndef DETACHED_PROCESS
#define DETACHED_PROCESS 0
--
Re: [patch 15/17] APR_HAS_PROC_INVOKED
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Set APR_HAS_PROC_INVOKED = 1 for MinGW
Committed in r421540.
trunk now compiles, but it fails linking. I'll move on to that tomorrow. =)
Thanks. -- justin
[patch 15/17] APR_HAS_PROC_INVOKED
Posted by John Mark Vandenberg <ja...@gmail.com>.
Set APR_HAS_PROC_INVOKED = 1 for MinGW
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -1570,6 +1570,15 @@ AC_SUBST(aprdso)
dnl ----------------------------- Checking for Processes
echo "${nl}Checking for Processes..."
+have_proc_invoked="0"
+case "$host" in
+ *mingw* )
+ have_proc_invoked="1"
+ ;;
+esac
+
+AC_SUBST(have_proc_invoked)
+
AC_CHECK_FUNCS(waitpid)
AC_ARG_ENABLE(other-child,
Index: include/apr.h.in
===================================================================
--- include/apr.h.in.orig
+++ include/apr.h.in
@@ -237,7 +237,7 @@ extern "C" {
#define APR_HAS_DSO @aprdso@
#define APR_HAS_SO_ACCEPTFILTER @acceptfilter@
#define APR_HAS_UNICODE_FS @have_unicode_fs@
-#define APR_HAS_PROC_INVOKED 0
+#define APR_HAS_PROC_INVOKED @have_proc_invoked@
#define APR_HAS_USER 1
#define APR_HAS_LARGE_FILES @aprlfs@
#define APR_HAS_XTHREAD_FILES 0
--
Re: [patch 06/17] Win32 unicode filesystem
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> file_io/win32/dir.c: In function `apr_dir_read':
> file_io/win32/dir.c:212: structure has no member named `w'
>
> APR_HAS_UNICODE_FS appears to only be used for Windows/Netware
> differentiation, and is only used in */win32/* files.
Committed in r421094.
> HFS Plus or HFS+ are also unicode filsystems.
Indeed.
> Is this the right name for the variable?
No, but it's not going to change now. =)
Thanks! -- justin
[patch 06/17] Win32 unicode filesystem
Posted by John Mark Vandenberg <ja...@gmail.com>.
file_io/win32/dir.c: In function `apr_dir_read':
file_io/win32/dir.c:212: structure has no member named `w'
APR_HAS_UNICODE_FS appears to only be used for Windows/Netware
differentiation, and is only used in */win32/* files.
HFS Plus or HFS+ are also unicode filsystems.
Is this the right name for the variable?
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -1359,6 +1359,15 @@ else
fi
AC_MSG_RESULT($off_t_value)
+have_unicode_fs="0"
+case "$host" in
+ *mingw* )
+ have_unicode_fs="1"
+ ;;
+esac
+
+AC_SUBST(have_unicode_fs)
+
APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], pid_t, 8)
if test "$ac_cv_sizeof_pid_t" = "$ac_cv_sizeof_short"; then
Index: include/apr.h.in
===================================================================
--- include/apr.h.in.orig
+++ include/apr.h.in
@@ -231,7 +231,7 @@ extern "C" {
#define APR_HAS_OTHER_CHILD @oc@
#define APR_HAS_DSO @aprdso@
#define APR_HAS_SO_ACCEPTFILTER @acceptfilter@
-#define APR_HAS_UNICODE_FS 0
+#define APR_HAS_UNICODE_FS @have_unicode_fs@
#define APR_HAS_PROC_INVOKED 0
#define APR_HAS_USER 1
#define APR_HAS_LARGE_FILES @aprlfs@
--
Re: [patch 01/17] MS VC++ 8.0 options
Posted by John Vandenberg <ja...@gmail.com>.
On 4/15/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Which are you building?
All of these patches are to build apr trunk using both MinGW and MS
VC++ 8.0 in an attempt to avoid regressions.
> +1 and I'll commit the patch shortly, if it wasn't already committed.
Thanks for knocking these small ones out of the way quickly.
--
John
Re: [patch 01/17] MS VC++ 8.0 options
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Which are you building? I believed I had already committed that one (tripped
over it myself.) It's possible this is sitting out in one of my many x686/Win64
trees, however.
+1 and I'll commit the patch shortly, if it wasn't already committed.
Bill
John Mark Vandenberg wrote:
> Building testall reports the following warning.
>
> 1. cl : Command line warning D9035 : option 'GX' has been deprecated ...
> cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
>
> Following those instructions doesnt affect the results.
>
> Index: test/Makefile.win
> ===================================================================
> --- test/Makefile.win.orig
> +++ test/Makefile.win
> @@ -25,7 +25,7 @@
>
> CL = cl.exe
>
> -CFLAGS = /nologo /c /MDd /W3 /Gm /GX /Zi /Od /D _DEBUG /D WIN32 /D APR_DECLARE_STATIC /FD
> +CFLAGS = /nologo /c /MDd /W3 /Gm /EHsc /Zi /Od /D _DEBUG /D WIN32 /D APR_DECLARE_STATIC /FD
>
> .c.obj::
> $(CL) -c $< $(CFLAGS) $(INCLUDES)
>
> --
>
> .
>
Re: [patch 01/17] MS VC++ 8.0 options
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Building testall reports the following warning.
>
> 1. cl : Command line warning D9035 : option 'GX' has been deprecated ...
> cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
>
> Following those instructions doesnt affect the results.
Committed in r420953. Thanks! -- justin
[patch 01/17] MS VC++ 8.0 options
Posted by John Mark Vandenberg <ja...@gmail.com>.
Building testall reports the following warning.
1. cl : Command line warning D9035 : option 'GX' has been deprecated ...
cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
Following those instructions doesnt affect the results.
Index: test/Makefile.win
===================================================================
--- test/Makefile.win.orig
+++ test/Makefile.win
@@ -25,7 +25,7 @@
CL = cl.exe
-CFLAGS = /nologo /c /MDd /W3 /Gm /GX /Zi /Od /D _DEBUG /D WIN32 /D APR_DECLARE_STATIC /FD
+CFLAGS = /nologo /c /MDd /W3 /Gm /EHsc /Zi /Od /D _DEBUG /D WIN32 /D APR_DECLARE_STATIC /FD
.c.obj::
$(CL) -c $< $(CFLAGS) $(INCLUDES)
--
Re: [patch 13/17] APR_INLINE
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Define APR_INLINE on MinGW to be static __inline__, and use
> APR_INLINE consistently throughout.
>
> This patch has only been tested with ./configure CFLAGS=" -O0 "
Partially committed in r421810. AFAICT, mingw doesn't need static
inline everywhere - only for when the declarations are in the header
file and hence multiply included.
Thanks. -- justin
[patch 13/17] APR_INLINE
Posted by John Mark Vandenberg <ja...@gmail.com>.
Define APR_INLINE on MinGW to be static __inline__, and use
APR_INLINE consistently throughout.
This patch has only been tested with ./configure CFLAGS=" -O0 "
Index: include/apr.h.in
===================================================================
--- include/apr.h.in.orig
+++ include/apr.h.in
@@ -62,7 +62,11 @@
#define APR_INLINE
#define APR_HAS_INLINE 0
#else
+#ifdef __MINGW32__
+#define APR_INLINE static __inline__
+#else
#define APR_INLINE __inline__
+#endif
#define APR_HAS_INLINE 1
#endif
Index: include/arch/win32/apr_arch_atime.h
===================================================================
--- include/arch/win32/apr_arch_atime.h.orig
+++ include/arch/win32/apr_arch_atime.h
@@ -36,7 +36,7 @@ struct atime_t {
#define APR_DELTA_EPOCH_IN_USEC APR_TIME_C(11644473600000000);
-__inline void FileTimeToAprTime(apr_time_t *result, FILETIME *input)
+APR_INLINE void FileTimeToAprTime(apr_time_t *result, FILETIME *input)
{
/* Convert FILETIME one 64 bit number so we can work with it. */
*result = input->dwHighDateTime;
@@ -48,7 +48,7 @@ __inline void FileTimeToAprTime(apr_time
}
-__inline void AprTimeToFileTime(LPFILETIME pft, apr_time_t t)
+APR_INLINE void AprTimeToFileTime(LPFILETIME pft, apr_time_t t)
{
LONGLONG ll;
t += APR_DELTA_EPOCH_IN_USEC;
Index: include/arch/win32/apr_arch_misc.h
===================================================================
--- include/arch/win32/apr_arch_misc.h.orig
+++ include/arch/win32/apr_arch_misc.h
@@ -155,7 +155,7 @@ FARPROC apr_load_dll_func(apr_dlltoken_e
#define APR_DECLARE_LATE_DLL_FUNC(lib, rettype, calltype, fn, ord, args, names) \
typedef rettype (calltype *apr_winapi_fpt_##fn) args; \
static apr_winapi_fpt_##fn apr_winapi_pfn_##fn = NULL; \
- __inline rettype apr_winapi_##fn args \
+ APR_INLINE rettype apr_winapi_##fn args \
{ if (!apr_winapi_pfn_##fn) \
apr_winapi_pfn_##fn = (apr_winapi_fpt_##fn) \
apr_load_dll_func(lib, #fn, ord); \
--
Re: [patch 00/17] successful msys/mingw build
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Paul Querna wrote:
>> Has anyone had time to seriously look at this patch set?
>
> Nope...
>
>> It would be a great thing to get APR fully supported under MinGW,
>> because then win32 developers can have a completely full toolchain....
>
> Yup...
>
>> John Mark Vandenberg wrote:
>>
>>> This series of patches allows apr to be built using MSYS and MinGW,
>>> but only with CFLAGS=" -O0 ". Compared with tests using MS VC++
>>> builds, only the dso functions appear to have problems specific to
>>> msys builds.
>>>
>>> Failed Tests Total Fail Failed %
>>> ===================================================
>>> testdso 5 4 80.00%
>
> This one above is a concern...
>
>>> testpipe 9 2 22.22%
>>> testsock 7 1 14.29%
>
> These two are not, they are platform limitations not bugs.
>
>>> Curiously, the results differ when testall is run from msys rather
>>> than CMD.
>>>
>>> Failed Tests Total Fail Failed %
>>> ===================================================
>>> testnames 13 1 7.69%
>
> This is obviously a concern
I am pretty sure we can fix the test cases, once we have it building :)
-Paul
Re: [patch 00/17] successful msys/mingw build
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Has anyone had time to seriously look at this patch set?
Nope...
> It would be a great thing to get APR fully supported under MinGW,
> because then win32 developers can have a completely full toolchain....
Yup...
> John Mark Vandenberg wrote:
>
>> This series of patches allows apr to be built using MSYS and MinGW,
>> but only with CFLAGS=" -O0 ". Compared with tests using MS VC++
>> builds, only the dso functions appear to have problems specific to
>> msys builds.
>>
>> Failed Tests Total Fail Failed %
>> ===================================================
>> testdso 5 4 80.00%
This one above is a concern...
>> testpipe 9 2 22.22%
>> testsock 7 1 14.29%
These two are not, they are platform limitations not bugs.
>> Curiously, the results differ when testall is run from msys rather
>> than CMD.
>>
>> Failed Tests Total Fail Failed %
>> ===================================================
>> testnames 13 1 7.69%
This is obviously a concern
Re: [patch 00/17] successful msys/mingw build
Posted by Paul Querna <ch...@force-elite.com>.
Has anyone had time to seriously look at this patch set?
It would be a great thing to get APR fully supported under MinGW,
because then win32 developers can have a completely full toolchain....
John Mark Vandenberg wrote:
> This series of patches allows apr to be built using MSYS and MinGW, but only with CFLAGS=" -O0 ". Compared with tests using MS VC++ builds, only the dso functions appear to have problems specific to msys builds.
>
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 5 4 80.00%
> testpipe 9 2 22.22%
> testsock 7 1 14.29%
>
> Curiously, the results differ when testall is run from msys rather than CMD.
>
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 5 4 80.00%
> testnames 13 1 7.69%
> testpipe 9 2 22.22%
> testsock 7 1 14.29%
>
> In a lovely coincidence, Davi Arnaut posted patches to bug 33490 (APR does not compile with Borland C++) whilst I prepared the series for submission.
>
> Libtool
> -------
>
> Something to be wary of .. msys installers may have installed libtool 1.4e
>
> $ libtool --version
> ltmain.sh (GNU libtool) 1.4e (1.1162 2002/11/22 22:36:25)
>
> Re-running autoconf with libtool 1.4e will complain with:
>
> configure.in:186: error: possibly undefined macro: AC_PROG_LIBTOOL
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
>
> To resolve this, download libtool-1.5 from the mingw project files, and unpack it so the m4 files are in the aclocal directory; usually /share/aclocal/ or /share/aclocal-1.7/
>
> --
> John
Re: [patch 12/17] redefinition of apr_uint16_t
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> In file included from dso/win32/dso.c:20:
> c:/johnv/apr/trunk-mingw/include/arch/win32/apr_arch_file_io.h:55: redefinition of `apr_wchar_t'
> include/arch/win32/apr_arch_utf8.h:26: `apr_wchar_t' previously declared here
>
> apr_arch_utf8.h:26:typedef apr_uint16_t apr_wchar_t;
Note that your title is wrong: apr_wchar_t is the one that's multiply
defined. =)
Committed in r421090. Thanks! -- justin
[patch 12/17] redefinition of apr_uint16_t
Posted by John Mark Vandenberg <ja...@gmail.com>.
In file included from dso/win32/dso.c:20:
c:/johnv/apr/trunk-mingw/include/arch/win32/apr_arch_file_io.h:55: redefinition of `apr_wchar_t'
include/arch/win32/apr_arch_utf8.h:26: `apr_wchar_t' previously declared here
apr_arch_utf8.h:26:typedef apr_uint16_t apr_wchar_t;
Index: include/arch/win32/apr_arch_file_io.h
===================================================================
--- include/arch/win32/apr_arch_file_io.h (revision 387026)
+++ include/arch/win32/apr_arch_file_io.h (working copy)
@@ -52,8 +52,6 @@
#include "arch/win32/apr_arch_utf8.h"
#include <wchar.h>
-typedef apr_uint16_t apr_wchar_t;
-
/* Helper functions for the WinNT ApiW() functions. APR treats all
* resource identifiers (files, etc) by their UTF-8 name, to provide
* access to all named identifiers. [UTF-8 completely maps Unicode
--
Re: [patch 00/17] successful msys/mingw build
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> On 7/14/06, Paul Querna <ch...@force-elite.com> wrote:
....
>> Is this the correct way to do it, or is something wrong in my setup?
>
> That patch should be fine. This is due to Python being a 'true' Win32
> build - so it has path delimiters of '\' which the msys make doesn't
> accept (I referred to this in my earlier post, FWIW - perhaps too
> cryptically though). In a perfect world, we would conditionalize this
> mapping to only be done on Win32 too; but it's essentially a no-op on
> Unix platforms. So, +1.
Committed in r422146.
> BTW, I saw on #apr that you were having an issue with:
>
> /mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined
> reference to `WinMain@16'
>
> This is caused by apr_app.c being pulled in incorrectly (also
> mentioned before too). It defines main() and should not be linked
> with the APR DLL. We need to teach gen-build to ignore that one file.
> (Ideally, we should delete it from the tree, but the test programs
> use it and doing so would cause us to have to tweak MSVC++'s build
> system and I really don't want to do that...)
Thanks, killed it, and it works.
I also got apr-util to compile -- I tried using the bundled expat, but
it broke due to autoconf sillyness -- So I built it using an external
Expart 2.0.0 and everything built great.
-Paul
Re: [patch 00/17] successful msys/mingw build
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/14/06, Paul Querna <ch...@force-elite.com> wrote:
> Justin Erenkrantz wrote:
> > For the record, here's a quick dump of what I downloaded/installed
> > from mingw.sf.net:
> > - MinGW 5.0.3
> > - MSYS-1.0.11-2004.04-30-1
> > - msysDTK-1.0.1
> > - msys-autoconf-2.5.9.tar.bz2 (extract to /usr)
> > - msys-libtool-1.5.tar.bz2 (extract to /usr)
> >
>
> I also needed:
> Python-2.5b2 (to run buildconf)
> TortoiseSVN
>
> So that I could run buildconf.
>
> Steps:
> 1) checkout source
> 2) open msys
> 3) run buildconf
> 4) run ./configure with:
> --enable-experimental-libtool CFLAGS="-O0"
> 5) go get a beer (configure is really slow...)
> 6) run make
>
> Then I ran into problems:
> make[1]: Entering directory `/c/work/asf/apr'
> /c/work/asf/apr/libtool --silent --mode=compile gcc -O0
> -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include
> -I/c/work/asf/apr/include/arch/win32 -I./include/arch/unix
> -I/c/work/asf/apr/include -o passwd\apr_getpass.lo -c
> passwd\apr_getpass.c && touch passwd\apr_getpass.lo
> gcc.exe: passwdapr_getpass.c: No such file or directory
> gcc.exe: no input files
> make[1]: *** [passwd\apr_getpass.lo] Error 1
> make[1]: Leaving directory `/c/work/asf/apr'
> make: *** [all-recursive] Error 1
>
> If I manually changed the libtool line, to use / as path deliminators,
> it works.
>
> So, attached is a patch to modify buildconf to generate a 'correct'
> build-rules.mk on win32.
>
> Is this the correct way to do it, or is something wrong in my setup?
That patch should be fine. This is due to Python being a 'true' Win32
build - so it has path delimiters of '\' which the msys make doesn't
accept (I referred to this in my earlier post, FWIW - perhaps too
cryptically though). In a perfect world, we would conditionalize this
mapping to only be done on Win32 too; but it's essentially a no-op on
Unix platforms. So, +1.
BTW, I saw on #apr that you were having an issue with:
/mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined
reference to `WinMain@16'
This is caused by apr_app.c being pulled in incorrectly (also
mentioned before too). It defines main() and should not be linked
with the APR DLL. We need to teach gen-build to ignore that one file.
(Ideally, we should delete it from the tree, but the test programs
use it and doing so would cause us to have to tweak MSVC++'s build
system and I really don't want to do that...)
Thanks! -- justin
Re: [patch 00/17] successful msys/mingw build
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> For the record, here's a quick dump of what I downloaded/installed
> from mingw.sf.net:
> - MinGW 5.0.3
> - MSYS-1.0.11-2004.04-30-1
> - msysDTK-1.0.1
> - msys-autoconf-2.5.9.tar.bz2 (extract to /usr)
> - msys-libtool-1.5.tar.bz2 (extract to /usr)
>
I also needed:
Python-2.5b2 (to run buildconf)
TortoiseSVN
So that I could run buildconf.
Steps:
1) checkout source
2) open msys
3) run buildconf
4) run ./configure with:
--enable-experimental-libtool CFLAGS="-O0"
5) go get a beer (configure is really slow...)
6) run make
Then I ran into problems:
make[1]: Entering directory `/c/work/asf/apr'
/c/work/asf/apr/libtool --silent --mode=compile gcc -O0
-DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include
-I/c/work/asf/apr/include/arch/win32 -I./include/arch/unix
-I/c/work/asf/apr/include -o passwd\apr_getpass.lo -c
passwd\apr_getpass.c && touch passwd\apr_getpass.lo
gcc.exe: passwdapr_getpass.c: No such file or directory
gcc.exe: no input files
make[1]: *** [passwd\apr_getpass.lo] Error 1
make[1]: Leaving directory `/c/work/asf/apr'
make: *** [all-recursive] Error 1
If I manually changed the libtool line, to use / as path deliminators,
it works.
So, attached is a patch to modify buildconf to generate a 'correct'
build-rules.mk on win32.
Is this the correct way to do it, or is something wrong in my setup?
-Paul
Re: [patch 00/17] successful msys/mingw build
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> This series of patches allows apr to be built using MSYS and MinGW, but only with CFLAGS=" -O0 ". Compared with tests using MS VC++ builds, only the dso functions appear to have problems specific to msys builds.
>
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 5 4 80.00%
> testpipe 9 2 22.22%
> testsock 7 1 14.29%
Okay. Trunk now matches this behavior on mingw. =)
A few minor things left:
- testatomic aborts(); so you have to do 'testall -x testatomic' to
get the above
- gen-build.py script needs to do two things:
- ignore apr_app.c from the build. (it's not meant to be compiled -
only as an example;
removing it from OBJECTS_misc_win32 in build-outputs.mk is sufficient.)
- emit '/' instead of '\' as msys make doesn't like that. (a simple
sed works for now.)
- jlibtool (--enable-experimental-libtool=yes to configure)
- GNU libtool refuses to create DLLs, but jlibtool can create them.
(I stopped caring about GNU libtool once it failed to create DLLs;
so if it works, good;
but I don't care to play their silly games...use jlibtool instead...)
- jlibtool compiles and links about 6x faster than GNU libtool (duh)
- As with all jlibtool builds, you need to install the DLLs in the
PATH to run apps
- However, -module isn't working yet; so the libmod_test.la doesn't link
(removing it from testall.exe's Makefile dependencies seems to do ok.)
If anyone else wants to jump in at this point, the big nasty stuff
should be in the tree now. I'll be working on these to-do items with
a slightly lesser priority now.
For the record, here's a quick dump of what I downloaded/installed
from mingw.sf.net:
- MinGW 5.0.3
- MSYS-1.0.11-2004.04-30-1
- msysDTK-1.0.1
- msys-autoconf-2.5.9.tar.bz2 (extract to /usr)
- msys-libtool-1.5.tar.bz2 (extract to /usr)
If you install those in that order, you should be able to reproduce
the necessary dev setup.
Many thanks to John for these patches! -- justin
Re: [patch 11/17] struct in_addr
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Move the autoconf check for type 'in_addr' into a macro, and
> improve it to work for Windows as well.
Committed in r421071. Thanks! -- justin
[patch 11/17] struct in_addr
Posted by John Mark Vandenberg <ja...@gmail.com>.
Move the autoconf check for type 'in_addr' into a macro, and
improve it to work for Windows as well.
Index: build/apr_network.m4
===================================================================
--- build/apr_network.m4.orig
+++ build/apr_network.m4
@@ -17,6 +17,31 @@ dnl ------------------------------------
dnl apr_network.m4: APR's autoconf macros for testing network support
dnl
+dnl check for type in_addr
+dnl
+dnl
+AC_DEFUN(APR_TYPE_IN_ADDR,[
+ AC_CACHE_CHECK(for type in_addr, ac_cv_type_in_addr,[
+ AC_TRY_COMPILE([
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+#ifdef HAVE_NETINET_IN_H
+#include <netinet/in.h>
+#endif
+#ifdef HAVE_WINSOCK2_H
+#include <winsock2.h>
+#endif
+],[
+ struct in_addr arg;
+ arg.s_addr = htonl(INADDR_ANY);
+], [ ac_cv_type_in_addr="yes"] , [
+ac_cv_type_in_addr="no"])
+])
+])
+
+dnl
+
dnl
dnl check for working getaddrinfo()
dnl
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -1971,17 +1971,12 @@ AC_CHECK_MEMBERS([struct tm.tm_gmtoff, s
dnl ----------------------------- Checking for Networking Support
echo "${nl}Checking for Networking support..."
-AC_MSG_CHECKING(for in_addr in netinet/in.h)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <netinet/in.h>
-],[
-struct in_addr arg;
-arg.s_addr = htonl(INADDR_ANY);
-], [ have_in_addr="1"
-msg=yes ] , [ have_in_addr="0"
-msg=no ])
-AC_MSG_RESULT([$msg])
+APR_TYPE_IN_ADDR
+if test "$ac_cv_type_in_addr" = "yes"; then
+ have_in_addr="1"
+else
+ have_in_addr="0"
+fi
AC_MSG_CHECKING([if fd == socket on this platform])
if test "x$file_as_socket" != "x0" ; then
--
Re: [patch 09/17] struct iovec
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
>> struct iovec is needed to emulate Unix writev. This patch moves
>> the workaround from apr.hw to apr_want.h to it can be shared by
>> any platform without it.
>>
>> AC_CHECK_TYPE has problems determining whether this type exists.
>
> This part is committed in r421075.
>
>> The change to build/apr_common.m4 allows APR_CHECK_SIZEOF_EXTENDED
>> to be called with a space in the argument.
>
> This is committed in r421074. (Do you have any clue what those P and
> p's were for?)
They were for handling pointer types. r421074 changed the
transliterations incorrectly - I've reimported the correct versions from
autoconf 2.59 in r421091:
-define(<<AC_TYPE_NAME>>, translit(sizeof_$2, [a-z ], [A-Z_]))dnl
+define(<<AC_TYPE_NAME>>, translit(sizeof_$2, [a-z *], [A-Z_P]))dnl
-define(<<AC_CV_NAME>>, translit(ac_cv_sizeof_$2, [A-Z ],[a-z_]))dnl
+define(<<AC_CV_NAME>>, translit(ac_cv_sizeof_$2, [ *], [_p]))dnl
Max.
Re: [patch 09/17] struct iovec
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> struct iovec is needed to emulate Unix writev. This patch moves
> the workaround from apr.hw to apr_want.h to it can be shared by
> any platform without it.
>
> AC_CHECK_TYPE has problems determining whether this type exists.
This part is committed in r421075.
> The change to build/apr_common.m4 allows APR_CHECK_SIZEOF_EXTENDED
> to be called with a space in the argument.
This is committed in r421074. (Do you have any clue what those P and
p's were for?)
Thanks! -- justin
[patch 09/17] struct iovec
Posted by John Mark Vandenberg <ja...@gmail.com>.
struct iovec is needed to emulate Unix writev. This patch moves
the workaround from apr.hw to apr_want.h to it can be shared by
any platform without it.
AC_CHECK_TYPE has problems determining whether this type exists.
The change to build/apr_common.m4 allows APR_CHECK_SIZEOF_EXTENDED
to be called with a space in the argument.
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -1438,6 +1438,14 @@ case $host in
;;
esac
+APR_CHECK_SIZEOF_EXTENDED([#include <sys/uio.h>],struct iovec,0)
+if test "$ac_cv_sizeof_struct_iovec" = "0"; then
+ have_iovec=0
+else
+ have_iovec=1
+fi
+
+
AC_SUBST(voidp_size)
AC_SUBST(short_value)
AC_SUBST(int_value)
@@ -1459,6 +1467,7 @@ AC_SUBST(uint64_literal)
AC_SUBST(stdint)
AC_SUBST(bigendian)
AC_SUBST(aprlfs)
+AC_SUBST(have_iovec)
dnl ----------------------------- Checking for string functions
AC_CHECK_FUNCS(strnicmp, have_strnicmp="1", have_strnicmp="0")
Index: include/apr.h.in
===================================================================
--- include/apr.h.in.orig
+++ include/apr.h.in
@@ -220,6 +220,7 @@ extern "C" {
#define APR_HAVE_STRUCT_RLIMIT @struct_rlimit@
#define APR_HAVE_UNION_SEMUN @have_union_semun@
#define APR_HAVE_SCTP @have_sctp@
+#define APR_HAVE_IOVEC @have_iovec@
/* APR Feature Macros */
#define APR_HAS_SHARED_MEMORY @sharedmem@
Index: include/apr_want.h
===================================================================
--- include/apr_want.h.orig
+++ include/apr_want.h
@@ -81,10 +81,28 @@
#ifdef APR_WANT_IOVEC
+#if APR_HAVE_IOVEC
+
#if APR_HAVE_SYS_UIO_H
#include <sys/uio.h>
#endif
+#else
+
+struct iovec
+{
+ char *iov_base;
+ int iov_len;
+};
+
+#endif
+
+/* apr_want is included at several layers; redefining APR_HAVE_IOVEC
+ * to ensure struct is not introduced several times
+ */
+#undef APR_HAVE_IOVEC
+#define APR_HAVE_IOVEC 1
+
#undef APR_WANT_IOVEC
#endif
Index: build/apr_common.m4
===================================================================
--- build/apr_common.m4.orig
+++ build/apr_common.m4
@@ -446,9 +446,9 @@ dnl
AC_DEFUN([APR_CHECK_SIZEOF_EXTENDED],
[changequote(<<,>>)dnl
dnl The name to #define
-define(<<AC_TYPE_NAME>>, translit(sizeof_$2, [a-z *], [A-Z_P]))dnl
+define(<<AC_TYPE_NAME>>, translit(sizeof_$2, [a-z ], [A-Z_]))dnl
dnl The cache variable
-define(<<AC_CV_NAME>>, translit(ac_cv_sizeof_$2, [ *],[<p>]))dnl
+define(<<AC_CV_NAME>>, translit(ac_cv_sizeof_$2, [A-Z ],[a-z_]))dnl
changequote([, ])dnl
AC_MSG_CHECKING(size of $2)
AC_CACHE_VAL(AC_CV_NAME,
Index: include/apr.hw
===================================================================
--- include/apr.hw.orig
+++ include/apr.hw
@@ -487,10 +487,7 @@ typedef int gid_t;
typedef int apr_wait_t;
/* struct iovec is needed to emulate Unix writev */
-struct iovec {
- char* iov_base;
- apr_size_t iov_len;
-};
+#define APR_HAVE_IOVEC 0
/* Nasty Win32 .h ommissions we really need */
#define STDIN_FILENO 0
--
Re: [patch 14/17] crtdbg.h
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> Move usage of MS VC++ crtdbg.h functionality into #if defined(_MSC_VER)
Committed in r421373. Thanks! -- justin
[patch 14/17] crtdbg.h
Posted by John Mark Vandenberg <ja...@gmail.com>.
Move usage of MS VC++ crtdbg.h functionality into #if defined(_MSC_VER)
Index: include/arch/win32/apr_arch_misc.h
===================================================================
--- include/arch/win32/apr_arch_misc.h.orig
+++ include/arch/win32/apr_arch_misc.h
@@ -138,6 +138,29 @@ apr_status_t apr_get_oslevel(apr_oslevel
#define ELSE_WIN_OS_IS_ANSI
#endif /* WINNT */
+#if defined(_MSC_VER)
+#include "crtdbg.h"
+
+APR_INLINE void* apr_malloc_dbg(size_t size, const char* filename, int linenumber) {
+ return _malloc_dbg(size, _CRT_BLOCK, filename, linenumber);
+}
+
+APR_INLINE void* apr_realloc_dbg(void* userData, size_t newSize, const char* filename, int linenumber) {
+ return _realloc_dbg(userData, newSize, _CRT_BLOCK, filename, linenumber);
+}
+
+#else
+
+APR_INLINE void* apr_malloc_dbg(size_t size, const char* filename, int linenumber) {
+ return malloc(size);
+}
+
+APR_INLINE void* apr_realloc_dbg(void* userData, size_t newSize, const char* filename, int linenumber) {
+ return realloc(userData, newSize);
+}
+
+#endif /* ! _MSC_VER */
+
typedef enum {
DLL_WINBASEAPI = 0, // kernel32 From WinBase.h
DLL_WINADVAPI = 1, // advapi32 From WinBase.h
Index: misc/win32/apr_app.c
===================================================================
--- misc/win32/apr_app.c.orig
+++ misc/win32/apr_app.c
@@ -36,7 +36,6 @@
#include "apr_general.h"
#include "apr_private.h"
#include "ShellAPI.h"
-#include "crtdbg.h"
#include "wchar.h"
#include "apr_arch_file_io.h"
#include "assert.h"
@@ -57,8 +56,8 @@ int wmain(int argc, const wchar_t **warg
dupenv = apr_wastrtoastr(&env, wenv, -1);
- _environ = _malloc_dbg((dupenv + 1) * sizeof (char *),
- _CRT_BLOCK, __FILE__, __LINE__ );
+ _environ = apr_malloc_dbg((dupenv + 1) * sizeof (char *),
+ __FILE__, __LINE__ );
memcpy(_environ, env, (dupenv + 1) * sizeof (char *));
/* MSVCRT will attempt to maintain the wide environment calls
Index: misc/win32/internal.c
===================================================================
--- misc/win32/internal.c.orig
+++ misc/win32/internal.c
@@ -18,7 +18,6 @@
#include "apr_arch_misc.h"
#include "apr_arch_file_io.h"
-#include <crtdbg.h>
#include <assert.h>
/* This module is the source of -static- helper functions that are
@@ -52,8 +51,8 @@ int apr_wastrtoastr(char const * const *
;
}
- newarr = _malloc_dbg((args + 1) * sizeof(char *),
- _CRT_BLOCK, __FILE__, __LINE__);
+ newarr = apr_malloc_dbg((args + 1) * sizeof(char *),
+ __FILE__, __LINE__);
for (arg = 0; arg < args; ++arg) {
newarr[arg] = (void*)(wcslen(arr[arg]) + 1);
@@ -66,8 +65,8 @@ int apr_wastrtoastr(char const * const *
* 4 ucs bytes will hold a wchar_t pair value (20 bits)
*/
elesize = elesize * 3 + 1;
- ele = elements = _malloc_dbg(elesize * sizeof(char),
- _CRT_BLOCK, __FILE__, __LINE__);
+ ele = elements = apr_malloc_dbg(elesize * sizeof(char),
+ __FILE__, __LINE__);
for (arg = 0; arg < args; ++arg) {
apr_size_t len = (apr_size_t)newarr[arg];
@@ -87,8 +86,8 @@ int apr_wastrtoastr(char const * const *
/* Return to the free store if the heap realloc is the least bit optimized
*/
- ele = _realloc_dbg(elements, ele - elements,
- _CRT_BLOCK, __FILE__, __LINE__);
+ ele = apr_realloc_dbg(elements, ele - elements,
+ __FILE__, __LINE__);
if (ele != elements) {
apr_size_t diff = ele - elements;
Index: misc/win32/start.c
===================================================================
--- misc/win32/start.c.orig
+++ misc/win32/start.c
@@ -23,7 +23,6 @@
#include "apr_arch_misc.h" /* for WSAHighByte / WSALowByte */
#include "wchar.h"
#include "apr_arch_file_io.h"
-#include "crtdbg.h"
#include "assert.h"
/* This symbol is _private_, although it must be exported.
@@ -54,8 +53,8 @@ static int warrsztoastr(const char * con
}
wsize = 1 + wch - arrsz;
- newarr = _malloc_dbg((args + 1) * sizeof(char *),
- _CRT_BLOCK, __FILE__, __LINE__);
+ newarr = apr_malloc_dbg((args + 1) * sizeof(char *),
+ __FILE__, __LINE__);
/* This is a safe max allocation, we will realloc after
* processing and return the excess to the free store.
@@ -63,8 +62,8 @@ static int warrsztoastr(const char * con
* 4 ucs bytes will hold a wchar_t pair value (20 bits)
*/
newlen = totlen = wsize * 3 + 1;
- newarr[0] = _malloc_dbg(newlen * sizeof(char),
- _CRT_BLOCK, __FILE__, __LINE__);
+ newarr[0] = apr_malloc_dbg(newlen * sizeof(char),
+ __FILE__, __LINE__);
(void)apr_conv_ucs2_to_utf8(arrsz, &wsize,
newarr[0], &newlen);
@@ -72,8 +71,8 @@ static int warrsztoastr(const char * con
assert(newlen && !wsize);
/* Return to the free store if the heap realloc is the least bit optimized
*/
- newarr[0] = _realloc_dbg(newarr[0], totlen - newlen,
- _CRT_BLOCK, __FILE__, __LINE__);
+ newarr[0] = apr_realloc_dbg(newarr[0], totlen - newlen,
+ __FILE__, __LINE__);
for (arg = 1; arg < args; ++arg) {
newarr[arg] = newarr[arg - 1] + 2;
@@ -128,8 +127,8 @@ APR_DECLARE(apr_status_t) apr_app_initia
dupenv = warrsztoastr(&_environ, sysstr, -1);
if (env) {
- *env = _malloc_dbg((dupenv + 1) * sizeof (char *),
- _CRT_BLOCK, __FILE__, __LINE__ );
+ *env = apr_malloc_dbg((dupenv + 1) * sizeof (char *),
+ __FILE__, __LINE__ );
memcpy((void*)*env, _environ, (dupenv + 1) * sizeof (char *));
}
else {
Index: misc/win32/misc.c
===================================================================
--- misc/win32/misc.c.orig
+++ misc/win32/misc.c
@@ -16,7 +16,6 @@
#include "apr_private.h"
#include "apr_arch_misc.h"
-#include "crtdbg.h"
#include "apr_arch_file_io.h"
#include "assert.h"
#include "apr_lib.h"
--
Re: [patch 10/17] include path prefix win32/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
John Mark Vandenberg wrote:
> The current autotools build system does not add 'include/arch' to
> the include path, so the includes in the form 'win32/...' dont
> work.
>
> The build system could be enhanced, but this brings win32 into line
> with the other platforms.
Agreed, the old semantics are a problem.
Re: [patch 10/17] include path prefix win32/
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> The current autotools build system does not add 'include/arch' to
> the include path, so the includes in the form 'win32/...' dont
> work.
>
> The build system could be enhanced, but this brings win32 into line
> with the other platforms.
Committed in r421349. Thanks! -- justin
[patch 10/17] include path prefix win32/
Posted by John Mark Vandenberg <ja...@gmail.com>.
The current autotools build system does not add 'include/arch' to
the include path, so the includes in the form 'win32/...' dont
work.
The build system could be enhanced, but this brings win32 into line
with the other platforms.
Index: file_io/win32/buffer.c
===================================================================
--- file_io/win32/buffer.c.orig
+++ file_io/win32/buffer.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_file_io.h"
#include "apr_thread_mutex.h"
APR_DECLARE(apr_status_t) apr_file_buffer_set(apr_file_t *file,
@@ -56,4 +56,4 @@ APR_DECLARE(apr_status_t) apr_file_buffe
APR_DECLARE(apr_size_t) apr_file_buffer_size_get(apr_file_t *file)
{
return file->bufsize;
-}
\ No newline at end of file
+}
Index: file_io/win32/filedup.c
===================================================================
--- file_io/win32/filedup.c.orig
+++ file_io/win32/filedup.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_file_io.h"
#include "apr_file_io.h"
#include "apr_general.h"
#include "apr_strings.h"
Index: file_io/win32/pipe.c
===================================================================
--- file_io/win32/pipe.c.orig
+++ file_io/win32/pipe.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_file_io.h"
#include "apr_file_io.h"
#include "apr_general.h"
#include "apr_strings.h"
Index: file_io/win32/readwrite.c
===================================================================
--- file_io/win32/readwrite.c.orig
+++ file_io/win32/readwrite.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_file_io.h"
#include "apr_file_io.h"
#include "apr_general.h"
#include "apr_strings.h"
Index: file_io/win32/seek.c
===================================================================
--- file_io/win32/seek.c.orig
+++ file_io/win32/seek.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_file_io.h"
#include "apr_file_io.h"
#include <errno.h>
#include <string.h>
Index: locks/win32/thread_cond.c
===================================================================
--- locks/win32/thread_cond.c.orig
+++ locks/win32/thread_cond.c
@@ -18,8 +18,8 @@
#include "apr_private.h"
#include "apr_general.h"
#include "apr_strings.h"
-#include "win32/apr_arch_thread_mutex.h"
-#include "win32/apr_arch_thread_cond.h"
+#include "apr_arch_thread_mutex.h"
+#include "apr_arch_thread_cond.h"
#include "apr_portable.h"
static apr_status_t thread_cond_cleanup(void *data)
Index: locks/win32/thread_rwlock.c
===================================================================
--- locks/win32/thread_rwlock.c.orig
+++ locks/win32/thread_rwlock.c
@@ -18,7 +18,7 @@
#include "apr_private.h"
#include "apr_general.h"
#include "apr_strings.h"
-#include "win32/apr_arch_thread_rwlock.h"
+#include "apr_arch_thread_rwlock.h"
#include "apr_portable.h"
static apr_status_t thread_rwlock_cleanup(void *data)
Index: threadproc/win32/proc.c
===================================================================
--- threadproc/win32/proc.c.orig
+++ threadproc/win32/proc.c
@@ -14,8 +14,8 @@
* limitations under the License.
*/
-#include "win32/apr_arch_threadproc.h"
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_threadproc.h"
+#include "apr_arch_file_io.h"
#include "apr_thread_proc.h"
#include "apr_file_io.h"
Index: threadproc/win32/signals.c
===================================================================
--- threadproc/win32/signals.c.orig
+++ threadproc/win32/signals.c
@@ -14,8 +14,8 @@
* limitations under the License.
*/
-#include "win32/apr_arch_threadproc.h"
-#include "win32/apr_arch_file_io.h"
+#include "apr_arch_threadproc.h"
+#include "apr_arch_file_io.h"
#include "apr_thread_proc.h"
#include "apr_file_io.h"
#include "apr_general.h"
Index: threadproc/win32/thread.c
===================================================================
--- threadproc/win32/thread.c.orig
+++ threadproc/win32/thread.c
@@ -15,7 +15,7 @@
*/
#include "apr_private.h"
-#include "win32/apr_arch_threadproc.h"
+#include "apr_arch_threadproc.h"
#include "apr_thread_proc.h"
#include "apr_general.h"
#include "apr_lib.h"
Index: threadproc/win32/threadpriv.c
===================================================================
--- threadproc/win32/threadpriv.c.orig
+++ threadproc/win32/threadpriv.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_threadproc.h"
+#include "apr_arch_threadproc.h"
#include "apr_thread_proc.h"
#include "apr_general.h"
#include "apr_lib.h"
Index: time/win32/access.c
===================================================================
--- time/win32/access.c.orig
+++ time/win32/access.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_atime.h"
+#include "apr_arch_atime.h"
#include "apr_time.h"
#include "apr_general.h"
#include "apr_lib.h"
Index: time/win32/time.c
===================================================================
--- time/win32/time.c.orig
+++ time/win32/time.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_atime.h"
+#include "apr_arch_atime.h"
#include "apr_time.h"
#include "apr_general.h"
#include "apr_lib.h"
Index: time/win32/timestr.c
===================================================================
--- time/win32/timestr.c.orig
+++ time/win32/timestr.c
@@ -14,7 +14,7 @@
* limitations under the License.
*/
-#include "win32/apr_arch_atime.h"
+#include "apr_arch_atime.h"
#include "apr_portable.h"
#include "apr_strings.h"
--
[patch 04/17] support msys make
Posted by John Mark Vandenberg <ja...@gmail.com>.
Enable the Makefiles to run using MSYS make.
Index: configure.in
===================================================================
--- configure.in.orig
+++ configure.in
@@ -205,7 +205,8 @@ if test "x$use_libtool" = "xyes"; then
export_lib_target='-rpath \$(libdir) \$(OBJECTS)'
else
lt_compile='$(COMPILE) -o $@ -c $<'
- link='$(AR) cr $(TARGET_LIB) $(OBJECTS); $(RANLIB) $(TARGET_LIB)'
+ # /bin/true consumes trailing arguments
+ link='$(AR) cr $(TARGET_LIB) $(OBJECTS); $(RANLIB) $(TARGET_LIB) && /bin/true'
so_ext='o'
lib_target=''
export_lib_target=''
Index: build/apr_rules.mk.in
===================================================================
--- build/apr_rules.mk.in.orig
+++ build/apr_rules.mk.in
@@ -37,6 +37,9 @@ AWK=@AWK@
SHELL=@SHELL@
LIBTOOL=@LIBTOOL@
+AR=@AR@
+RANLIB=@RANLIB@
+
# compilation and linking flags that are supposed to be set only by the user.
# configure adds to them for tests, but we restore them at the end.
#
--