On Thu. 2010-12-16 at 03:35 PM EST, Jim Jagielski <[email protected]> wrote:
> On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote: > >> >> Here is my idea... currently, when looking for sizes >> and formats for off_t, we do from smallest to largest >> (int -> long -> long long). We also do the same when >> checking apr_int64_t as well... >> >> What if we do the reverse? What if instead of finding >> the smallest that is the right size, we find the first, >> starting with the longest? >> >> I'm trying that out now, so we'll see... >> > > hey.... this looks promising! With this, APR and httpd > builds with no "warning ... expect" errors at all, and > passes the test framework, no matter is built forcing 64bit, > 32bit *or universal*! > > Please check over because I hope to commit sometimes > tomorrow!! I think universal is going to take more work. Right now, configure runs little test programs once, either 32-bit or 64-bit, and records the results in apr.h and other places. Those answers can't always be right for both 32-bit and 64-bit. The header files will need to have some conditionals to use the right answers depending on which way the code is being compiled. Other programs obviously manage to do this. Maybe it's simpler than it seems to me. Example: if I build universal (CFLAGS='-arch i386 -arch x86_64'), the compile fails in strings/apr_snprintf.c: strings/apr_snprintf.c: In function ‘conv_os_thread_t’: strings/apr_snprintf.c:500: error: duplicate case value strings/apr_snprintf.c:498: error: previously used here strings/apr_snprintf.c: In function ‘conv_os_thread_t_hex’: strings/apr_snprintf.c:671: error: duplicate case value strings/apr_snprintf.c:669: error: previously used here because sizeof(apr_int32_t) is apparently the same as sizeof(apr_int64_t), which is obviously wrong. Here's apr.h: typedef int apr_int32_t; typedef unsigned int apr_uint32_t; typedef long apr_int64_t; typedef unsigned long apr_uint64_t; (What's interesting is that if I build just 32-bit or just 64-bit, that compile does not fail. I don't know why; maybe the tests that set apr_int32_t and apr_int64_t respond in different ways to universal builds.) But all this is beside the point of the current issue. I think if we can get apr to build & test okay separately, 32-bit or 64-bit, that'll be real worthwhile progress. Universal can wait for another day :-) Dan
