Re: building apr on cygwin for mingw
On Sun, Dec 10, 2006 at 08:42:29PM +1100, John Vandenberg wrote: On 12/9/06, Bob Rossi [EMAIL PROTECTED] wrote: On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote: We should first check whether the libtool developers intentionally added that blank line; if they can fix the regression on their side, it means that the next stable version of libtool will work with older source tarballs of apr. Was i supposed to do this? Ralf Wildenhues has removed the offending blank line from libtool. Thanks John, for getting that done. Should I wait for the next release of libtool to come out, or is the regex going to be modified? Thanks, Bob Rossi
Re: building apr on cygwin for mingw
On 12/12/06, Bob Rossi [EMAIL PROTECTED] wrote: On Sun, Dec 10, 2006 at 08:42:29PM +1100, John Vandenberg wrote: On 12/9/06, Bob Rossi [EMAIL PROTECTED] wrote: On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote: We should first check whether the libtool developers intentionally added that blank line; if they can fix the regression on their side, it means that the next stable version of libtool will work with older source tarballs of apr. Was i supposed to do this? Ralf Wildenhues has removed the offending blank line from libtool. Thanks John, for getting that done. Should I wait for the next release of libtool to come out, or is the regex going to be modified? libtool 1.5.23a is an alpha release, so this problem has never made it out into the wild, thanks to your bug report. Personally, I dont think the sed expression in the APR needs to change -- it could be more permissive, but I pretty sure that we wont be seeing libtool emit a leading blank line for a very long time -- next time it will be some other minor unintentional change, and its hard to predict what it will be. Did you end up with libtool 1.5.23a by doing a standard cygwin install, or did you specifically select that version? If it was automagically selected for you, then my guess is that another cygwin package you installed depended on that alpha release of libtool, and I would recommend that you discuss this with the cygwin list. If you specifically selected version 1.5.23a, consider rolling back to 1.5.22 Alternatively, you could fix the current alpha version of libtool you have installed: edit /usr/bin/libtool and remove the blank line (around line 838) that caused this glitch. -- John
Re: building apr on cygwin for mingw
On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote: We should first check whether the libtool developers intentionally added that blank line; if they can fix the regression on their side, it means that the next stable version of libtool will work with older source tarballs of apr. Was i supposed to do this? Thanks, Bob Rossi
Re: building apr on cygwin for mingw
On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote: Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the default for the cross compiled size is 8. However, ssize_t for me is 4. So, the configure fails. I made this change: Can't you set ac_cv_sizeof_ssize_t=4 to get round that? Regards, joe
Re: building apr on cygwin for mingw
On Tue, Dec 05, 2006 at 12:34:36PM +, Joe Orton wrote: On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote: Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the default for the cross compiled size is 8. However, ssize_t for me is 4. So, the configure fails. I made this change: Can't you set ac_cv_sizeof_ssize_t=4 to get round that? Yup, but that's not going to work when I upgrade my compiler, or something else changes. The point is, I'm in an environment where the host program can run, and tell me exactly what the size is. Thanks, Bob Rossi
Re: building apr on cygwin for mingw
Failed Tests Total FailFailed % === testdso 5 4 80.00% testpipe 9 2 22.22% testpipe errors are expected. Filesystem pipes on windows do not behave in a socket-compatible, select()able manner. testdso is another story - perhaps it believes it's using the dlxxx flavor instead of windows, and some common code it causing it to throw up?
Re: building apr on cygwin for mingw
On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote: Failed TestsTotal FailFailed % === testdso 5 4 80.00% testpipe9 2 22.22% testpipe errors are expected. Filesystem pipes on windows do not behave in a socket-compatible, select()able manner. testdso is another story - perhaps it believes it's using the dlxxx flavor instead of windows, and some common code it causing it to throw up? Thanks for the quick response. This is the output of my configure run. Is something obviously wrong here? Checking for DSO... checking for NSLinkModule... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes adding -ldl to LIBS checking for dlsym... yes Thanks, Bob Rossi
Re: building apr on cygwin for mingw
If you force dlopen and dlsym to 0, see what happens. dso/win32/dso.c, is the source we should be compiling, not the dso/unix/dso.c. Can you check that? Bob Rossi wrote: On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote: Failed TestsTotal FailFailed % === testdso 5 4 80.00% testpipe9 2 22.22% testpipe errors are expected. Filesystem pipes on windows do not behave in a socket-compatible, select()able manner. testdso is another story - perhaps it believes it's using the dlxxx flavor instead of windows, and some common code it causing it to throw up? Thanks for the quick response. This is the output of my configure run. Is something obviously wrong here? Checking for DSO... checking for NSLinkModule... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes adding -ldl to LIBS checking for dlsym... yes Thanks, Bob Rossi
Re: building apr on cygwin for mingw
Bob Rossi wrote: Thanks for the quick response. This is the output of my configure run. Is something obviously wrong here? also - check that APR_HAS_DSO is 1.
Re: building apr on cygwin for mingw
Hi, Well, here is the compile command. /bin/sh /home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32 -I./include/arch/unix -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include -o dso/win32/dso.lo -c dso/win32/dso.c touch dso/win32/dso.lo And yes, #define APR_HAS_DSO 1 Thanks, Bob Rossi On Tue, Dec 05, 2006 at 03:11:30PM -0600, William A. Rowe, Jr. wrote: If you force dlopen and dlsym to 0, see what happens. dso/win32/dso.c, is the source we should be compiling, not the dso/unix/dso.c. Can you check that? Bob Rossi wrote: On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote: Failed Tests Total FailFailed % === testdso 5 4 80.00% testpipe 9 2 22.22% testpipe errors are expected. Filesystem pipes on windows do not behave in a socket-compatible, select()able manner. testdso is another story - perhaps it believes it's using the dlxxx flavor instead of windows, and some common code it causing it to throw up? Thanks for the quick response. This is the output of my configure run. Is something obviously wrong here? Checking for DSO... checking for NSLinkModule... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes adding -ldl to LIBS checking for dlsym... yes Thanks, Bob Rossi
Re: building apr on cygwin for mingw
On 12/6/06, Bob Rossi [EMAIL PROTECTED] wrote: On Tue, Dec 05, 2006 at 10:16:52AM +1100, John Vandenberg wrote: Hi Bob, On 12/2/06, Bob Rossi [EMAIL PROTECTED] wrote: First, and oddly enough, the buildconf script fails for me because build/buildcheck.sh doesn't recognize my libtool --version. I don't know sed well enough, and thought someone here would quickly be able to spot the problem. If not, I'll have to look deeper. $ libtool --version 2/dev/null ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This command is failing by giving me no output. $ libtool --version 2/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' The following worked for me on Fedora Core 3, MSYS (MINGW32_NT-5.1 - 1.0.11), and Cygwin (CYGWIN_NT-5.1 - 1.5.18): $ cat EOF | sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. EOF 1.5.23a Could you let us know which version of sed you are using. $ sed --version GNU sed version 4.1.5 That's on Cygwin of course. The problem appears to be that libtool is now emitting a blank line before the line that contains the version string; try $ libtool --version 2/dev/null | sed -e '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' So, after patching autoconf, and making these two patches to apr, I was able to cross compile on cygwin with this command, ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32 CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' I was able to take a sample program, and run it on a machine that did not have cygwin installed, and it ran fine. It was simply a hello world type program with apr stuff in it. Have you tried the test suite? Nope, great idea. Attached is the results. I'm going to try a native build of mingw to make sure the results are the same. How do these results look? They look comparable to the last msys/MinGW test results I have seen. http://marc2.theaimsgroup.com/?l=apr-devm=114506483217503w=2 -- John
Re: building apr on cygwin for mingw
On Wed, Dec 06, 2006 at 08:30:55AM +1100, John Vandenberg wrote: The problem appears to be that libtool is now emitting a blank line before the line that contains the version string; try $ libtool --version 2/dev/null | sed -e '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' Works like a charm. $ libtool --version 2/dev/null | sed -e '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' 1.5.23a So, after patching autoconf, and making these two patches to apr, I was able to cross compile on cygwin with this command, ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32 CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' I was able to take a sample program, and run it on a machine that did not have cygwin installed, and it ran fine. It was simply a hello world type program with apr stuff in it. Have you tried the test suite? Nope, great idea. Attached is the results. I'm going to try a native build of mingw to make sure the results are the same. How do these results look? They look comparable to the last msys/MinGW test results I have seen. http://marc2.theaimsgroup.com/?l=apr-devm=114506483217503w=2 Intereseting. So everything appears to be correct? For some reason, testsock works now, and it didn't before. I'd love to see the sed command go into apr. I'm still wondering what should be done about the m4 macros. Thanks, Bob Rossi
Re: building apr on cygwin for mingw
Bob Rossi wrote: Hi, Well, here is the compile command. /bin/sh /home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32 -I./include/arch/unix -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include -o dso/win32/dso.lo -c dso/win32/dso.c touch dso/win32/dso.lo And yes, #define APR_HAS_DSO 1 Beauty. If you can share the backtrace (you said it crashed, no?) this too might be helpful.
Re: building apr on cygwin for mingw
On 12/6/06, Bob Rossi [EMAIL PROTECTED] wrote: On Wed, Dec 06, 2006 at 08:30:55AM +1100, John Vandenberg wrote: The problem appears to be that libtool is now emitting a blank line before the line that contains the version string; try $ libtool --version 2/dev/null | sed -e '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' Works like a charm. $ libtool --version 2/dev/null | sed -e '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' 1.5.23a I have grabbed a copy of libtool-1.5.22 and 1.5.23a. I can confirm that 1.5.23a is emitting a blank line first, while 1.5.22 does not. Sounds like a bug in their development builds. So, after patching autoconf, and making these two patches to apr, I was able to cross compile on cygwin with this command, ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32 CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' I was able to take a sample program, and run it on a machine that did not have cygwin installed, and it ran fine. It was simply a hello world type program with apr stuff in it. Have you tried the test suite? Nope, great idea. Attached is the results. I'm going to try a native build of mingw to make sure the results are the same. How do these results look? They look comparable to the last msys/MinGW test results I have seen. http://marc2.theaimsgroup.com/?l=apr-devm=114506483217503w=2 Intereseting. So everything appears to be correct? For some reason, testsock works now, and it didn't before. Great! Hopefully in another few months testdso will also start working correctly :-) I'd love to see the sed command go into apr. We should first check whether the libtool developers intentionally added that blank line; if they can fix the regression on their side, it means that the next stable version of libtool will work with older source tarballs of apr. -- John
Re: building apr on cygwin for mingw
Bob Rossi wrote: On Tue, Dec 05, 2006 at 03:35:21PM -0600, William A. Rowe, Jr. wrote: Bob Rossi wrote: Hi, Well, here is the compile command. /bin/sh /home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32 -I./include/arch/unix -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include -o dso/win32/dso.lo -c dso/win32/dso.c touch dso/win32/dso.lo And yes, #define APR_HAS_DSO 1 Beauty. If you can share the backtrace (you said it crashed, no?) this too might be helpful. It raised an assertion. Assertion failed: rv == APR_SUCCESS, file testmutexscope.c, line 168 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Would you still like a backtrace? Can one typically get that for apr using GDB using the standard techniques? ie. (r, bt) Thanks, Bob Rossi This is what i sent to the list on the past regarding this error when building under mingw from trunk. ... I've just been working on getting the mingw build of apr up and running (based on [EMAIL PROTECTED]), it all seems to go well and i get the compiled libraries as expected. However when it comes to testing i notice that there are problems such that the testmutexscope.exe fails. The output is as follows. quote Trying proc mutexes with mechanism `default'... Mutex mechanism `default' is global in scope on this platform. Assertion failed: rv == APR_SUCCESS, file testmutexscope.c, line 169 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. /quote Basically what appears to be happening in that the apr_thread_join returns APR_INCOMPLETE, this is correct as per the apr_thread_join source code as the thread's pool is still intact (apr_thread_exit was not called for thread cleanup). However the thread itself has exited, or more rather then threads main function has returned. My question comes down to the usage of apr_thread_exit(...), should all threads prior to returning call this function, and if it does not then is it considered a usage error? I would be inclined to change the dummy thread function such that if the threads function registered via apr_thread_create does return then apr_thread_exit(...) is called, however this is more a fail safe for perhaps incorrect usage? I myself did try to assertain whether apr_thread_exit() was infact required to be called, however i failed and looking at the test examples they generally do not. Andrew
Re: building apr on cygwin for mingw
On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote: Hi, I've successfully cross compiled apr on cygwin to mingw. I've already had one patch go upstream to autoconf, which fixes a problem AC_CHECK_SIZEOF. I have two very small other problems, that need to be sent upstream, and then trunk should work out of the box. First, and oddly enough, the buildconf script fails for me because build/buildcheck.sh doesn't recognize my libtool --version. I don't know sed well enough, and thought someone here would quickly be able to spot the problem. If not, I'll have to look deeper. $ libtool --version 2/dev/null ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This command is failing by giving me no output. $ libtool --version 2/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' So, I changed it to $ libtool --version 2/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;' and it worked, but I don't think that is the correct fix. Any ideas? Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the default for the cross compiled size is 8. However, ssize_t for me is 4. So, the configure fails. I made this change: -APR_CHECK_SIZEOF_EXTENDED([#include sys/types.h], ssize_t, 8) +AC_CHECK_SIZEOF([ssize_t], [#include stdio.h +#include sys/types.h]) and things work nicely. Would a patch like this be acceptable? There are 5 changes I made just like this. Finally, the macro APR_CHECK_SIZEOF_EXTENDED could probably be removed. So, after patching autoconf, and making these two patches to apr, I was able to cross compile on cygwin with this command, ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32 CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' I was able to take a sample program, and run it on a machine that did not have cygwin installed, and it ran fine. It was simply a hello world type program with apr stuff in it. I would really appreciate if these thoughts could be considered, so I could create a patch to send upstream. I'm very interested in feedback on this issue. Sorry if I'm to impatient, I know a release was just made and everyone is probably very busy. Thanks, Bob Rossi
Re: building apr on cygwin for mingw
Hi Bob, On 12/2/06, Bob Rossi [EMAIL PROTECTED] wrote: First, and oddly enough, the buildconf script fails for me because build/buildcheck.sh doesn't recognize my libtool --version. I don't know sed well enough, and thought someone here would quickly be able to spot the problem. If not, I'll have to look deeper. $ libtool --version 2/dev/null ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This command is failing by giving me no output. $ libtool --version 2/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' The following worked for me on Fedora Core 3, MSYS (MINGW32_NT-5.1 - 1.0.11), and Cygwin (CYGWIN_NT-5.1 - 1.5.18): $ cat EOF | sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q' ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. EOF 1.5.23a Could you let us know which version of sed you are using. So, after patching autoconf, and making these two patches to apr, I was able to cross compile on cygwin with this command, ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32 CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' I was able to take a sample program, and run it on a machine that did not have cygwin installed, and it ran fine. It was simply a hello world type program with apr stuff in it. Have you tried the test suite? -- John
Re: Building APR with Cygwin?
On 7/12/05, Dan Johnson [EMAIL PROTECTED] wrote: Hi Dan, Has anyone build APR 1.1.1 on Cygwin? I found some packages at Cygwin's site but they were 0.9.5 and 0.9.6. I tried building the Unix distribution directly but the configure script dies with decision on anonymous shared memory allocation method failed. Is this a well-known problem? I quickly attempted this on Cygwin using the 1.1.1 trunk code, without any issues. The relevant part of the log for each looks like this on Windows XP when I generate configure using an up to date Cygwin with `autoconf-2.5x' ... checking for shmdt... yes checking for shmctl... yes checking for create_area... no checking for MAP_ANON in sys/mman.h... yes checking for /dev/zero... yes checking for mmap that can map /dev/zero... yes decision on anonymous shared memory allocation method... 4.4BSD-style mmap() via MAP_ANON decision on namebased memory allocation method... SysV IPC shmget() ... I dont know a lot about Cygwin, but I would check that out first. What were the configure results for header sys/mman.h, function mmap, and function munmap? Cheers, John
RE: Building APR with Cygwin?
The problem is that I need to compile using MinGW under Cygwin, and MinGW doesn't provide any of the shared memory header files (shm.h, sys/mmap.h, sys/mman.h, etc.) so the test fails. A quick Google shows that a few other people have had this problem trying to build Subversion with MinGW but it doesn't look like anyone's resolved it. Does anyone know of a successful APR build with MinGW? Thanks, Dan Daniel M. Johnson Software Engineer | One Hornet Way, MS 9M52/W6 Northrop Grumman Integrated Systems | El Segundo, CA 90245-2804 J-UCAS Vehicle Management Systems | Telephone: (310) 345-5253 -Original Message- From: John Vandenberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 12:37 AM To: Dan Johnson Cc: dev@apr.apache.org Subject: Re: Building APR with Cygwin? On 7/12/05, Dan Johnson [EMAIL PROTECTED] wrote: Hi Dan, Has anyone build APR 1.1.1 on Cygwin? I found some packages at Cygwin's site but they were 0.9.5 and 0.9.6. I tried building the Unix distribution directly but the configure script dies with decision on anonymous shared memory allocation method failed. Is this a well-known problem? I quickly attempted this on Cygwin using the 1.1.1 trunk code, without any issues. The relevant part of the log for each looks like this on Windows XP when I generate configure using an up to date Cygwin with `autoconf-2.5x' ... checking for shmdt... yes checking for shmctl... yes checking for create_area... no checking for MAP_ANON in sys/mman.h... yes checking for /dev/zero... yes checking for mmap that can map /dev/zero... yes decision on anonymous shared memory allocation method... 4.4BSD-style mmap() via MAP_ANON decision on namebased memory allocation method... SysV IPC shmget() ... I dont know a lot about Cygwin, but I would check that out first. What were the configure results for header sys/mman.h, function mmap, and function munmap? Cheers, John
RE: Building APR with Cygwin?
On Tue, 12 Jul 2005, Dan Johnson wrote: The problem is that I need to compile using MinGW under Cygwin, and MinGW doesn't provide any of the shared memory header files (shm.h, sys/mmap.h, sys/mman.h, etc.) so the test fails. A quick Google shows that a few other people have had this problem trying to build Subversion with MinGW but it doesn't look like anyone's resolved it. Does anyone know of a successful APR build with MinGW? I feel like I remember a little discussion about this on this list at some point in the past, but basically what I'd ask is, simply, why use Cygwin? APR is by its nature designed to be its own portability layer -- you don't need the added portability layer of cygwin stacked on top of it. You can build APR natively on win32 with no trouble at all; we distribute visual studio projects with APR for this purpose. The upshot is that you can therefore build a native Subversion on win32 as well by using a native APR, since it's APR's job to do all the interfacing with the operating system.
Re: Building APR with Cygwin?
On 7/13/05, Dan Johnson [EMAIL PROTECTED] wrote: The problem is that I need to compile using MinGW under Cygwin, and MinGW doesn't provide any of the shared memory header files (shm.h, sys/mmap.h, sys/mman.h, etc.) so the test fails. Dan, It sounds like you are building for MinGW, and Cygwin is just a build environment. Is that what you want; native binaries produced using a normal build system? A quick Google shows that a few other people have had this problem trying to build Subversion with MinGW but it doesn't look like anyone's resolved it. Does anyone know of a successful APR build with MinGW? Curt Arnold has successfully built it using Ant + cpptask as part of the log4cxx project. If you want to take a look, most of the problems have been addressed in this patch: http://zeroj.hda0.net/apr-win32-20050713.patch There may be win32 problems in these changes because the tests do not build using the libtool approach. Here is the log. $ make test (cd test make check OSDIR=/d/workpits/apr-mingw/include/arch/win32 ) make[1]: Entering directory `/d/workpits/apr-mingw/test' /bin/sh ./libtool --silent --mode=compile gcc -g -O2 -DHAVE_CONFIG_H -I../include -I./../include -I/d/workpits/apr-mingw/include/arch/win32 -o testlockperf.lo -c testlockperf.c touch testlockperf.lo /bin/sh ./libtool --silent --mode=link gcc -g -O2 -DHAVE_CONFIG_H -I../include -I./../include -I/d/workpits/apr-mingw/include/arch/win32 -no-install -Wl,--enable-auto-import,--subsystem,console -o testlockperf.exe testlockperf.lo ../libapr.la-lrpcrt4 -lws2_32 -ladvapi32 -lshell32 -lkernel32 -lmsvcrt fu01.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu02.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu03.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu04.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu05.o(.idata$3+0xc): undefined reference to `libmsvcrt_a_iname' fu06.o(.idata$3+0xc): more undefined references to `libmsvcrt_a_iname' follow nmth00.o(.idata$4+0x0): undefined reference to `_nm___pctype' make[1]: *** [testlockperf.exe] Error 1 make[1]: Leaving directory `/d/workpits/apr-mingw/test' make: *** [check] Error 2 I am working on removing the libtool dependance in order that a native dll is created and used. Thanks, Dan Cheers, John
