-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ralf Wildenhues wrote:
> Hi John,
>
> * John Calcote wrote on Mon, Jun 23, 2008 at 08:26:09PM CEST:
>> Is there a community-approved method for determining in configure.ac
>> whether or not you're building (targeting) 64-bit code?
>
> What is 64-bit code, and why do you need to know in your program?
>
> Both are serious questions, and LONG_MAX/ULONG_MAX, CHAR_BIT and
> AC_CHECK_SIZEOF for int, long, or a pointer type, may be part of
> the answer to your question. Of course, many programs don't need
> to know or check for any of this at all and are still portable to
> "64-bit" systems, or even systems with 48 bit types, which is Good.
>
> Checking $host is likely not what you would want, as for
> ./configure CC='gcc -m32'
>
> on x86_64-unknown-linux-gnu, it may match.
>
> Cheers,
> Ralf
>
Wow, right you are. I didn't even think to check why I needed it.
You see, I'm porting a huge database project to Autotools from an ugly
GNU makefile based build system. The old makefiles used various system
checks, such as uname, etc to determine the native platform word size.
It then allowed the user to specifically target (via a particular phony
make target) 32-bit binaries, even if the host is a 64-bit platform. The
correct way to do this is, of course, as you mentioned:
$ ./configure CXX='g++ -m32' ...
In response to your "why" question, I grep'ed the source for instances
of FLM_64BIT (the project's own "64-bit target" macro, set based on
system query mentioned above). In nearly every case, I found one of
three situations:
1. The code was poorly written, and didn't really need to check.
2. The code was debug code, such as an internal debug memory manager, or
stack-walking code, that needed to determine the native word - basically
a special case of (1) above.
3. The code was particular to MS Windows. In these situations, it's
pretty clear that MS doesn't care about portable code.
Here are a few examples from the source:
[Win] - - - - - - - - - - - - - - - -
#if !defined(FLM_UNIX) && !defined( FLM_64BIT)
#pragma pack(pop)
#endif
[Win] - - - - - - - - - - - - - - - -
#ifdef FLM_64BIT
machineType = IMAGE_FILE_MACHINE_IA64;
#else
machineType = IMAGE_FILE_MACHINE_I386;
#endif
[Poorly Written] - - - - - - - - - -
#if defined( FLM_WIN) && defined( FLM_64BIT)
f_sprintf(pszTmp, "Unfreed Pointer: 0x%016I64x\r\n",
(FLMUINT)(&pHdr [1]));
#else
f_sprintf(pszTmp, "Unfreed Pointer: 0x%08x\r\n",
(unsigned)((FLMUINT)(&pHdr [1])));
#endif
[Win] - - - - - - - - - - - - - - - -
#ifdef FLM_64BIT
DWORD64 udDisplacement;
#else
DWORD udDisplacement;
#endif
[Poorly Written] - - - - - - - - - -
#if defined( FLM_64BIT) || defined( FLM_OSX) || \
defined( FLM_S390) || defined( FLM_HPUX) || \
defined( FLM_AIX)
typedef unsigned long FLMSIZET;
#else
typedef unsigned FLMSIZET;
#endif
[Poorly Written] - - - - - - - - - -
#if !defined( FLM_UNIX) && !defined( FLM_64BIT)
#define FLM_PACK_STRUCTS
#endif
[Poorly Written] - - - - - - - - - -
#if defined( FLM_X86) && defined( FLM_64BIT)
unsigned long ftkGetMMXSupported( void)
{
return( 1);
}
#endif
- - - - - - - - - - - - - - - - - - - -
The code also goes to great lengths to self-determine the platform
native word size based on various pre-defined preprocessor definitions,
such as __arch64__, _WIN64, _s390x_, __ia64__, etc.
In retrospect, the best thing to have done in my configure.ac file here
was to simply "punt" -- that is, I probably should just ignore the
issue, allow the code base to self-determine, as it's currently doing,
and not allow the user to specify any sort of "force 32-bit" configure
argument, but rather just allow them to configure their compiler
variable to compile 32-bit code (eg., CXX='g++ -m32').
Thanks for the feed back. Any additional comments are very welcome. :)
Regards,
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIYADfdcgqmRY/OH8RAmEqAKCI4q8+KL+hFjACGEhkdZaHop8heQCfeBHf
UnfGWg8VICbK51WUmZPWTP0=
=ekdW
-----END PGP SIGNATURE-----
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
