glibc/sysdeps/i386/configure.ac

57 lines
2.2 KiB
Plaintext
Raw Normal View History

GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
# Local configure fragment for sysdeps/i386.
# We no longer support i386 since it lacks the atomic instructions
# required to implement NPTL threading.
if test "$config_machine" = i386; then
AC_MSG_ERROR([
*** ERROR: Support for i386 is deprecated.
*** Please use host i786, i686, i585 or i486.
*** For example: /src/glibc/configure --host=i686-pc-linux-gnu ..."])
fi
i386: Fail at configure time for i386 builds. This change does two things: * Treats a target i386-* as if it were i686. * Fails configure if the user is generating code for i386. We no longer support i386 code-generation because the i386 lacks the atomic operations we need in glibc. You can still configure for i386-*, but you get i686 code. You can't build with --march=i386, --mtune=i386 or a compiler that defaults to i386 code-generation. I've added two i386 entries in the master todo list to discuss merging and renaming: http://sourceware.org/glibc/wiki/Development_Todo/Master#i386 The failure modes are fail-safe here. You compile for i386, get i686, and try to run on i386 and it fails. The configure log has a warning saying we elided to i686. There is no situation that I can see where we run into any serious problems. The patch makes the current state better in that we get less confused users and we build successfully in more default configurations. The next enhancement would be to add --march=i?86 as suggested in #c20 of BZ#10062 for any i?86-* builds, which would solve the problem of a 32-bit compiler that defaults to i386 code-gen and glibc configured for i686-* target. Which previously failed at build time, and now will fail at configure time (requires adding --march=i686). Updated NEWS with BZ #10060 and #10062. No regressions. --- 2013-04-06 Carlos O'Donell <carlos@redhat.com> [BZ #10060, #10062] * aclocal.m4 (LIBC_COMPILER_BUILTIN_INLINED): New macro. * sysdeps/i386/configure.in: Use LIBC_COMPILER_BUILTIN_INLINED and fail configure if __sync_val_compare_and_swap is not inlined. * sysdeps/i386/configure: Regenerate. * configure.in: Build for i686 when configured for i386. * configure: Regenerate. * README: Remove i386 reference.
2013-04-06 16:00:35 +00:00
# The GNU C Library can't be built for i386. There are several reasons for
# this restriction. The primary reason is that i386 lacks the atomic
# operations required to support the current NPTL implementation. While it is
# possible that such atomic operations could be emulated in the kernel to date
# no such work has been done to enable this. Even with NPTL disabled you still
# have no atomic.h implementation. Given the declining use of i386 we disable
# support for building with `-march=i386' or `-mcpu=i386.' We don't explicitly
# check for i386, instead we make sure the compiler has support for inlining
# the builtin __sync_val_compare_and_swap. If it does then we should have no
# problem building for i386.
LIBC_COMPILER_BUILTIN_INLINED(
[__sync_val_compare_and_swap],
[int a, b, c; __sync_val_compare_and_swap (&a, b, c);],
[-O0],
[libc_cv_unsupported_i386=no],
[AC_MSG_ERROR([
*** Building with -march=i386/-mcpu=i386 is not supported.
*** Please use host i786, i686, i586, or i486.
*** For example: /source/glibc/configure CFLAGS='-O2 -march=i686' ...])])
i386: Fail at configure time for i386 builds. This change does two things: * Treats a target i386-* as if it were i686. * Fails configure if the user is generating code for i386. We no longer support i386 code-generation because the i386 lacks the atomic operations we need in glibc. You can still configure for i386-*, but you get i686 code. You can't build with --march=i386, --mtune=i386 or a compiler that defaults to i386 code-generation. I've added two i386 entries in the master todo list to discuss merging and renaming: http://sourceware.org/glibc/wiki/Development_Todo/Master#i386 The failure modes are fail-safe here. You compile for i386, get i686, and try to run on i386 and it fails. The configure log has a warning saying we elided to i686. There is no situation that I can see where we run into any serious problems. The patch makes the current state better in that we get less confused users and we build successfully in more default configurations. The next enhancement would be to add --march=i?86 as suggested in #c20 of BZ#10062 for any i?86-* builds, which would solve the problem of a 32-bit compiler that defaults to i386 code-gen and glibc configured for i686-* target. Which previously failed at build time, and now will fail at configure time (requires adding --march=i686). Updated NEWS with BZ #10060 and #10062. No regressions. --- 2013-04-06 Carlos O'Donell <carlos@redhat.com> [BZ #10060, #10062] * aclocal.m4 (LIBC_COMPILER_BUILTIN_INLINED): New macro. * sysdeps/i386/configure.in: Use LIBC_COMPILER_BUILTIN_INLINED and fail configure if __sync_val_compare_and_swap is not inlined. * sysdeps/i386/configure: Regenerate. * configure.in: Build for i686 when configured for i386. * configure: Regenerate. * README: Remove i386 reference.
2013-04-06 16:00:35 +00:00
dnl Check whether asm supports Intel MPX
AC_CACHE_CHECK(for Intel MPX support, libc_cv_asm_mpx, [dnl
cat > conftest.s <<\EOF
bndmov %bnd0,(%esp)
EOF
if AC_TRY_COMMAND(${CC-cc} -c $ASFLAGS conftest.s 1>&AS_MESSAGE_LOG_FD); then
libc_cv_asm_mpx=yes
else
libc_cv_asm_mpx=no
fi
rm -f conftest*])
if test $libc_cv_asm_mpx = yes; then
AC_DEFINE(HAVE_MPX_SUPPORT)
fi
dnl It is always possible to access static and hidden symbols in an
dnl position independent way.
AC_DEFINE(PI_STATIC_AND_HIDDEN)
dnl When multi-arch is enabled, all external functions must be called
dnl via PIC PLT in PIE, which requires setting up EBX register.
if test x"$multi_arch" != xno; then
AC_DEFINE(NO_HIDDEN_EXTERN_FUNC_IN_PIE)
fi