Thu Nov 3 12:25:34 UTC 2011 (revision 180821) This is a regression from 4.6. This failure is from the autoconf probe in RTEMS looking for scandir(). It fails because of a linking error. I think this is because sparc/t-softmul is not in the tmake_file list in libgcc/config.host. Does it sound right? RTEMS is always cross compiled and sparc-rtems* is always (for now) v7 and v8 sparc. configure:5128: sparc-rtems4.11-gcc --pipe -o conftest -g -O2 -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs conftest.c >&5 conftest.c:49:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] conftest.c:58:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] /users/joel/test-gcc/install-svn/lib/gcc/sparc-rtems4.11/4.7.0/../../../../sparc-rtems4.11/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010074 /users/joel/test-gcc/install-svn/lib/gcc/sparc-rtems4.11/4.7.0/../../../../sparc-rtems4.11/lib/libg.a(lib_a-qsort.o): In function `qsort': /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:160: undefined reference to `.umul' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:208: undefined reference to `.umul' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:214: undefined reference to `.udiv' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:218: undefined reference to `.udiv' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:163: undefined reference to `.umul' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:165: undefined reference to `.umul' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:201: undefined reference to `.umul' /users/joel/test-gcc/gcc-svn/newlib/libc/search/qsort.c:154: undefined reference to `.umul' /users/joel/test-gcc/install-svn/lib/gcc/sparc-rtems4.11/4.7.0/libgcc.a(_divdi3.o): In function `__udivmoddi4': /users/joel/test-gcc/gcc-svn/libgcc/libgcc2.c:935: undefined reference to `.udiv'
Created attachment 25710 [details] Proposed solution With this change, the RTEMS configure process finished and RTEMS is currently building
Can you multiarch a 64-bit sparc build from 32-bit rtems? Probably not... but if that were possible you'd need to check host_address like we do for Linux. So, change looks fine as-is to me, feel free to commit. Thanks.
Author: joel Date: Fri Nov 4 12:57:40 2011 New Revision: 180946 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180946 Log: 2011-11-04 Joel Sherrill <joel.sherrill@oarcorp.com> PR target/50989 * config.host (sparc-*-rtems*): Add sparc/t-softmul. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config.host
(In reply to comment #2) > Can you multiarch a 64-bit sparc build from 32-bit rtems? > Probably not... but if that were possible you'd need to > check host_address like we do for Linux. I think we are OK without any detection logic. We are not self-hosted and we have a separate sparc64-rtems for use with the 64 bit SPARC targets. From our perspective, the sparc-rtems target is really only for the ERC32 and LEON variants. > So, change looks fine as-is to me, feel free to commit. > > Thanks. Committed and closing. Thank you.