Sources Bugzilla – Bug 10060
2.9.90 configure still does not figure out i686 (Pentium i686) without --with-cpu=
Last modified: 2013-04-06 16:31:26 UTC
Having consistently got this behaviour when building i686-pc-gnu-linux under x86_64-pc-gnu-linux ( Gentoo and Fedora 10 both ) , without any third-party "Linux distribution" patches, I've been trying to find a simple patch to reliably fix this problem, so I actually mounted over NFS the latest CVS snapshot from : $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc co libc and then mounted it with a genuine i686 host ( Fedora Core 6 ) and got exactly the same set of errors as when attempting to build in 32-bit i686 mode on x86_64, when building natively on i686 FC-6; so it really cannot be any sort of environment gcc / binutils problem at all, since the same problem occurs on FC-6 : $ gcc --version Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20070626 (Red Hat 4.1.2-13) : $ ld --version GNU ld version 2.17.50.0.6-5.fc6 20061020 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. As under: $ gcc --version; ld --version gcc (Linux 2.6.29 GCC 4.3.3 JVD 2009-02-24) 4.3.4 20090223 (prerelease) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU ld (GNU Binutils) 2.19.51.20090319 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. (ie latest gcc 4.3.x 4.4.x and binutils on an x86_64 ). The problem for both builds was simply that some parts of the code refuse to auto-determine a "pentium" default CPU and enable "i686" gcc TLS, either under $ uname -a; cat /etc/fedora-release Linux jvdsibm 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 15:12:59 EST 2007 i686 i686 i386 GNU/Linux Fedora Core release 6 (Zod) or under: $ uname -a; cat /etc/gentoo-release Linux jvdspc 2.6.29-rc8-tip-jvd #2 SMP Thu Apr 9 12:44:15 EDT 2009 x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-64 AuthenticAMD GNU/Linux Gentoo Base System release 1.12.12 or under: $ uname -a; cat /etc/fedora-release Linux jvdspc 2.6.29-rc8-tip-jvd #2 SMP Thu Apr 9 12:44:15 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Fedora release 10 (Cambridge) GLIBC configure line : $ ../configure --prefix=/usr --libdir=/usr/lib32 --sysconfdir=/usr/etc/32 --sharedstatedir=/usr/var/32 --datarootdir=/usr/share/32 --enable-shared --enable-tls --enable-threads=posix Yes, I want those weird */32 directories; I'm trying to build, eventually, for a x86_64 i386 mode glibc. But first just get it to build with those configure args on ANY i686 ! - (I'd rather not convert my ancient and slow i686 laptop to FC8/10 - it's happy with FC-6 and so am I - but why can't it use the above configure args and build glibc ? ). These errors appear in the make.log with the above configure arguments : $ make 2>&1 | tee make.log || grep 'sync_fetch_and_add' make.log ... /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_getpw_r.c:232: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_getgr_r.c:321: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os:/jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_gethst_r.c:413: more undefined references to `__sync_fetch_and_add_4' follow I think these will go away if I rebuild from scratch with some --with-cpu=i686 or similar argument, no ? So why can't glibc determine the correct TLS model to use when given "--enable-tls" and "build=i686-*" and when uname -m == 'i686' and its actually running on a genuine i686 ? Why MUST I use a --with-cpu argument when the above is the case ?
Configuring works. You have to provide all necessary information. There will be now change.
After having rebuilt after configuration with "--with-cpu=i686" on the FC-6 i686, I still get these missing symbols: /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `fallocate': /jvdspc/jvdsibm/glibc-2.90.9/libc/io/../sysdeps/unix/sysv/linux/i386/fallocate.c:31: undefined reference to `__call_fallocate' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__fallocate64_l64': /jvdspc/jvdsibm/glibc-2.90.9/libc/io/../sysdeps/unix/sysv/linux/i386/fallocate64.c:31: undefined reference to `__call_fallocate' And STILL the wrong TLS model: mv -f /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/shlib.ldsT /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/shlib.lds gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.2 -B/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/csu/ -Wl,--version-script=/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86 -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/math -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/elf -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/dlfcn -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/nss -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/nis -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/rt -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/resolv -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/crypt -L/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/nptl -Wl,-rpath-link=/jvdspc/jvdsibm/glibc-2.90.9/libc/x86:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/math:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/elf:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/dlfcn:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/nss:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/nis:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/rt:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/resolv:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/crypt:/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/nptl -o /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc.so -T /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/shlib.lds /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/csu/abi-note.o /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/elf/soinit.os /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/elf/sofini.os /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/elf/interp.os /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/elf/ld.so -lgcc /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__libc_fork': /jvdspc/jvdsibm/glibc-2.90.9/libc/posix/../nptl/sysdeps/unix/sysv/linux/i386/../fork.c:79: undefined reference to `__sync_bool_compare_and_swap_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `fallocate': /jvdspc/jvdsibm/glibc-2.90.9/libc/io/../sysdeps/unix/sysv/linux/i386/fallocate.c:31: undefined reference to `__call_fallocate' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__fallocate64_l64': /jvdspc/jvdsibm/glibc-2.90.9/libc/io/../sysdeps/unix/sysv/linux/i386/fallocate64.c:31: undefined reference to `__call_fallocate' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__nscd_drop_map_ref': /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `nscd_getpw_r': /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_getpw_r.c:232: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__nscd_drop_map_ref': /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `nscd_getgr_r': /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_getgr_r.c:321: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__nscd_drop_map_ref': /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os:/jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_gethst_r.c:413: more undefined references to `__sync_fetch_and_add_4' follow /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `__nscd_get_map_ref': /jvdspc/jvdsibm/glibc-2.90.9/libc/nscd/nscd_helper.c:431: undefined reference to `__sync_val_compare_and_swap_4' /jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc_pic.os: In function `*__GI___libc_freeres': /jvdspc/jvdsibm/glibc-2.90.9/libc/malloc/set-freeres.c:39: undefined reference to `__sync_bool_compare_and_swap_4' collect2: ld returned 1 exit status make[1]: *** [/jvdspc/jvdsibm/glibc-2.90.9/libc/x86/libc.so] Error 1 make[1]: Leaving directory `/jvdspc/jvdsibm/glibc-2.90.9/libc' make: *** [all] Error 2 I haven't been able to build a pure i386 mode library EXCEPT by patching with either Red Hat or Gentoo patches while the x86_64 arch builds fine without them. Why is this ? Why can't the CVS version simply configure and build with the configure arguments : $ ../configure --prefix=/usr --libdir=/usr/lib32 --sysconfdir=/usr/etc/32 --sharedstatedir=/usr/var/32 --datarootdir=/usr/share/32 --enable-shared --enable-tls --enable-threads=posix --with-cpu=i686 I get the same errors as above with either building i686 on i686 (FC-6) or building i686 under 'setarch i686' on RHEL5 , FC10 or Gentoo . The only workaround I have found is to edit out the TLS references listed above.
*** This bug has been marked as a duplicate of 333 ***
OK, fair enough, you really don't want to discuss configure here - but just for my own records, and to assist others who may have similar problems, I'll document the fixes I find here . First : CFLAGS='-g -O2 -m32 -m96bit-long-double -march=pentium -mtune=generic -pipe' ASFLAGS='-32' LDFLAGS='-melf-i386' ARCH=i686 export CFLAGS ASFLAGS LDFLAGS ARCH ../configure \ --prefix=/usr \ --libdir=/usr/lib/32 \ --sysconfdir=/usr/etc/32 \ --sharedstatedir=/usr/var/32 \ --datarootdir=/usr/share/32 \ --build=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --with-headers=%{_prefix}/include --enable-bind-now \ --with-tls --enable-threads=posix --with-__thread \ --with-cpu=i686
Aha! It GREATLY helps to have the latest binutils installed - part of the problem was that the binutils-2.17.50.0.6-5.fc6 20061020 of FC-6 did not comprehend GLIBC's advanced ld(1) --version-script usage ; another problem was that GLIBC's advanced GCC TLS requires a libgcc from at least gcc-4.2.4 . Couldn't the GLIBC build / configure script say something like : "if [ $GCC_VERSION_NUMBER -le 4.1.0 ]; then use_old_gcc_tls() use_old_ld_version_script() else # do it the current way fi " To suggest the above was all that was intended by reporting this "not-a-bug" bug report - it is really more of the nature of a "request-for-enhancement" and should probably have originally been so . In any case, it really helps to keep track of this issue for my own records - if someone else finds it useful, then all the better. Thanks & Regards, Jason
(In reply to comment #1) > Configuring works. You have to provide all necessary information. There will > be now change. No, this is YOU, Ulrich Drepper, who, first of all, has to provide all the necessary info in the documentation and information, and you don't. glibc-2.10.1 does _not_ build in my environment while under _exactly_ the same environment glibc-2.9 builds OK, and there is no changes in glibc-2.10.1/INSTALL file compared to glibc-2.9/INSTALL one. So it is YOU, Ulrich Drepper, who failed to even mention changes that happened - according to GNU standards the INSTALL file should contain build instructions, and YOU, Ulrich Drepper, have failed to put new requirements into the INSTALL file. Rest assured, I _will_ open another bug report, and now it's a bullet-proof evidence of regression in build mechanism.
Similar to http://sourceware.org/bugzilla/show_bug.cgi?id=10062 We are going to fix this by upgrading i386 builds to i686 builds. That is to say that instead of implying an unsupported i386 build when we determine it's i386, we instead build for i686 (which has the support we need).
Fixed with: commit a01f19c8fb12eef419d4112879bc715e2ab6f6d7 Author: Carlos O'Donell <carlos@redhat.com> Date: Sat Apr 6 12:00:35 2013 -0400 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.