From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 2 18:47:43 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FEE106564A for ; Tue, 2 Nov 2010 18:47:43 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5867E8FC0A for ; Tue, 2 Nov 2010 18:47:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:88e2:8a04:2da6:ead5] (unknown [IPv6:2001:7b8:3a7:0:88e2:8a04:2da6:ead5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6F2195C5A for ; Tue, 2 Nov 2010 19:47:42 +0100 (CET) Message-ID: <4CD05CD9.7000606@andric.com> Date: Tue, 02 Nov 2010 19:47:53 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101016 Lanikai/3.1.6pre MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Please test the binutils-2.17 project branch X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 18:47:43 -0000 Hi all, As you may know, I am working on an update of our in-tree binutils to 2.17.50, the last version that was still under version 2 of the GPL. I have put this in a project branch, which you can checkout from: svn://svn.freebsd.org/base/projects/binutils-2.17 Please try building world and kernel from this tree, and if the machine in question is expendable (!) installing them. If you see any clearly binutils-related issues, you can reply to this list, or mail me directly if you prefer. Currently, a make universe of the binutils-2.17 project tree builds to completion for the following arches: - amd64 run-time tested by me - i386 run-time tested by me - mips needs run-time testing - pc98 needs run-time testing - powerpc run-time tested by nwhitehorn - sparc64 needs run-time testing - sun4v needs run-time testing The following arches still have building problems: - arm There is some weird issue that causes the cross-tools ld to segfault during buildworld, when linking a binary blob into a .o file: ===> usr.sbin/uathload (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /home/dim/src/freebsd/binutils-2.17/usr.sbin/uathload/uathload.c gzip -cn /home/dim/src/freebsd/binutils-2.17/usr.sbin/uathload/uathload.8 > uathload.8.gz ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin Segmentation fault (core dumped) I am investigating this now, any hints welcome. :) - ia64 Something in sys/boot/ia64/efi/ldscript.ia64 makes ld complain about mixing ordered and unordered sections: ===> sys/boot/ia64/efi (all) ... /usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: .data has both ordered [`.IA_64.unwind' in efimd.o] and unordered [`.IA_64.unwind_info' in /usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/lib/libstand.a(strlen.o)] sections /usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: final link failed: Bad value I am not sure if this is a bug in binutils, or something in the linker script. My ia64 knowledge is extremely limited, though... 2 bad arches against 7 good ones isn't a bad score, but I would like to make sure all of them at least build without any issues, before even thinking of merging this into head. So please help out if you can. Last but not least, be sure to build some ports when the new binutils are installed in the base system. There are always some nasty ones out there that test for specific versions of GNU tools, and die when their expectations are not met. :)