Re: APR 1.0.0 and CYGWIN
William A. Rowe, Jr. wrote: I should have added that the pseudo-fork and condition vars on cygwin would actually be better preserved by using the unix port. In fact, if the cygwin build simply used the win32 apr_file_io code I'd be quite happy with it relying on the other (unambiguous) features of the cygwin API. Using the win32 apr file_io code on cygwin is impossible. Cygwin provides a mapping of posix-like paths to windows paths. If you use the win32 API, you essentially cut cygwin out of the loop, breaking the translation of those pathnames. Max.
APR 1.0.0 and CYGWIN
I was unable to build ARP-1.0.0 on CYGWIN. I get the following error: $ makemake[1]: Entering directory `/cygdrive/y/spryware/apr/apr-1.0.0'/bin/bash /cygdrive/y/spryware/apr/apr-1.0.0/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DCYGWIN -I./include -I/cygdrive/y/spryware/apr/apr-1.0.0/include/arch/unix -I./include/arch/unix -I/cygdrive/y/spryware/apr/apr-1.0.0/include -o network_io/unix/sockopt.lo -c network_io/unix/sockopt.c touch network_io/unix/sockopt.lonetwork_io/unix/sockopt.c: In function `apr_socket_opt_set':network_io/unix/sockopt.c:135: error: `ttllevel' undeclared (first use in this function)network_io/unix/sockopt.c:135: error: (Each undeclared identifier is reported only oncenetwork_io/unix/sockopt.c:135: error: for each function it appears in.)network_io/unix/sockopt.c:136: error: `ttl' undeclared (first use in this function)make[1]: *** [network_io/unix/sockopt.lo] Error 1make[1]: Leaving directory `/cygdrive/y/spryware/apr/apr-1.0.0'make: *** [all-recursive] Error 1 Daniel May
Re: APR 1.0.0 and CYGWIN
Daniel, we really shouldn't be building unix/ on cygwin. In spite of the built-in support, it simply hasn't been vetted and is bound to have vulnerabilities if used for Apache 2.0. Ideally we should modify the configure.in for cygwin to determine win32/ as the build sources, and toggle -DWIN32. There are probably other side effects, but I'd be happy to help you work through them if you would like to help us put together a patch. In many cases (see the file lists in the .dsp win32 build files) we zig-zag between win32/ and unix/ in the same tree, and need to see how to do so effectively for cygwin. If we do this right, the same sources should build on both cygwin and mingw. Bill At 02:17 PM 10/14/2004, Daniel May wrote: I was unable to build ARP-1.0.0 on CYGWIN. I get the following error: $ make make[1]: Entering directory `/cygdrive/y/spryware/apr/apr-1.0.0' /bin/bash /cygdrive/y/spryware/apr/apr-1.0.0/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CON FIG_H -DCYGWIN -I./include -I/cygdrive/y/spryware/apr/apr-1.0.0/include/arch/unix -I./include/arch /unix -I/cygdrive/y/spryware/apr/apr-1.0.0/include -o network_io/unix/sockopt.lo -c network_io/unix /sockopt.c touch network_io/unix/sockopt.lo network_io/unix/sockopt.c: In function `apr_socket_opt_set': network_io/unix/sockopt.c:135: error: `ttllevel' undeclared (first use in this function) network_io/unix/sockopt.c:135: error: (Each undeclared identifier is reported only once network_io/unix/sockopt.c:135: error: for each function it appears in.) network_io/unix/sockopt.c:136: error: `ttl' undeclared (first use in this function) make[1]: *** [network_io/unix/sockopt.lo] Error 1 make[1]: Leaving directory `/cygdrive/y/spryware/apr/apr-1.0.0' make: *** [all-recursive] Error 1 Daniel May
Re: APR 1.0.0 and CYGWIN
William A. Rowe, Jr. wrote: Daniel, we really shouldn't be building unix/ on cygwin. In spite of the built-in support, it simply hasn't been vetted and is bound to have vulnerabilities if used for Apache 2.0. Ideally we should modify the configure.in for cygwin to determine win32/ as the build sources, and toggle -DWIN32. There are probably other side effects, but I'd be happy to help you work through them if you would like to help us put together a patch. In many cases (see the file lists in the .dsp win32 build files) we zig-zag between win32/ and unix/ in the same tree, and need to see how to do so effectively for cygwin. If we do this right, the same sources should build on both cygwin and mingw. Please please discuss this on the cygwin mailing lists before going down this course. Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. Max.
Re: APR 1.0.0 and CYGWIN
At 04:47 PM 10/14/2004, Max Bowsher wrote: Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. If cygwin used the unambiguous POSIX file flags and had close to 100% compatibility with a unix filesystem (no pathname ambiguity, case sensitive file names, valid filename characters of \ : etc) then there would be little concern for security, and it would be very rational to go with the unix flavor port.
Re: APR 1.0.0 and CYGWIN
I should have added that the pseudo-fork and condition vars on cygwin would actually be better preserved by using the unix port. In fact, if the cygwin build simply used the win32 apr_file_io code I'd be quite happy with it relying on the other (unambiguous) features of the cygwin API. Bill At 04:47 PM 10/14/2004, Max Bowsher wrote: Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. If cygwin used the unambiguous POSIX file flags and had close to 100% compatibility with a unix filesystem (no pathname ambiguity, case sensitive file names, valid filename characters of \ : etc) then there would be little concern for security, and it would be very rational to go with the unix flavor port.
