First note, there is an error I uncovered in apr-iconv-1.2.1's generated dll .mak file, so an -r2 is on it's way.
Secondly, the sqlite3, oracle and pgsql binaries do build, against the current official binaries. Which modules may we distribute under the AL from w.a.o/dist/apr/binaries/win32/? (I have no plan to distribute the binary of the client itself, only the apr_dbd_*-1.dll's bound to them). There is no distributed sqlite2 binary that I can find, and I presume that supporting it would be silly. The MySQL connector which I believe we can't ship also will not build; apr_dbd_mysql.c(142) : warning C4244: 'function' : conversion from '__int64 ' to 'unsigned long ', possible loss of data apr_dbd_mysql.c(256) : warning C4018: '>=' : signed/unsigned mismatch apr_dbd_mysql.c(416) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data apr_dbd_mysql.c(486) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data apr_dbd_mysql.c(536) : warning C4244: '=' : conversion from 'unsigned __int64 ' to 'int ', possible loss of data apr_dbd_mysql.c(642) : warning C4244: '=' : conversion from 'unsigned __int64 ' to 'int ', possible loss of data apr_dbd_mysql.c(868) : error C2632: 'long' followed by 'long' is illegal apr_dbd_mysql.c(872) : error C2632: 'long' followed by 'long' is illegal apr_dbd_mysql.c(873) : error C2632: 'long' followed by 'long' is illegal apr_dbd_mysql.c(873) : warning C4244: '=' : conversion from '__int64 ' to 'long ', possible loss of data apr_dbd_mysql.c(879) : error C2632: 'long' followed by 'long' is illegal apr_dbd_mysql.c(883) : error C2632: 'long' followed by 'long' is illegal apr_dbd_mysql.c(884) : error C2632: 'long' followed by 'long' is illegal apr_dbd_mysql.c(884) : warning C4244: '=' : conversion from 'unsigned __int64 ' to 'unsigned long ', possible loss of data Bottom line, "long long" is just not portable. What's up with that? FreeTDS also does not build (had to compile this m'self as there are no official binaries); apr_dbd_freetds.c(42) : fatal error C1083: Cannot open include file: 'regex.h': No such file or directory Now, we have a well supported pcre implementation that we already trust; why is this still using regex by default? Feels very apache1.3 to me :) Otherwise, posted up the build log for your amusement. http://apr.apache.org/dev/dist/build-win32-results.log Of these, the failures map to... testipsub 5 1 20.00% testsock 7 1 14.29% I'm running with the IPv6 stack installed and compiled in, but no configured IPv6 adapter (very similar to other reports this weekend :-) testpass 4 2 50.00% no crypt() support for win32. testxlate 1 1 100.00% apr-iconv exhibits strange "end of shift-state" behavior for utf-7 That's the story. Vote forthcoming. Bill
