/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crti.S: Assembler messages: /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crti.S:24: Error: Architecture mismatch on "be,pn %icc,.LL3". /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crti.S:24: (Requires v9|v9a|v9b; requested architecture is sparclite.) /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crti.S:30: Error: Architecture mismatch on "return". /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crti.S:30: (Requires v9|v9a|v9b; requested architecture is sparclite.) make[2]: *** [/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crti.o] Error 1 make[2]: *** Waiting for unfinished jobs.... /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crtn.S: Assembler messages: /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crtn.S:9: Error: Architecture mismatch on "return". /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crtn.S:9: (Requires v9|v9a|v9b; requested architecture is sparclite.) /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crtn.S:17: Error: Architecture mismatch on "return". /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crtn.S:17: (Requires v9|v9a|v9b; requested architecture is sparclite.) make[2]: *** [/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/csu/crtn.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/csu' make[1]: *** [csu/subdir_lib] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5' make: *** [all] Error 2 !!! ERROR: The ebuild did not complete successfully. !!! Function src_compile, Line 129, Exitcode 2 !!! (no error message) CFLAGS="-O2 -pipe -mcpu=v9" Will try again without this option
well, now without -mcpu=v9 it seems to be a little happier... but I stopped the build as I saw reference to a lot of sparc32 options... example: gcc gconv_trans.c -c -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -pipe -fPIC -I../include -I. -I/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/iconv -I.. -I../libio -I/var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere -I../sysdeps/sparc/sparc32/elf -I../linuxthreads/sysdeps/unix/sysv/linux/sparc -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/sparc/sparc32 -I../linuxthreads/sysdeps/sparc -I../sysdeps/unix/sysv/linux/sparc/sparc32 -I../sysdeps/unix/sysv/linux/sparc -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/sparc -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/sparc/sparc32/fpu -I../sysdeps/sparc/sparc32 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/sparc/sparc32/soft-fp -I../sysdeps/sparc/fpu -I../sysdeps/sparc -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -o /var/tmp/portage/glibc-2.2.5-r6/work/glibc-2.2.5/buildhere/iconv/gconv_trans.os Is this correct behaviour for sparc64 machine? I am a bit confused on this and didn't want to take the chance of destroying the system by installing an incorrect glibc. Any advice would be appreciated
Gerk, try building with -mcpu=v8 -mtune=v9 the -mtune=v9 will get you some extra optimizations over using -mcpu=v8 alone, I build my whole machines with -mcpu=v8 -mtune=v9 no problems. (I always find trouble when I start playing with -mcpu=v9 though. :) ) -mcpu=uptrasparc fails for me as well FWIW, and with exactly the same message shown in this bug according to the docs, ultrasparc should be a synonym for v9 in gcc 3.2 so perhaps it's a glibc bug?
yes I would think that glibc is not making proper distinctions it all worked ok with mcpu=v8 mtune=v9 might be something worth further investigation
I also ran into this glitch, when trying to bootstrap glibc on my sun blade 100 (I submitted a bug as well: http://bugs.gentoo.org/show_bug.cgi?id=7567). I'm guessing it is a glibc glitch, even though I do not know that much about how glibc puts itself together. I think one of the reasons it references sparc32 information alot is to build itself in 32-bit userland, whereas accessing sparc64 might be taken as 64-bit. Not too sure, I'm new to all this linux/sparc64 stuff. Kumba
reason is it's building with 64bit on a 32bit userland.
