From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5387 invoked by alias); 17 Apr 2012 14:07:53 -0000 Received: (qmail 5366 invoked by uid 22791); 17 Apr 2012 14:07:51 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,TW_CX,TW_IW,TW_MX,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.mvtec.com (HELO mail.mvtec.com) (62.245.183.138) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Apr 2012 14:07:11 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mvtec.com (8.14.4/8.14.4) with ESMTP id q3HE79jh000966 for ; Tue, 17 Apr 2012 16:07:09 +0200 X-Spam-Score: -4.335 Received: from mail.mvtec.com ([127.0.0.1]) by localhost (mail.mvtec.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RjqHyTMT+ZpJ for ; Tue, 17 Apr 2012 16:07:02 +0200 (CEST) Received: from [192.168.32.170] (statler.mvtec [192.168.32.170]) by mail.mvtec.com (8.14.4/8.14.4) with ESMTP id q3HE70P8000955 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 16:07:01 +0200 Message-ID: <4F8D7903.6040208@mvtec.com> Date: Tue, 17 Apr 2012 14:07:00 -0000 From: Eric Doenges User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: crossgcc@sourceware.org Subject: Need a cross compiler for very old PXA270-based system Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00017.txt.bz2 Hi, I have the following problem - a customer wants us to port our software to their existing embedded system, which uses an Intel PXA270 processor and runs an ancient Linux (I think it's 2.6.16). The toolchain used for this system is the 'arm-linux-toolchain-bin-12-15-04-driscoll.tar.gz'. Unfortunately, a bug in gcc-3.4.3 prevents our software from compiling correctly, so I need a newer version of gcc that uses the headers and libraries from the existing toolchain. I also need a newer binutils that will handle --gc-sections correctly. My first attempt was to build gcc-4.3.7 and binutils-2.21.1. I downloaded and unpacked the sources, added symlinks in the gcc source directory to the binutils directory in order to be able to build binutils and gcc together, and then used the following configure options: ../gcc-4.3.6/configure --target=arm-linux --prefix=/home/doenges/opt/pxa270 --with-cpu=iwmmxt --with-arch=iwmmxt --with-abi=iwmmxt --without-fp --with-float=soft --enable-cxx-flags=-mcpu=iwmmxt --with-sysroot=/proj/opt/arm-linux/arm-linux --with-local-prefix=/proj/opt/arm-linux/arm-linux --disable-nls --disable-libmudflap --disable-libssp --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long --disable-multilib This fails during building of libgcc due to __DTORS_LIST__ not being declared. If I change the --target to arm-iwmmxt-linux-gnueabi, it fails while attempting to link libgcc because gcc will generate Version4 EABI objects, while the linker expects the old (pre-EABI) ABI. If I leave out the --with-abi=iwmmxt, it fails much sooner because gcc 4.3.6 refuses to compile for iwmmxt when not using the new ABI. Figuring the ABI problem is inherent to gcc 4.x, I then tried to compile gcc-3.4.6 (again using binutils 2.21.1) using the following configure options: ../gcc-3.4.6/configure --target=arm-linux --prefix=/home/doenges/opt/pxa270 --with-cpu=iwmmxt --with-float=soft --enable-cxx-flags=-mcpu=iwmmxt --with-headers=/proj/opt/arm-linux/arm-linux/include --with-local-prefix=/proj/opt/arm-linux/arm-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long --without-fp This also fails during linking of libgcc with the linker complaining that the object files contain FPA instructions, while the link target does not. Note that the object files don't actually contain any FPA instructions; it seems the problem is that the flags in the ELF headers don't match - objects generated by the compiler have (reported by readelf -h) Flags: 0x200, GNU EABI, software FP while the libraries in the existing toolchain have Flags: 0x602, has entry point, GNU EABI, software FP, VFP I have no idea why readelf thinks these are GNU EABI files, as it reports OS/ABI as 'ARM', with ABI version 0. I then tried compiling gcc-3.4.3 using the same configure options as in the original toolchain (obtained by running arm-linux-gcc -v): ../gcc-3.4.3/configure --target=arm-linux --prefix=/home/doenges/opt/pxa270 --with-cpu=iwmmxt --enable-cxx-flags=-mcpu=iwmmxt --with-headers=/proj/opt/arm-linux/arm-linux/include --with-local-prefix=/proj/opt/arm-linux/arm-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long --without-fp This fails with the same error(s) as gcc 3.4.3, though the object files created by the compiler now have these flags: Flags: 0x0 So, to finally get to the point - does anyone have any idea what I must do to get a working gcc toolchain for the PXA270 using the old ABI ? With kind regards, Eric P.S.: I apologize in advance if this is not the correct mailing list for this question, but after a fruitless day of googling I'm fresh out of ideas and don't really know where else to ask. -- Dr. Eric Dönges doenges@mvtec.com MVTec Software GmbH | Neherstr. 1 | 81675 München | Germany www.mvtec.com | Tel: +49 89 457695-0 | Fax: +49 89 457695-55 Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt Amtsgericht München HRB 114695 -- For unsubscribe information see http://sourceware.org/lists.html#faq