diff options
| author | Jeff Morriss <jeff.morriss@ulticom.com> | 2012-05-04 21:56:32 +0000 |
|---|---|---|
| committer | Jeff Morriss <jeff.morriss@ulticom.com> | 2012-05-04 21:56:32 +0000 |
| commit | 06bb1678241c2cd4094f99f77ac3bdb85a46e59a (patch) | |
| tree | 882fdb688b8145fef7789a8c85b71505f5639ff8 /configure.in | |
| parent | d1566f00a29b8f4db3aae925be825c065e53e6a2 (diff) | |
| download | wireshark-06bb1678241c2cd4094f99f77ac3bdb85a46e59a.tar.gz | |
The rest of the fix for https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7221
(emem alignment problems on SPARC) :
Have emem use 8-byte alignment when we need it.
Since I can't seem to write code that which reliably (across GCC versions and
optimization levels) determines if 8-byte alignment is needed for doubles,
"when" is defined as "if we're compiling for a CPU other than i386."
Windows doesn't need a check because it's either i386 or 64-bit (x86_64 or
maybe ia64--both of which get 8-byte alignment from G_MEM_ALIGN).
(And, yes, all of this is ignoring the 16-byte alignment requirements of long
doubles.)
svn path=/trunk/; revision=42431
Diffstat (limited to 'configure.in')
| -rw-r--r-- | configure.in | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/configure.in b/configure.in index a71026dc41..85e79e9638 100644 --- a/configure.in +++ b/configure.in @@ -1911,6 +1911,22 @@ CPPFLAGS="$CPPFLAGS '-DPLUGIN_DIR=\"\$(plugindir)\"'" PLUGIN_LIBS="" AC_SUBST(PLUGIN_LIBS) +# +# Check if (emem) memory allocations must be 8-byte aligned. +# I haven't been able to write C code that reliably makes that determination +# (different versions of GCC with or without optimization give different +# results) so just assume everything except (32-bit) x86 needs 8-byte +# alignment (64-bit x86 will get 8-byte alignment from G_MEM_ALIGN anyway). +# +AC_MSG_CHECKING(whether we need memory allocations to be 8-byte aligned) +if test x$host_cpu != xi386 +then + AC_MSG_RESULT(yes) + AC_DEFINE(NEED_8_BYTE_ALIGNMENT, 1, [Define if we need memory allocations to be 8-byte aligned]) +else + AC_MSG_RESULT(no) +fi + dnl libtool defs # # Yes, AM_PROG_LIBTOOL is redundant with newer version(s) of some tool(s) |