On Dec 17, 2010, at 6:58 AM, Dan Poirier wrote: > 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: >
Hmmm.... I cannot recreate that (at least on the 1.4.x branch). What happens if you just blank out CFLAGS? The default is for universal... > 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 >
