Bug 10060 - 2.9.90 configure still does not figure out i686 (Pentium i686) without --with-cpu=
Summary: 2.9.90 configure still does not figure out i686 (Pentium i686) without --with...
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: build (show other bugs)
Version: 2.8
: P2 enhancement
Target Milestone: ---
Assignee: Carlos O'Donell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-11 04:57 UTC by Jason Vas Dias
Modified: 2014-07-01 07:20 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Vas Dias 2009-04-11 04:57:52 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 ?
Comment 1 Ulrich Drepper 2009-04-11 05:11:03 UTC
Configuring works.  You have to provide all necessary information.  There will
be now change.
Comment 2 Jason Vas Dias 2009-04-11 08:22:23 UTC
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.





Comment 3 Ulrich Drepper 2009-04-11 08:55:33 UTC

*** This bug has been marked as a duplicate of 333 ***
Comment 4 Jason Vas Dias 2009-04-11 11:52:32 UTC
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

Comment 5 Jason Vas Dias 2009-04-12 22:20:13 UTC
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  
Comment 6 Sergei Steshenko 2009-05-27 16:07:40 UTC
(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.
Comment 7 Carlos O'Donell 2013-04-06 15:40:31 UTC
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).
Comment 8 Carlos O'Donell 2013-04-06 16:31:26 UTC
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.