From owner-freebsd-arm@FreeBSD.ORG Sun Dec 14 14:04:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7B12900 for ; Sun, 14 Dec 2014 14:04:06 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71E7ECB3 for ; Sun, 14 Dec 2014 14:04:06 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ex7so6637454wid.12 for ; Sun, 14 Dec 2014 06:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iG2hCbCXXe6Bnsc9Pnd4GFNqH9ELvgzCN+kRJa4ZSLU=; b=sdpVeFN8RStPWUA4JQF6hL4UCkm9uovX3kW/qQU0fC6B/0cZsvZ6FxIWCYKcz4XlV7 DI9DLvnOfEPBEbwo2PiYhXol+ayl+WUtWKKyk/JWvqEG1GxuGZpqGjnPLlNMbNjXYqtR YVcL3nPbBVWfKqd4CM2b1MFr6Kgd68lMfeb7uyaZV0aPlT8eyb48ovmyqftP1i/nrmcR FI8GEabkXl8j4Ohxtippy4qEvUCFYImCjX2qFz6S7cXnMnBNr6LrxLKAi9sSLMO2eL3i xBFCDetN6VhY8X3aYl4Wi11h1NGY41OOeeYErTh/tO9dH0nByyDTobjNAax6J0IFxFYc 2cBQ== X-Received: by 10.194.193.2 with SMTP id hk2mr42847108wjc.40.1418565843875; Sun, 14 Dec 2014 06:04:03 -0800 (PST) Received: from ketas-laptop.mydomain ([2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id nb8sm9506982wic.7.2014.12.14.06.04.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Dec 2014 06:04:02 -0800 (PST) Sender: Sulev-Madis Silber Message-ID: <548D98CE.7030307@hot.ee> Date: Sun, 14 Dec 2014 16:03:58 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?UmVuw6kgTGFkYW4=?= Subject: Re: using GPIO on 10.1-release References: <201412131505.sBDF55IM070058@mech-as221.men.bris.ac.uk> <1772909.5HItWhHBl0@quad> In-Reply-To: X-TagToolbar-Keys: D20141214160356505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 14:04:07 -0000 On 2014-12-13 18:17, René Ladan wrote: > Op 13 dec. 2014 16:23 schreef "Maxim V FIlimonov" : >> >> On Saturday 13 December 2014 07:05:06 Anton Shterenlikht wrote: >>> Hi >>> >>> My son is bugging me to teach him something 'cool' on RPi. >>> I've got 10.1-release working on RPi-B. >>> >>> I've seen some tutorials on using LEDs via >>> GPIO, but those are implemented in python >>> using RPi-GPIO module [1], which doesn't seem to >>> exist on ports. (Or am I looking in the wrong place?) >>> >>> Anyway, what is the easiest way to start on >>> GPIO programming on RPi-B 10.1-release, >>> preferably using what is available via ports >>> already? >>> >> >> Use gpioctl, it's already in the base system. > > Or look at comms/dcf77pi for some examples in C (in the input.c file) Or you can still use https://github.com/gonzoua/freebsd-gpio If you find examples there too "example-ish", I use it like this: http://ketas.si.pri.ee/bbb/bbb-poe-daemon/util/gpio.pl (pin config part needs rewrite to remove gpioctl exec) Well, only if you and / or him likes Perl. There is also new GPIO code somewhere, which supports features like interrupts. I haven't really seen it or tried to get that working (loos@ & rpaulo@ likely know more). I also don't know about RPi, I only have BBB which I can say works well and has lot of features, including some unsupported ones. Curses per some time period seems higher with RPi. Though, it's cheaper device... And you already have it. From owner-freebsd-arm@FreeBSD.ORG Sun Dec 14 16:15:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05C793C6 for ; Sun, 14 Dec 2014 16:15:00 +0000 (UTC) Received: from frontend1.warwick.net (mail.warwick.net [204.255.24.102]) by mx1.freebsd.org (Postfix) with SMTP id 94919EDF for ; Sun, 14 Dec 2014 16:14:58 +0000 (UTC) Received: (qmail 30316 invoked from network); 14 Dec 2014 16:08:16 -0000 Received: from 70.44.113.83.res-cmts.sefg.ptd.net (HELO 70.44.113.83.res-cmts.sefg.ptd.net) (egunther@warwick.net@70.44.113.83) by frontend1.warwick.net with SMTP (69607768-83ab-11e4-b823-001e0b616b8e); Sun, 14 Dec 2014 11:08:16 -0500 Message-ID: <1418573358.24891.1.camel@warwick.net> Subject: Re: Raspberry Pi composite video problem SOLVED From: Eric Gunther To: freebsd-arm@freebsd.org Date: Sun, 14 Dec 2014 11:09:18 -0500 In-Reply-To: <20141129105210.5a72a8ec@X220.alogt.com> References: <1417167767.23507.2.camel@warwick.net> <1417193156.3202.1.camel@warwick.net> <20141129084900.10050d11@X220.alogt.com> <1417229109.1835.2.camel@warwick.net> <20141129105210.5a72a8ec@X220.alogt.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 69607768-83ab-11e4-b823-001e0b616b8e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.83 X-MagicMail-EnvelopeFrom: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:15:00 -0000 ********************** ********* BUT, I have to reiterate, that this is not my issue. I am hoping that someone here could help with the text being mis-formatted or mis-configured for the tv. I have tried /boot/msdos/config.txt Have tried framebuffer settings --- unreadable or still off screen Have tried overscan settings --- no useable change Have not tried firmware FreeBSD-10.1-RELEASE-arm-armv6-RPI-B.img Thanks for any help, --e So I seem to have succeeded in setting the TV resolution right. TV: The size of the screen is 11.25 / 8.5 (inches high/wide). The TV has Video and Audio single RCA jacks in and out. There is also some recessed adjustment screws for "focus" and "screen". Screen changes the brightness. config.txt: ### appears to work 12-14-14 ### framebuffer_width=600 framebuffer_height=500 framebuffer_depth=16 overscan_left=0 overscan_right=0 overscan_top=-10 overscan_bottom=-10 overscan_disable=0 ### above is edit ##### disable_commandline_tags=1 gpu_mem=32 device_tree=rpi.dtb device_tree_address=0x100 kernel=uboot.img Have a good day, -e From owner-freebsd-arm@FreeBSD.ORG Sun Dec 14 21:08:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A629229D for ; Sun, 14 Dec 2014 21:08:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C786F47 for ; Sun, 14 Dec 2014 21:08:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBEL8C1t011632 for ; Sun, 14 Dec 2014 21:08:12 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201412142108.sBEL8C1t011632@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 14 Dec 2014 21:08:12 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 21:08:12 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 195009 | [patch]: [arm] Use 400 kHz as the default OMAP4 I 1 problems total for which you should take action. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 15 15:25:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60AE38C6 for ; Mon, 15 Dec 2014 15:25:22 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DAADC68 for ; Mon, 15 Dec 2014 15:25:22 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBFFPLNS091020 for ; Mon, 15 Dec 2014 15:25:21 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBFFPLxm091019; Mon, 15 Dec 2014 15:25:21 GMT (envelope-from root) Date: Mon, 15 Dec 2014 15:25:21 +0000 To: freebsd-arm@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Request, 4 lines] D1317: Build gperf as a dependency before gcc for arm releases Message-ID: X-Priority: 3 Thread-Topic: D1317: Build gperf as a dependency before gcc for arm releases X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ODU1NjY4YTdmOTUyYWNiMWZkMGQ1ZDNlZjg3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:25:22 -0000 emaste created this revision. emaste added a reviewer: gjb. emaste added a subscriber: freebsd-arm. REVISION SUMMARY Older u-boot versions hardcode the use of a host gcc compiler, and gcc relies on having gperf available so we must build and install it first. REVISION DETAIL https://reviews.freebsd.org/D1317 AFFECTED FILES release/arm/release.sh To: emaste, gjb Cc: freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Mon Dec 15 15:30:56 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F2EAA6D for ; Mon, 15 Dec 2014 15:30:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76F29D39 for ; Mon, 15 Dec 2014 15:30:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBFFUui3075812 for ; Mon, 15 Dec 2014 15:30:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195998] New: arm release builds rely on having a host gcc Date: Mon, 15 Dec 2014 15:30:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:30:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195998 Bug ID: 195998 Summary: arm release builds rely on having a host gcc Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org The ARM release builds require u-boot, and u-boot's build infrastructure (for at least certain versions) is hardcoded to use a host gcc. This is currently handled by explicitly building and installing in gnu/usr.bin/cc but this will not be possible once gcc 4.2.1 is removed from the source tree. I suspect u-boot is just building some basic host tools and it may be possible to just make a symlink cc -> gcc in the chroot for the builds. See also https://reviews.freebsd.org/D1317 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 15 15:36:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 330ECC4D for ; Mon, 15 Dec 2014 15:36:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A756D70 for ; Mon, 15 Dec 2014 15:36:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBFFaDxo010905 for ; Mon, 15 Dec 2014 15:36:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195998] arm release builds rely on having a host gcc Date: Mon, 15 Dec 2014 15:36:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:36:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195998 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian@FreeBSD.org --- Comment #1 from Ian Lepore --- The mechanism for building u-boot for ARM images is transitioning towards ports/packages as the build mechanism. See sysutils/u-boot-beaglebone and other u-boot-* ports. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 15 15:59:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBA37E6E for ; Mon, 15 Dec 2014 15:59:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A803FF51 for ; Mon, 15 Dec 2014 15:59:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sBFFxED1024557 for ; Mon, 15 Dec 2014 15:59:14 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sBFFxE9i024556; Mon, 15 Dec 2014 15:59:14 GMT (envelope-from root) Date: Mon, 15 Dec 2014 15:59:14 +0000 To: freebsd-arm@freebsd.org From: "gjb (Glen Barber)" Subject: [Differential] [Commented On] D1317: Build gperf as a dependency before gcc for arm releases Message-ID: <1af4a7031ffa4195ad4232115bb08b58@localhost.localdomain> X-Priority: 3 Thread-Topic: D1317: Build gperf as a dependency before gcc for arm releases X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ODU1NjY4YTdmOTUyYWNiMWZkMGQ1ZDNlZjg3IFSPBVI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:59:14 -0000 gjb added inline comments. INLINE COMMENTS release/arm/release.sh:133 I've tried this exact change, which sadly does not work. Discussed in IRC with imp@, building gcc(1) should not be necessary with the sysutils/u-boot-* ports. REVISION DETAIL https://reviews.freebsd.org/D1317 To: emaste, gjb Cc: freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Mon Dec 15 23:20:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46830B48 for ; Mon, 15 Dec 2014 23:20:49 +0000 (UTC) Received: from server949-han.de-nserver.de (server949-2-han.de-nserver.de [77.75.250.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3F26B87 for ; Mon, 15 Dec 2014 23:20:47 +0000 (UTC) Received: (qmail 21577 invoked from network); 16 Dec 2014 00:20:34 +0100 X-Fcrdns: Yes Received: from dslb-094-218-030-109.094.218.pools.vodafone-ip.de (HELO [192.168.0.12]) (94.218.30.109) (smtp-auth username konstantin@schukraft.org, mechanism plain) by server949-han.de-nserver.de (qpsmtpd/0.92) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Tue, 16 Dec 2014 00:20:34 +0100 Message-ID: <548F6CB9.7020205@schukraft.org> Date: Tue, 16 Dec 2014 00:20:25 +0100 From: Konstantin Schukraft User-Agent: "" MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Pandaboard: problems with some kernel modules Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-User-Auth: Auth by konstantin@schukraft.org through 94.218.30.109 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:20:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm running 10.1-RELEASE on a Pandaboard as a home server, and while most of it works great, I have some problems with some kernel modules. geom_eli compiles and installs (make and make install) fine, but loading it, no matter whether I use the full path or not, always errors out with "kldload: can't load geom_eli: No such file or directory" although it is there: root@panda:/usr/src/sys/modules/geom/geom_eli # ls /boot/kernel/ fdescfs.ko geom_bde.ko geom_eli.ko geom_label.ko kernel kernel.gz.tramp kernel.symbols linker.hints nullfs.ko procfs.ko The other selfbuild modules you can see here load just fine. opensolaris and zfs can't even be build, both error out with In file included from /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris.c:32: /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/sys/cpuvar.h:53:9: error: 'cpu_id' macro redefined [-Werror] #define cpu_id cpuid ^ ./machine/cpufunc.h:178:9: note: previous definition is here #define cpu_id() cpufuncs.cf_id() ^ 1 error generated. *** Error code 1 Anyone having geli encryption or ZFS working on a Pandaboard? Thanks, Konstantin -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUj2y5AAoJEH3raMNeVmMF2GwQAKH6/OkBCybG4UaeUiPL9dkp Jd/3QoIkBZRPwCugdiiqLMMfis5RMKyVMYWC1lzz2z/PyK/nCtJPAe+X28lWEv4i NJxNQcLhOjp6n3vfJ83G+NdBLn0nLv0Tcx9grjNh83FF1koR/ysqrf3sEpNzT/+n +6iD+CHieJ8ZFfOTOemFUJI6EnqXOjin4XAvnxK/FaFQQQvNknNKTtWzujF6ZnNV HdSJftna9c1IWAi84HLMYvamdW8xbJEWpMhKgvESygAuMvu9gTvJK124gBYNIG3W 4PGSWaWH7PNbbZpcwhj1F+RVJ5DEvOJObESYnCvIfViOtV0iOOYmM1uO5OUDKFOV UOlIE7ABrIi7+nRrGptHM2KBCJ+9PTU/z6PzTX5Zr70V4FgYwWJQw03HtX5LZItz V6sBlNXni/NK93X+F252AKTHlqau9BmLD0juxBy7fSBMjxTIdTliRGBrVjI9vQ1N msdEk3OZuuL+qVnvCS04OEKnvZDGHIPgBMXsxvLZ0Gm/rimQFFP2MTOCXyJplprn aWwE0OL+4C7T+QiNm2djtKE8v64Uqp8Qb8h9pf0svri110/AjQV9BltPLwdeaV7H aVnO4gnMfSBe2GBeOjPWKusNQBD6EWSvYF0eYxQQt5/1V/r+D5+yBYJqXUfCLOqC 5zovFCBG9KwLm1sRDbC3 =wiR/ -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Dec 16 19:36:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1CA1E9; Tue, 16 Dec 2014 19:36:30 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2227A9C; Tue, 16 Dec 2014 19:36:29 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::949f:2cd4:f2b0:7a2d] (unknown [IPv6:2001:7b8:3a7:0:949f:2cd4:f2b0:7a2d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 810F7B80A; Tue, 16 Dec 2014 20:36:25 +0100 (CET) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> Date: Tue, 16 Dec 2014 20:36:14 +0100 Message-Id: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> To: FreeBSD-Current X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:36:30 -0000 --Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Nov 2014, at 22:03, Dimitry Andric wrote: >=20 > We're working on updating llvm, clang and lldb to 3.5.0 in head. This > is quite a big update again, and any help with testing is appreciated. >=20 > To try this out, ensure you have good backups or snapshots, then build > world and kernel from the projects/clang350-import branch [1]. Please > use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. * PowerPC64 should mostly work, thanks to Justin Hibbits. * PowerPC32 might start working soon; it really needs some backporting of fixes to clang 3.4.1, which is now in head, so there is an easier upgrade path for PowerPC users. * Sparc64 still does not work, and I don't see any quick solutions to it for now. It should probably stay with gcc. * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. Lastly, to clear things up about the requirements for this branch (and thus for head, in a while); to build it, you need to have: * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or gcc >=3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D 4.8. So from any earlier standard 10.x or 11.x installation, you should be good, unless you explicitly disabled clang or libc++. In that case, you must build and install both of those first. On a 9.x installation, you will have clang by default, but not libc++, so libc++ should be built and installed first, before attempting to build the clang350-import branch. On 8.x an earlier, you need to upgrade to at least 9.x first, follow the previous instruction. As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while (roughly a month), but this will cause upgrades from 9.x to 10.x to start requiring the build of libc++, as described above. I don't think we can merge clang 3.5.x to 9.x, unless clang becomes the default compiler there (but that is very unlikely). -Dimitry [1] svn://svn.freebsd.org/base/projects/clang350-import [2] = https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn.html#svn-mi= rrors [3] = http://pb2.nyi.freebsd.org/build.html?mastername=3Dhead-amd64-PR195480-def= ault&build=3D2014-12-12_23h17m02s [4] https://svnweb.freebsd.org/changeset/ports/374780 --Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSQibcACgkQsF6jCi4glqMLqACdFS2s3k6N5P/wyb7iIfxuLpn5 2CoAn1K6tH3+OtZZc+K5NncA4dYaTE52 =Tg7o -----END PGP SIGNATURE----- --Apple-Mail=_0B8D3B99-55C1-4902-9EE7-A3F0D2EA96CD-- From owner-freebsd-arm@FreeBSD.ORG Tue Dec 16 19:53:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC8D397B for ; Tue, 16 Dec 2014 19:53:23 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id 4908B325 for ; Tue, 16 Dec 2014 19:53:22 +0000 (UTC) Received: from wwinf1j32 ([10.232.42.106]) by mwinf5d52 with ME id UKlk1p00N2HSGtW03Klk16; Tue, 16 Dec 2014 20:45:44 +0100 X-ME-Helo: wwinf1j32 X-ME-Auth: Z2RhbG1hc0B3YW5hZG9vLmZy X-ME-Date: Tue, 16 Dec 2014 20:45:44 +0100 X-ME-IP: 90.15.230.61 Date: Tue, 16 Dec 2014 20:45:44 +0100 (CET) From: Gilles DALMAS Reply-To: Gilles DALMAS To: freebsd-arm Message-ID: <1069979072.26915.1418759144718.JavaMail.www@wwinf1j32> Subject: MIME-Version: 1.0 X-Originating-IP: [90.15.230.61] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:53:23 -0000 hello, are there any news about the gmac support in freebsd=C2=A0 for Cubieboard 3= , among others? =C2=A0 =C2=A0 Salutations, Gilles From owner-freebsd-arm@FreeBSD.ORG Tue Dec 16 20:12:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 799CFF6 for ; Tue, 16 Dec 2014 20:12:37 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFB4816 for ; Tue, 16 Dec 2014 20:12:35 +0000 (UTC) Received: from wwinf1j32 ([10.232.42.106]) by mwinf5d49 with ME id ULCU1p00L2HSGtW03LCUL7; Tue, 16 Dec 2014 21:12:28 +0100 X-ME-Helo: wwinf1j32 X-ME-Auth: Z2RhbG1hc0B3YW5hZG9vLmZy X-ME-Date: Tue, 16 Dec 2014 21:12:28 +0100 X-ME-IP: 90.15.230.61 Date: Tue, 16 Dec 2014 21:12:28 +0100 (CET) From: Gilles DALMAS Reply-To: Gilles DALMAS To: freebsd-arm Message-ID: <1672054200.27808.1418760748677.JavaMail.www@wwinf1j32> Subject: gmac support MIME-Version: 1.0 X-Originating-IP: [90.15.230.61] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:12:37 -0000 hello, are there any news about the gmac support in freebsd=C2=A0 for Cubieboard 3= , among others? =C2=A0 =C2=A0 Salutations, Gilles From owner-freebsd-arm@FreeBSD.ORG Tue Dec 16 21:45:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 56BB3D43; Tue, 16 Dec 2014 21:45:53 +0000 (UTC) Message-ID: <5490A810.7040002@FreeBSD.org> Date: Tue, 16 Dec 2014 16:45:52 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dimitry Andric , FreeBSD-Current Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 21:45:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/16/2014 14:36, Dimitry Andric wrote: > * The second exp-run had much better results: the failure with the > highest number of dependencies is devel/mingw32-gcc, but this > seems to be due to a problem with makeinfo, not clang. The next > highest on the list is java/openjdk6, for which ports r374780 [4] > was very recently committed. Unfortunately, r374780 was not enough. Instead, I just turned off "-Werror" for now (r374824). https://svnweb.freebsd.org/changeset/ports/374824 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUkKgGAAoJEHyflib82/FGGtAH/jyK3fVhWeXlgID5MKov0+vq 34BwE98ppJWreu4LdkXGqCUZeciyMmcw4ROfEPo6IthIxcHsRleh+O+BnmA5wFce gMczWBO1R+uEzcSH75UhyaVJVMKy8BJ2vRU2s90GANUnMhcMvNjN0Y89+8PdCHWF zaR8oy/GlVpJ13RTbyeaMf8K0T6MyQp58VQYP1gmlhjafEjVOLO9IVZyLWVx/nsI +DtjLj1DdNrPKrV1jrVRmZ+bJqOLaLgL4FUV/vruSduA1U8E1BZgnklXqRPowXqN jmFbLYE4kiygcEmUnpVbLQeB2EWXbQq7g4pijh90qDrhCSX1rUN3gz2DxY/Mub4= =reYk -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Dec 17 23:01:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57415210 for ; Wed, 17 Dec 2014 23:01:45 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 142A6D6A for ; Wed, 17 Dec 2014 23:01:44 +0000 (UTC) Received: from [192.168.137.1] (afkd1.neoplus.adsl.tpnet.pl [178.42.3.1]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 62160C60260 for ; Wed, 17 Dec 2014 18:01:39 -0500 (EST) Message-ID: <54920B54.8010404@toomeek.waw.pl> Date: Thu, 18 Dec 2014 00:01:40 +0100 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: gmac support References: <1672054200.27808.1418760748677.JavaMail.www@wwinf1j32> In-Reply-To: <1672054200.27808.1418760748677.JavaMail.www@wwinf1j32> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Wed, 17 Dec 2014 18:01:40 -0500 (EST) X-Virus-Scanned: clamav-milter 0.98.4 at a8d2ba546e X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:01:45 -0000 Hello, I'm also interested in gmac support since Banana Pi 1Gbit NIC is using it... Regards, Tom W dniu 2014-12-16 21:12, Gilles DALMAS pisze: > hello, > > are there any news about the gmac support in freebsd for Cubieboard 3, among others? > > > > > > Salutations, > > > Gilles > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 01:18:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFDC46E3; Thu, 18 Dec 2014 01:17:59 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B82FC1C9D; Thu, 18 Dec 2014 01:17:59 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id r2so99542igi.0; Wed, 17 Dec 2014 17:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cagQMYQIqcr7b0Mp3glfGwKql8LZ/o4hO9BdjKX7R3c=; b=k+Iry73QsxfJ/bQM1pFp1Vl7/yKVtZK5kR/gonwCmIID0VGjskWWI0lRbeGUlRY3q9 Da5O/n+XXeR/UgqxeQEAdls786sNKNMT5yEFi1jKLB22YxCCMnHy06Gk+YtqrsCy+fNe Ikq/kGlZZEhNUkqfHfdll4VjTlQG1ZHiuuTVB8KkpMT3Yq1lS75vuPRTQDj9uJ8P1nbZ XrCYvIpWXKS05R4Ses2IrI0KIl5nr9LkHXrWNUr8YJx+J4AEbk0eVzGhVzt1z9dr6ARn LPUPTZlWbzzN7Bz+1wSMK8eV5TAdGYiQ9kBvhdHnWwXZiKBJt/H1LvpBat+es2DsIPxR GC2w== MIME-Version: 1.0 X-Received: by 10.107.18.208 with SMTP id 77mr43391288ios.57.1418865479115; Wed, 17 Dec 2014 17:17:59 -0800 (PST) Received: by 10.50.4.170 with HTTP; Wed, 17 Dec 2014 17:17:59 -0800 (PST) In-Reply-To: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> Date: Wed, 17 Dec 2014 17:17:59 -0800 Message-ID: Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import From: NGie Cooper To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD ARM , FreeBSD-Current , FreeBSD ports X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 01:18:00 -0000 On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric wrote: > Hi, ... Hi Dimitry, As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. - Could a "MK_CLANG_ALL_TARGETS" or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I made a lot of progress on my faster-build branch ( https://github.com/yaneurabeya/freebsd/tree/faster-build ), but got mired down in the minutiae of how this needs to be implemented (it worked up until I ran make tinderbox, of course :)..), and had to work on other things... Thanks! From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 02:07:46 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F24E0509 for ; Thu, 18 Dec 2014 02:07:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5531395 for ; Thu, 18 Dec 2014 02:07:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBI27jsL083861 for ; Thu, 18 Dec 2014 02:07:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196081] New: [PATCH] ARM: sunxi: Add driver for the MMC/SD host found in the Allwinner A10 SoC Date: Thu, 18 Dec 2014 02:07:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: omgalvan.86@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 02:07:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196081 Bug ID: 196081 Summary: [PATCH] ARM: sunxi: Add driver for the MMC/SD host found in the Allwinner A10 SoC Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: omgalvan.86@gmail.com CC: ganbold@freebsd.org, gonzo@FreeBSD.org, ian@FreeBSD.org, imp@FreeBSD.org Attachment #150704 maintainer-approval?(imp@FreeBSD.org), Flags: maintainer-approval?(ian@FreeBSD.org) Created attachment 150704 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=150704&action=edit sunxi MMC/SD device driver This is the device driver for the SD/MMC host controller found in Allwinner A10 SoCs. The original driver was written by Alexander Fedorov back in October 2013; however that version was lacking some features and had a couple of bugs that caused the kernel to panic when trying to boot. This version aims to correct those mistakes, as well as serving as a sort of documentation on this particular host, since the Allwinner datasheet is only available in Chinese language and one has to sign an NDA in order to get it. Most of the work consisted in reverse-engineering the Linux and U-Boot drivers. Some of the registers and the DMA scheme used by this host are similar to the ones on the Synopsys Designware SD Host Controller and the Altera Arria V family of SoCs; as such we based some of our work on the datasheets for those hosts. Right now the driver supports multiblock programmed I/O only. While that gives us a fairly decent performance, ideally we should add support for DMA. We already have a version which can perform DMA transfers, however we noticed the transferred data always ends up being corrupted. I'll be sending the DMA version after this one is reviewed an commited. We left Alexander's name in the driver's copyright header as it's fair since he wrote the first version. We also made some changes to other files besides a10_mmc.c and a10_mmcreg.h; as those changes were relatively minor we didn't think it was necessary for us to include our names in the header. As this is our first contribution to the project, any feedback is more than welcome. So far we've tested it with a few different microSD cards; it would be great if anyone could try using an actual MMC card. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 13:03:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB49DF7; Thu, 18 Dec 2014 13:03:08 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8AA112C7; Thu, 18 Dec 2014 13:03:07 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::74f6:f05:5a8d:a897] (unknown [IPv6:2001:7b8:3a7:0:74f6:f05:5a8d:a897]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9D394B80A; Thu, 18 Dec 2014 14:03:03 +0100 (CET) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C5A7933F-460F-431A-BE05-C752275FCCFF"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: Date: Thu, 18 Dec 2014 14:02:58 +0100 Message-Id: References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> To: NGie Cooper X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , FreeBSD ports X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 13:03:08 -0000 --Apple-Mail=_C5A7933F-460F-431A-BE05-C752275FCCFF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Dec 2014, at 02:17, NGie Cooper wrote: > > On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric wrote: ... > As a request to speed up the build process further, > - Would it be [easily] possible in the clang35 branch to bootstrap > the compiler for a specific architecture? The bootstrap / cross > compiler for instance always builds N targets instead of building just > the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) > - Could a "MK_CLANG_ALL_TARGETS" or something similar option be > added to src.opts.mk to fine tune this process for those of us who > don't want to build a cross-compile toolchain every iteration for our > target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. -Dimitry --Apple-Mail=_C5A7933F-460F-431A-BE05-C752275FCCFF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEUEARECAAYFAlSS0IYACgkQsF6jCi4glqPEdQCfVE7MItkXcaNthE+b/Y0AE1C6 btoAl0MSaWbjGLwTaC9ra/H7EMnGZQI= =iLuy -----END PGP SIGNATURE----- --Apple-Mail=_C5A7933F-460F-431A-BE05-C752275FCCFF-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 13:55:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAF7DDD8 for ; Thu, 18 Dec 2014 13:55:08 +0000 (UTC) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 806AB1BB8 for ; Thu, 18 Dec 2014 13:55:08 +0000 (UTC) X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=d5B3OGfE c=1 sm=1 a=PfRRqASh+22Lc+SRmnf6GA==:17 a=L9H7d07YOLsA:10 a=kj9zAlcOel0A:10 a=sIt-5M63AAAA:8 a=F23uU8RbzNy54pWHS2UA:9 a=CjuIK1q_8ugA:10 a=PfRRqASh+22Lc+SRmnf6GA==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.231.137 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.231.137] ([209.6.231.137:50834] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTP id 04/DE-42102-8F7D2945; Thu, 18 Dec 2014 08:34:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21650.55288.425711.209975@jerusalem.litteratus.org> Date: Thu, 18 Dec 2014 08:34:48 -0500 To: Dimitry Andric Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import In-Reply-To: References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> X-Mailer: VM 8.2.0b under 24.4.1 (amd64-portbld-freebsd10.1) Cc: FreeBSD ARM , FreeBSD-Current , FreeBSD ports , NGie Cooper X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 13:55:08 -0000 Dimitry Andric writes: > > - Could a "MK_CLANG_ALL_TARGETS" or something similar option be > > added to src.opts.mk to fine tune this process for those of us who > > don't want to build a cross-compile toolchain every iteration for our > > target MACHINE/MACHINE_ARCH? > > I would be fine with something like this, as long as it is turned off by > default, or if it is only used for the bootstrap stages. It is actually > an extremely useful feature of clang that you can target multiple > architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? Curiously, Robert Huff From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 14:21:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B12F8682 for ; Thu, 18 Dec 2014 14:21:46 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CAD41FF1 for ; Thu, 18 Dec 2014 14:21:46 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so1493125pdi.35 for ; Thu, 18 Dec 2014 06:21:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=EgDqQl03gMfOfJkt+SJDNNEnUtEbl7yXAiOI0do0zD0=; b=bzHNAoAv4RoKF3w5osl/odXYwybT2+Mu2CoY+C1GJNmkj7k84/4YQNFc2FN4G0dZ9G zm0kDEkfTuUCMsvotaoIeXHOFVWmkgCY6P2DtXFaZh4W4f6S7KD9z8duLKvT1K2rVmhV 6HVl8AgyCpsXDYx4rtXLfrRFghh2KaLla0bI7QOq1yY4W+wB/XIgytrktwCWL66WBdNW 7UU1bkNI6ByB9r3zHgg1U33K3JaqsudTIHLVfMw5N7raH5NoubrKpFYVbsAnLUGsdDdc 3EWU3jMVgUVj0VxxWkdp0uT+ez+eFoz7MPbEeNyE/a01N4QcujGdgnBmXGB/6cSPpSTv 2YoA== X-Gm-Message-State: ALoCoQmF5jLjVYk/U/jQVURcv1VjK3RTQRrDFF5HjT4c/mDjnp93ZRugL5OHkREBtjNT2Ii0cvGR X-Received: by 10.70.44.66 with SMTP id c2mr3772673pdm.51.1418912505431; Thu, 18 Dec 2014 06:21:45 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id i11sm6997479pbq.23.2014.12.18.06.21.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 06:21:44 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EDB854E8-CC35-4A03-9A15-80A65063E49F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Thu, 18 Dec 2014 07:21:41 -0700 Message-Id: References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , FreeBSD ports , NGie Cooper X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:21:46 -0000 --Apple-Mail=_EDB854E8-CC35-4A03-9A15-80A65063E49F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 18, 2014, at 6:02 AM, Dimitry Andric wrote: >=20 > On 18 Dec 2014, at 02:17, NGie Cooper wrote: >>=20 >> On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric = wrote: > ... >> As a request to speed up the build process further, >> - Would it be [easily] possible in the clang35 branch to bootstrap >> the compiler for a specific architecture? The bootstrap / cross >> compiler for instance always builds N targets instead of building = just >> the desired TARGET/TARGET_ARCH combo. >=20 > It's not very easy, at least not without breaking various parts of our > fragile build system, but I surely want to put something like this on > the TODO list for *after* the import has completed. >=20 > The branch is making progress right now, and I would not want to > complicate matters further by introducing yet another tricky feature. = :) The build system isn=E2=80=99t so much the issue, but you wind up with files that refer to all the architectures. But this is a request for a new feature, not quite in scope for a = compiler upgrade. >> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be >> added to src.opts.mk to fine tune this process for those of us who >> don't want to build a cross-compile toolchain every iteration for our >> target MACHINE/MACHINE_ARCH? >=20 > I would be fine with something like this, as long as it is turned off = by > default, or if it is only used for the bootstrap stages. It is = actually > an extremely useful feature of clang that you can target multiple > architectures with one compiler binary. This is a new feature. Various people have tried in the past to = implement it and compiling just the mips files on mips is straight forward. = However, convincing clang to not reference the other architectures requires more sophistication than we currently have in the clang build process. > A more interesting case would be to remodel the build system so it can > use one toolchain (external, or pkg-ng'd, maybe?) for building an = entire > universe. With clang, that should be relatively easy to do. Another useful new feature. The hard part with this is getting all the = fiddly bits in the tree that depend on default CC producing proper binaries to cooperate.. Doable, but that=E2=80=99s a lot of universe builds. And = today it isn=E2=80=99t very practical because sparc64 and mips are broken... Warner --Apple-Mail=_EDB854E8-CC35-4A03-9A15-80A65063E49F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkuL1AAoJEGwc0Sh9sBEAjZ8QAI6iBNKPSQmhd9pG/LFGfztN cnlt5SdJgHCYuVqncB0/R7yIQiU2xm+kjXemXbd08lUqiXhcxdUQAeusNgVkw3pF BR0kviv0qmWjbtdBkWRjVKbGdfGkk7lJZhKrFzSxEJNrL4/7cm3pvf4jGgX0UNl0 JiL7CQNl5tmeQMsKcy09SzI9MNXFxbhHiKD5majqgx4sFsguqNzZRwnh78Cez8GM CMgVkRfGEY0FG49a+2iUDbq1/J7+tMTew8HpE5wgMsXlnYwi4jjTeZnpnoaq4IEa u4kIedMMbNoGyUTuM5wWN7XUe4RtOWqbye6ZEdtIn7LIPQFkWXU0Wj2nCxjsiMYt Kn+HJRhM2IaJA3RkYJW9o49Ek7841ZbG0zkUBFsRIM0UZstItZnUbUmHBqXG1pcB JSOj+k/Obrn1aXa7va4XQidNwtGi03EHuDJTTk7KqpAwiHb4aqFmPTXzKpKNR37G DZLQKZ32OWAqyr80pKrn33jj9mzq7CYAU8c6SvOWUkL2+W5dn5b5P7evvzmrglsX noRNiiHmRJiDdn1HJemUVWyLlTyHbgm1DtMu/Dc/k40a3pRAv2kAYVNcZ0HpcyP3 sPKI3zeariL5x+bssleP0lUyJNKZcsyr1F9BlLhO2u+hOFbmjHucQgqekuQ/UOpv /teGdffq8+qwuBVpJCFO =7moE -----END PGP SIGNATURE----- --Apple-Mail=_EDB854E8-CC35-4A03-9A15-80A65063E49F-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 14:23:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88E217DE for ; Thu, 18 Dec 2014 14:23:09 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DE5D1FFF for ; Thu, 18 Dec 2014 14:23:09 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id bj1so1487606pad.37 for ; Thu, 18 Dec 2014 06:23:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ZMN4BQZ6YiqBlrjFuOI+gyoMX4N/cVJ5PjciO8GPego=; b=jVXmCKJqOGksLfzvFIRcRtxl/wt1ozr3wqNNywUXTfs28lNA8FpvqgVtKSgNVn0QRU Pd4tqg31PxUs07d3Va2EF7AHdxpLnO0D/S23FWepBR4QIgi0cRnVXA2iW8EeIK0f5cDR zNu+6yCLxDPswxghCuUf7I8+kmFvB6q7xExKDphYGEacAEH1TzVYCOeQvAN7yBkSVCLX fCWcQYUFoq0BPIYZ9jWs52wvOZinBofA0+gS/JZd37G71ngI+z6d8UVDM9KE1WvGozQv uaB63gBegm1TKTRQj+YeERAv1hrNCAN70lifEuQoN+JqX6yB/g7U699VP1rPTMglVi7x rU4Q== X-Gm-Message-State: ALoCoQln1FQs83hgi6Oy5GQdnrU1auv7ZONUW+yRi/m5BC+lFRIhUeP3rAhDuMV9ptjl86T1f0wc X-Received: by 10.69.16.99 with SMTP id fv3mr3826643pbd.43.1418912582577; Thu, 18 Dec 2014 06:23:02 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id oq6sm6979863pdb.45.2014.12.18.06.23.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 06:23:01 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F8E895ED-1245-483D-9B18-946ECE5EC863"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <21650.55288.425711.209975@jerusalem.litteratus.org> Date: Thu, 18 Dec 2014 07:22:59 -0700 Message-Id: <75214DC1-919B-4F96-8052-09AFE283453E@bsdimp.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <21650.55288.425711.209975@jerusalem.litteratus.org> To: owner-freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , Dimitry Andric , NGie Cooper , FreeBSD ports X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:23:09 -0000 --Apple-Mail=_F8E895ED-1245-483D-9B18-946ECE5EC863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 18, 2014, at 6:34 AM, owner-freebsd-arm@freebsd.org wrote: >=20 >=20 > Dimitry Andric writes: >=20 >>> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be >>> added to src.opts.mk to fine tune this process for those of us who >>> don't want to build a cross-compile toolchain every iteration for = our >>> target MACHINE/MACHINE_ARCH? >>=20 >> I would be fine with something like this, as long as it is turned off = by >> default, or if it is only used for the bootstrap stages. It is = actually >> an extremely useful feature of clang that you can target multiple >> architectures with one compiler binary. >=20 > Point of information: this seems useful for developers, and > (almost entirely) useless for everyone else. Are there other > cohorts that want this badly? > If that's correct, and there's a simple switch for > configuration ... why should this default to what's useful for the > (much?) smaller number of people? About what am I ignorant? Only people working on a single binary of clang to build all = architectures are interested, which is a vanishingly small number. There=E2=80=99s = little point to build this stuff even for hard-core developers. Warner --Apple-Mail=_F8E895ED-1245-483D-9B18-946ECE5EC863 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkuNDAAoJEGwc0Sh9sBEA0SYP/1bzvZlk7++0nOuSqprYl7/g hpy3cLx/hqdPE+g7fWBdMYQhzLs0Rd8OfLW4qQ/h1W8iwoz8s8KzqCyDAJoaTbf/ lP+VvjDTy7T9dj7bqyMjdjseY11VpxLOremJABuoV+UAv68uVCg49MdKI9FIjZcM +WAvA8Of0L4xkxcvsA+CU1uqamI2BAylyh7AvHCdHhs0EC7bUg+d+oWPEvpOpcq8 9FBpC+uIwBXI5ZHaHubclYhamzCT+63sQzY7J4h5awsafmFAi0LySXZEhPYdQC+L uAqDOT1i5h4dcCI5NJx97yDqgpdNCSjCq3ckgBx2ZzmFBERB17m+KfmaMYRupM47 mqegwzvPTJ6CsduJnBCth88YmryB36JmW86Jy+Gn8oXd2nSiFeIROgjyVWb5eg7J lLrMHo8bajWkgsiTpN7yWcLqjDD3FY1M4rftVp+NBfhG/qhCBxmO0hymHqKOJajG 6elDIs+yWdddcPoTd4UiyxWGPRqvQqGxQb/VsDcHwUD/s0nQ8EAI/hlQMcT8HhsG rRovEoIlM4mr8IekQtmNbm++PKxhDe79xBxn4L7sp4GuKHIO+QR4hd9OyYwIvYxF T46ZLkmxXuDDkI53Wq6bnFLNiA6n2YHIwzWkCe15vBbAtU/AMLH5gnhXI9cK3dpA ffRtYAS+n7S6Wd3EVxdy =zJx1 -----END PGP SIGNATURE----- --Apple-Mail=_F8E895ED-1245-483D-9B18-946ECE5EC863-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 14:44:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29D01E21; Thu, 18 Dec 2014 14:44:32 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3A742493; Thu, 18 Dec 2014 14:44:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::74f6:f05:5a8d:a897] (unknown [IPv6:2001:7b8:3a7:0:74f6:f05:5a8d:a897]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A89B4B80A; Thu, 18 Dec 2014 15:44:22 +0100 (CET) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: <21650.55288.425711.209975@jerusalem.litteratus.org> Date: Thu, 18 Dec 2014 15:44:12 +0100 Message-Id: References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <21650.55288.425711.209975@jerusalem.litteratus.org> To: Robert Huff X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , FreeBSD ports , NGie Cooper X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:44:32 -0000 --Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Dec 2014, at 14:34, Robert Huff wrote: > Dimitry Andric writes: > >>> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be >>> added to src.opts.mk to fine tune this process for those of us who >>> don't want to build a cross-compile toolchain every iteration for our >>> target MACHINE/MACHINE_ARCH? >> >> I would be fine with something like this, as long as it is turned off by >> default, or if it is only used for the bootstrap stages. It is actually >> an extremely useful feature of clang that you can target multiple >> architectures with one compiler binary. > > Point of information: this seems useful for developers, and > (almost entirely) useless for everyone else. Are there other > cohorts that want this badly? > If that's correct, and there's a simple switch for > configuration ... why should this default to what's useful for the > (much?) smaller number of people? About what am I ignorant? It's not a simple switch, at least not now. If you use the upstream build system for llvm, e.g. autoconf or CMake, it has an option to select all the architectures that are supported. Several config files are then generated differently, and parts of the target support subdirectories are selectively enabled or disabled. In fact, we already build just a subset of the available architectures, since FreeBSD only supports about 5 of them. We can probably arrange for a more minimal configuration in our build system, but since the build time saved is quite small, I don't think it makes much sense in complicating our build system even further. If people are really so interested in shaving off a little, for more complication, that is fine with me. But unfortunately, I have too many tasks on my plate right now, and I cannot work on it. Besides, doing such a new feature now would interfere with the current branch work. Also, after the 3.5.0 import, there are much more interesting fish to fry, in my opinion. For example, importing newer versions of libc++ and compiler-rt, which can bring address sanitizer support, etc. -Dimitry --Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSS6EQACgkQsF6jCi4glqOINgCgtxznuS7Lp1GZzdsGdaVA5H/t 0GIAoNqaW8VrXZUqBlJqhaqvx97ggMWA =vrEg -----END PGP SIGNATURE----- --Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 14:47:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D38A17F for ; Thu, 18 Dec 2014 14:47:41 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60A8424ED for ; Thu, 18 Dec 2014 14:47:41 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so1528846pab.40 for ; Thu, 18 Dec 2014 06:47:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=p5IpbZglrLI1dIIJpyXpYFXl0CH/aGonP2IaKLPKrB4=; b=dyEntbdhVvG0W5hTuvPsf+l4c9cAVOY4QrqKBmkvPzCehswEdCqkjmQDUdYzoRSq8q q8gRaRhyCl1XxhUNsWqO9+QqG0y1POz02is0JKnc4sKNi0w05EfDWajBq/GfvqZrurwD OW6ILT0ScjCUrB4zzuksYQu9lpKl/yup3v9DNBeD9DdtPJMe5BGma4zJ/5PBJkI+jlIM bH7imPjV0pDcKDpPmerztFqmEuCgt6d5/rTzGZmr/2fmR/dvTWRSrJH3YOaG9MBspQRJ AfG3GD7eYllRlpZHSSWUtr5bi6ndx6Bdf3BtvjZRThGb+1qKvfohZi6cPO7dYQd+uSsK b8HQ== X-Gm-Message-State: ALoCoQkdSjXv0APRV+nf80bdtjxRg9p5kCk0IfAPpQqlB8wUchgO5+WdFyk+2K63VBLGcgL7JZFp X-Received: by 10.68.69.109 with SMTP id d13mr3975826pbu.57.1418914055686; Thu, 18 Dec 2014 06:47:35 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id t9sm6970859pbs.75.2014.12.18.06.47.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 06:47:34 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Date: Thu, 18 Dec 2014 07:47:31 -0700 Message-Id: References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:47:41 -0000 --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is excellent news Dimitry! > On Dec 16, 2014, at 12:36 PM, Dimitry Andric wrote: >=20 > On 28 Nov 2014, at 22:03, Dimitry Andric wrote: >>=20 >> We're working on updating llvm, clang and lldb to 3.5.0 in head. = This >> is quite a big update again, and any help with testing is = appreciated. >>=20 >> To try this out, ensure you have good backups or snapshots, then = build >> world and kernel from the projects/clang350-import branch [1]. = Please >> use a Subversion mirror [2], if you are able to. >=20 > Here are some updates about the status of the 3.5.0 import. >=20 > * i386 and amd64 have been tested through make universe, and = everything > should compile and run. > * Little-endian ARM builds should now compile and run, thanks to = Andrew > Turner for putting in lots of work. > * Big-endian ARM is apparently supposed to work, but I'm not sure if > Andrew managed to test it on real hardware. I know Andrew doesn=E2=80=99t have the right arm gear to do this test, = and emulation environments that run FreeBSD have had poor big-endian support for arm. > * PowerPC64 should mostly work, thanks to Justin Hibbits. > * PowerPC32 might start working soon; it really needs some backporting > of fixes to clang 3.4.1, which is now in head, so there is an easier > upgrade path for PowerPC users. > * Sparc64 still does not work, and I don't see any quick solutions to = it > for now. It should probably stay with gcc. > * Mips will only have a chance with the upcoming clang 3.6.0, but that > is way too late for this import. It will probably require external > toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. > * Another ports exp-run was done [3], after fixing the problem with > lang/gcc, which lead to many skipped dependent ports. > * The second exp-run had much better results: the failure with the > highest number of dependencies is devel/mingw32-gcc, but this seems > to be due to a problem with makeinfo, not clang. The next highest on > the list is java/openjdk6, for which ports r374780 [4] was very > recently committed. Will users of our stable branch have code similar to the code that = caused problems? One warning flag about your upgrade to the stable branch would be if there=E2=80=99s a significant number of user-written = programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there=E2=80=99s a good chance we won=E2=80=99t find them until users hit = them and start to complain (by which point it is likely too late). Could you post a = summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. > I would really like to merge this branch to head in about a week, > pending portmgr approvall; I don't expect the base system (outside of > llvm/clang) to need any further updates. I think there=E2=80=99s good reason to do this, but we should chat about = the build issues below before doing it. They are minor, but an important detail. I=E2=80=99ll see if I can find a few minutes to pull the branch = and send patches. > Lastly, to clear things up about the requirements for this branch (and > thus for head, in a while); to build it, you need to have: > * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) > * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >=20 > So from any earlier standard 10.x or 11.x installation, you should be > good, unless you explicitly disabled clang or libc++. In that case, > you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get = the word out a little better. > On a 9.x installation, you will have clang by default, but not libc++, > so libc++ should be built and installed first, before attempting to > build the clang350-import branch. Can you make sure that the UPDATING entry you are writing for this contains explicit instructions. > On 8.x an earlier, you need to upgrade to at least 9.x first, follow > the previous instruction. We should remove building on 8 support then, unless there external toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). > As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while > (roughly a month), but this will cause upgrades from 9.x to 10.x to > start requiring the build of libc++, as described above. I don't = think > we can merge clang 3.5.x to 9.x, unless clang becomes the default > compiler there (but that is very unlikely). Let=E2=80=99s see how it goes, and what the upgrade issues wind up being before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers on = stable branches traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly identical to prior releases than gcc was, it might not have the same = issues associated with it. Warner --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkukEAAoJEGwc0Sh9sBEAT0kP/Rnez5JSvAwYw80kxMc/Ui1P rvW0Nq7D3sMYxXHY13Frt0+yT/7JEZpXMRGFGHijwaKd/iSgUT2W04BQAYHkjWWj Z2cq/mFLrKtcS8puBpDGC9hGkZ6jeB06k6N82mu+HrbrMtNxb7Rl9MAeaPyZl0vb dmKVFmSDSnlNCSSE6sJygmexT4JKcP+2Bv8U/C4htCsKwnYzbroUJVhmhNwm6NHp Tgloml0B3IVdd3rY91uW6Ie1He1px96uoFnFS7IeHWsC2CkVKrpdOwoLXJdk8ofr /uyKvOCng7pmGmoNVE6/h0RdPGGatjHwdHgF2V1in4I2XNWmavMq8Js3+ipPAB0t ox4TMQqGWnOIAsGJiyAboPbrC4gTj3DpTVJp4SyROYMWMXtp8w26fOktzwErmHEq ghxR8GO8ypq5lhpURuzyprkn4rp++PHeLN5soDmFYjx8k39FXB8iWkrhFjiyaNh4 kaa1GWXTxuaDOMiDRLjgluo7LstAn5jUir0HX/CnPgycEFw5yCxEia7dTqHj0Jmx uGdx8a+ZnSptbuSjfytT0BH9TLRj2wYdGmwGNA12KrgYOuBTCZqEaOpdYvE0KN2W 4tFdAfr13vUzcUk0W6bD1uVFUn2myKvy7gxPD7C4+NyJ5ZUTLHKiwyeFn3O7KzeL QDFb8Gg5HEyaoGI9gSpf =k3ZX -----END PGP SIGNATURE----- --Apple-Mail=_7FA36E47-9950-4DAC-BDC0-A131AC31BE31-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 14:51:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A230488 for ; Thu, 18 Dec 2014 14:51:52 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EFCC25E0 for ; Thu, 18 Dec 2014 14:51:52 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so1578194pdj.0 for ; Thu, 18 Dec 2014 06:51:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=rD/Pm0XEpaCcg14dHYfT3WCE7Bzxzr7rqJbuRe5FETE=; b=jvH+k1DcI4YImFSQl9w9heO0MEMwNZ7sXXsm39NJzp3ipwE3QVe56ezAkGwHiClmkI hdXAgqzjMftglqpdBfqDIHkPhmvPFlHjiBNURkMls4dKqUogB91IgrV0N3SypP/CAfu1 wQLTSFA6QhuiPbqicorB1dH9ws5nyMi7tg4q4PtB7eS3K+l60spvTFJDuaIRz8OOF6LN naJqJ3o3idDZKYk2ipytZY8ABF3gEe4rVZ4R+LTh+K8YLaAr03g/dQAAkqRClFESszwR xgo+FaV6CSrJT9zg7iddMp8d49xkJWb8eq/gSrszx5OuTEioWSyOBCd3bdZN4WjQ61gE mGwA== X-Gm-Message-State: ALoCoQm8W9OvEEk1MlsAsMbU7LePO/8Be98Qdi2UzPz5qT9LHneDjFQ3+AuvlaRor79U9lCwJewt X-Received: by 10.68.68.130 with SMTP id w2mr3928581pbt.167.1418914311460; Thu, 18 Dec 2014 06:51:51 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id kw10sm7082469pab.29.2014.12.18.06.51.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 06:51:50 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8585A9CA-84EF-42F8-B871-2B3E958B1A69"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Thu, 18 Dec 2014 07:51:47 -0700 Message-Id: <9D9850F8-62D6-4A85-BED3-1B4AB4DE5C14@bsdimp.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <21650.55288.425711.209975@jerusalem.litteratus.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , Robert Huff , NGie Cooper , FreeBSD ports , FreeBSD-Current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:51:52 -0000 --Apple-Mail=_8585A9CA-84EF-42F8-B871-2B3E958B1A69 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Dec 18, 2014, at 7:44 AM, Dimitry Andric wrote: > > On 18 Dec 2014, at 14:34, Robert Huff wrote: >> Dimitry Andric writes: >> >>>> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be >>>> added to src.opts.mk to fine tune this process for those of us who >>>> don't want to build a cross-compile toolchain every iteration for our >>>> target MACHINE/MACHINE_ARCH? >>> >>> I would be fine with something like this, as long as it is turned off by >>> default, or if it is only used for the bootstrap stages. It is actually >>> an extremely useful feature of clang that you can target multiple >>> architectures with one compiler binary. >> >> Point of information: this seems useful for developers, and >> (almost entirely) useless for everyone else. Are there other >> cohorts that want this badly? >> If that's correct, and there's a simple switch for >> configuration ... why should this default to what's useful for the >> (much?) smaller number of people? About what am I ignorant? > > It's not a simple switch, at least not now. If you use the upstream > build system for llvm, e.g. autoconf or CMake, it has an option to > select all the architectures that are supported. Several config files > are then generated differently, and parts of the target support > subdirectories are selectively enabled or disabled. > > In fact, we already build just a subset of the available architectures, > since FreeBSD only supports about 5 of them. We can probably arrange > for a more minimal configuration in our build system, but since the > build time saved is quite small, I don't think it makes much sense in > complicating our build system even further. > > If people are really so interested in shaving off a little, for more > complication, that is fine with me. But unfortunately, I have too many > tasks on my plate right now, and I cannot work on it. Besides, doing > such a new feature now would interfere with the current branch work. With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. > Also, after the 3.5.0 import, there are much more interesting fish to > fry, in my opinion. For example, importing newer versions of libc++ and > compiler-rt, which can bring address sanitizer support, etc. I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. Warner --Apple-Mail=_8585A9CA-84EF-42F8-B871-2B3E958B1A69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkuoDAAoJEGwc0Sh9sBEAC2cP/RZEnJNk6MLxkknDLYxAZNsm pu69tosuAMV1rbYPjRjRwJxAhASrEsAq7vSGGMRjKIxtmXh5FILqm6EMPIPpnGdw zWGD6ILWp1OWCp9niZY3C6Ps4dyOERhGZwW+S5yDCRFARGBvU7G4fQ7hp9QzztPf ZJOLWeVcIYIKq0wQdeFxb5EzYRTWzg40LBBh3ko8b7ZTK4xTzuEqynGp78nrkDe3 vxeKNGZtcQCIOCHMSvZECwG8q/ZG6aim9QE9OaB8rrbMl1rdQS3Yjb4zaLNRJhaT q2YWrVo32Po7QVAlan0SymZe+wdu9pVfeqmyjvOEB2s/esjacOgAZxDc7gV2hKfE ZVE8DIyaaDItRrqTsaCPCW37/VVXrkDMTvj+5finiKf+/0BqKazLaBmLKUDRahZf ylIH+YtQB2K/wVc2POuJyfcLzyF4yCQHZdnBSaan2aonb9ob1Rovdz3FP96M+gJ5 8g3CKF87ZtnwUSAGZOZJ8mvaQvl6l8w50s8eE12KOuHJTXSJIrJZCOb9A0DBSTMS vD4VOnX0mTcXGa+4yME5j1cXHgjzqr7xxT//ofdkpbw1FXz4v/wzuVNNeKwHOdWV RJthyZVWplsoFkqetPwXUwJgWsCqkupx/1bUiYd7YWEu0BJpY9oBX44z2yc8hvm5 n1ug/eyRZtpdJOP4bqXp =k1B6 -----END PGP SIGNATURE----- --Apple-Mail=_8585A9CA-84EF-42F8-B871-2B3E958B1A69-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 19:01:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1C503A5; Thu, 18 Dec 2014 19:01:26 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45FA72E5A; Thu, 18 Dec 2014 19:01:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::74f6:f05:5a8d:a897] (unknown [IPv6:2001:7b8:3a7:0:74f6:f05:5a8d:a897]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A2B7BB80A; Thu, 18 Dec 2014 20:01:20 +0100 (CET) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: Dimitry Andric In-Reply-To: Date: Thu, 18 Dec 2014 20:01:09 +0100 Message-Id: <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> To: Warner Losh X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:01:26 -0000 --Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 18 Dec 2014, at 15:47, Warner Losh wrote: ... >> * Mips will only have a chance with the upcoming clang 3.6.0, but = that >> is way too late for this import. It will probably require external >> toolchain support to get it working. >=20 > For native builds yes. For cross builds, clang 3.6 can be built on an > x86 host. Yes, and it could even be one of the ports, if that is easier to use. > * Another ports exp-run was done [3], after fixing the problem with >> lang/gcc, which lead to many skipped dependent ports. >> * The second exp-run had much better results: the failure with the >> highest number of dependencies is devel/mingw32-gcc, but this seems >> to be due to a problem with makeinfo, not clang. The next highest on >> the list is java/openjdk6, for which ports r374780 [4] was very >> recently committed. >=20 > Will users of our stable branch have code similar to the code that = caused > problems? I'm not sure which code you are referring to here, the openjdk6 code? The code itself is basically fine, but for reasons unknown to me, the port is compiled with -Werror (which is not the case for the other openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings for shaky C++ constructions, these appear during the openjdk6 build, but they are easily suppressed, if upstream does not fix them, or does not care to fix them. I already sent Jung-uk an alternative fix for openjkd6, similar to the one used for www/squid, where warnings are suppressed based on the COMPILER_VERSION variable provided the ports infrastructure. In my opinion it would still be easier to just to turn off -Werror for any third-party code, if we don't feel like modifying it (with all the risks involved). > One warning flag about your upgrade to the stable branch > would be if there=E2=80=99s a significant number of user-written = programs that > suddenly become uncompilable with the new clang using the environment > that they have today. We know of some items that are issues, so = careful > attention here is needed. Unless we go proactively looking for these, > there=E2=80=99s a good chance we won=E2=80=99t find them until users = hit them and start > to complain (by which point it is likely too late). Could you post a = summary > of the issues that ports have hit and the fixes necessary? We may need > to have that in the release notes and/or UPDATING file to help prepare > our users for the bumps and give them solutions over them. The base system is already completely free of warnings, as far as I know of, so no action is needed there. For ports, the number of failures introduced by new warnings are quite small, as far as I can see, and mostly for ports that are compiled with -Werror. The most encountered new warnings are, off the top of my head: -Wabsolute-value This warns in two cases, for both C and C++: * When the code is trying to take the absolute value of an unsigned quantity, which is effectively a no-op, and almost never what was intended. The code should be fixed, if at all possible. * When the code is trying to take the absolute value, but the called abs() variant is of the wrong type, which may lead to truncation. If the warning is turned off, better make sure any truncation does not lead to unwanted side-effects. -Wtautological-undefined-compare and -Wundefined-bool-conversion These warn when C++ code is trying to compare 'this' against NULL, while 'this' should never be NULL in well-defined C++ code. However, there is some legacy (pre C++11) code out there, which actively abuses this feature, which was less strictly defined in previous C++ versions. Squid does this, and apparently openjdk too. The warning can be turned off for C++98 and earlier, but compiling the code in C++11 mode might result in unexpected behavior, for example the unreachable parts of the program could be optimized away. > I would really like to merge this branch to head in about a week, >> pending portmgr approvall; I don't expect the base system (outside of >> llvm/clang) to need any further updates. >=20 > I think there=E2=80=99s good reason to do this, but we should chat = about the > build issues below before doing it. They are minor, but an important > detail. I=E2=80=99ll see if I can find a few minutes to pull the = branch and send > patches. >=20 >> Lastly, to clear things up about the requirements for this branch = (and >> thus for head, in a while); to build it, you need to have: >> * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >>> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) >> * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >>=20 >> So from any earlier standard 10.x or 11.x installation, you should be >> good, unless you explicitly disabled clang or libc++. In that case, >> you must build and install both of those first. >=20 > This is true only on i386, amd64, and arm hosts. Given that some = people > do try to do weird things, tightening up how you present this will get = the > word out a little better. >=20 >> On a 9.x installation, you will have clang by default, but not = libc++, >> so libc++ should be built and installed first, before attempting to >> build the clang350-import branch. >=20 > Can you make sure that the UPDATING entry you are writing for this > contains explicit instructions. I'm quite bad at writing UPDATING entries, so any help there is much appreciated. :-) > On 8.x an earlier, you need to upgrade to at least 9.x first, follow >> the previous instruction. >=20 > We should remove building on 8 support then, unless there external > toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). The problem with 8.x is that it still has the old binutils 2.15, and neither clang nor libc++. It would really require some externally supplied parts. Maybe this could be done with ports, but I'm not sure how long ports still supports the 8.x branch? >> As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while >> (roughly a month), but this will cause upgrades from 9.x to 10.x to >> start requiring the build of libc++, as described above. I don't = think >> we can merge clang 3.5.x to 9.x, unless clang becomes the default >> compiler there (but that is very unlikely). >=20 > Let=E2=80=99s see how it goes, and what the upgrade issues wind up = being > before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers on = stable branches > traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly > identical to prior releases than gcc was, it might not have the same = issues > associated with it. We don't really use llvm or clang's own ABI for anything at the moment, just the resulting compiler executable, which is actually one big binary (and it is even statically linked, by default). The code output by clang 3.4.1 or 3.5.0 is not different in any "ABI" sense of the word. Of course it will be different in absolute sense, since optimizations were improved, and so on. The only real issue is how to bootstrap the compiler itself, since it requires working C++11 support. In 10.x, we provide that by default, but not in earlier releases. -Dimitry --Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSTJH0ACgkQsF6jCi4glqOyzwCfUxIAeT19Ct+Sar04C72noiC3 SwcAoONLkGO04a0C7/Y9oxfTfhidmjs3 =SWHs -----END PGP SIGNATURE----- --Apple-Mail=_87AADF1D-B9B8-4954-9EDC-21E6948A47C2-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 19:13:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83D7599D; Thu, 18 Dec 2014 19:13:37 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49973105D; Thu, 18 Dec 2014 19:13:37 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id fp1so1975947pdb.24; Thu, 18 Dec 2014 11:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+xmpZdoMcVfKiQSBuMyzFvGknYzx3AXeytKJBe+ZynU=; b=VRCjSciVRkM/LMPYUbgHG0GCBK4oXdjQUjZvwu8NgPNey+MGNZRfkh+43sjMRGAd18 g61qIou4fBG0c4cjapECaMRzqt2+pBNm/2F3YAbaZOMLsq2K+p9K7wKR8PozWLvQNEBl m187IAC+83Ujh22pv1VXVhJ2bnmX798Dg3IzpREmXKFjdoC6Q7zX+Noh/JyJ8XZyxyWH ZYqHkg5qQnCT/PssSzgIccqX5oVK4q9Fwlhse1zNj4Vjo+Na9MxLMaAuGJbeOqAYilzk OiZ7NHzLY4dNZl/XTe3Defgi85C2Ee5NdtfGoJYUUbxeScGpAyDZTOxnB01lOyfUHvpf DDug== X-Received: by 10.70.137.1 with SMTP id qe1mr6127549pdb.90.1418930016794; Thu, 18 Dec 2014 11:13:36 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:4965:32c9:fd93:5519? ([2601:8:ab80:7d6:4965:32c9:fd93:5519]) by mx.google.com with ESMTPSA id eo4sm7401811pbb.87.2014.12.18.11.13.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 11:13:35 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7E7A7273-DB8E-4D03-BA0E-96DA9BB5A08E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import From: Garrett Cooper In-Reply-To: Date: Thu, 18 Dec 2014 11:13:36 -0800 Message-Id: <6C1932BE-8B1D-44E1-AAFA-C24756434BDC@gmail.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD ARM , FreeBSD-Current , FreeBSD ports X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:13:37 -0000 --Apple-Mail=_7E7A7273-DB8E-4D03-BA0E-96DA9BB5A08E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 18, 2014, at 5:02, Dimitry Andric wrote: > On 18 Dec 2014, at 02:17, NGie Cooper wrote: >>=20 >> On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric = wrote: > ... >> As a request to speed up the build process further, >> - Would it be [easily] possible in the clang35 branch to bootstrap >> the compiler for a specific architecture? The bootstrap / cross >> compiler for instance always builds N targets instead of building = just >> the desired TARGET/TARGET_ARCH combo. >=20 > It's not very easy, at least not without breaking various parts of our > fragile build system, but I surely want to put something like this on > the TODO list for *after* the import has completed. >=20 > The branch is making progress right now, and I would not want to > complicate matters further by introducing yet another tricky feature. = :) Fair enough :). >> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be >> added to src.opts.mk to fine tune this process for those of us who >> don't want to build a cross-compile toolchain every iteration for our >> target MACHINE/MACHINE_ARCH? >=20 > I would be fine with something like this, as long as it is turned off = by > default, or if it is only used for the bootstrap stages. It is = actually > an extremely useful feature of clang that you can target multiple > architectures with one compiler binary. Yes. If make tinderbox could use this it would be useful, otherwise, for = most folks it seems like a less interesting feature. > A more interesting case would be to remodel the build system so it can > use one toolchain (external, or pkg-ng'd, maybe?) for building an = entire > universe. With clang, that should be relatively easy to do. Agreed. bdrewery is working on something similar to that internally for = Isilon. Building the same toolchain N times internally when building the = system and your upstream revision of FreeBSD doesn=92t change is like = testing your sanity =97 not much changes with the bootstrap = compiler/toolchain then! Thanks for the reply :)! --Apple-Mail=_7E7A7273-DB8E-4D03-BA0E-96DA9BB5A08E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUkydgAAoJEMZr5QU6S73eA5MH/Rocvs4q+qhcrhIzhRFcqHGb iuQ0c9VqwmR7BU4aWAMY1qIzBqsEfyImZfUGc/zUAJ+zWQlf8QnJy50Bi5V9kTUO VLin6d7r62VvQu/yUQ0e948w/tlaIRC9kqiEliYZfFqdJMZLfF7ADS69ahzGuSm2 tUQiMLsPE/SMcehspLW/SweT3+fL44UXrzIzxJIAqeP3ea7GPEMQ0+auvqR40yLl iTsTlu2nyCESdWiuQ5tCJoSXjcWRiRsH3fMpCebSwT7oxi0Xn+TDE8PsXSti8doz btDp1abP0F/cQN84fy0xLX+TaUs5XonZe7YgIp080AqbgvhJAZSPy+g1WUsnAvc= =GVVZ -----END PGP SIGNATURE----- --Apple-Mail=_7E7A7273-DB8E-4D03-BA0E-96DA9BB5A08E-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 21:17:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 042E08A3; Thu, 18 Dec 2014 21:17:08 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAD3E26AD; Thu, 18 Dec 2014 21:17:07 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id kx10so2171162pab.30; Thu, 18 Dec 2014 13:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WiNtF0Rm5xB5caPl8hAFac/vQeXBa/vatvcceFslTj8=; b=RnfZoqHGwpKdpJY4VeW4zK9LGUkMb7T7M8nX7K73OUlESgtn0qgp30wk1v3139NgCX sTTE0noMsVnEMXBDm66FIenqsad+g9ToR0hfSiqgMMAVMNxOiqfybywL6KPXal9+RixD Vr+3E3tlc/0XDa0MyBk9hIkJeFoo/p3ie3Q5nXkec+B5PJhmfVuf8a3MXnEK8WbOLMwU 5HVV6BPXs/c5/EaJ5KjGbyT46SbBS5tUrpoPqeB8rnOSQ9f+tmBzu7tWtPMS3oO9PpsS W8voVSn0qPxigBNotIoYy6h1QGcUapkAK/007XvFWBg0q8HbE47SEeItI/D4DllPqoUv WNvw== X-Received: by 10.67.1.66 with SMTP id be2mr6799097pad.132.1418937427313; Thu, 18 Dec 2014 13:17:07 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id m7sm7622278pdj.47.2014.12.18.13.17.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 13:17:06 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_809A63B6-D6BB-4306-BBEF-CE33F0F6EA92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import From: Garrett Cooper In-Reply-To: <9D9850F8-62D6-4A85-BED3-1B4AB4DE5C14@bsdimp.com> Date: Thu, 18 Dec 2014 13:17:03 -0800 Message-Id: <18CDB8BF-C24E-442D-8904-5DB777E64A62@gmail.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <21650.55288.425711.209975@jerusalem.litteratus.org> <9D9850F8-62D6-4A85-BED3-1B4AB4DE5C14@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD ARM , Robert Huff , Dimitry Andric , FreeBSD ports , FreeBSD-Current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 21:17:08 -0000 --Apple-Mail=_809A63B6-D6BB-4306-BBEF-CE33F0F6EA92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 18, 2014, at 6:51, Warner Losh wrote: > With the recent parallelism work, the is true. It might save a couple = percent > off the build time. Before those changes, though, disabling all non = target > arches saved about 10% of the buildworld time. I=92m curious. How much is 10% in terms of minutes and with what -j = value? > Creating a hack to do this is easy (which is how I measured it). But = Dimitry > is right that creating a robust solution is hard. Even harder if you = want it > to be completely clean. It didn=92t seem incredibly hard =97 it just required a bit more = =93generated files=94 in clang AFAICT. I=92ll hang ten until clang35 is = in so I can re-asses what=92s going on with building it. > I tend to agree. IMHO, supporting the work going on to bring the > meta-mode stuff will pay far higher dividends than optimizing this > corner of the build. True=85 probably will! --Apple-Mail=_809A63B6-D6BB-4306-BBEF-CE33F0F6EA92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUk0RPAAoJEMZr5QU6S73eDlIH/Rt0qDR/zVfty+f4hvlGSxgT nAaXV/kkkaS9LZcCjyi/4a/RYHUQ1n04I1DVFKmlXkokfCRHpjCV+qZngPyPkbh2 bOFaqMIUKc6Ch+9Y3wXCCIIpLD/7op29vjad/gWNvKsaelWTsdyv3Ls+1nxS4Mmn 69KCWuBqOmf37c1rjHZPOjcBUJG8xY4TDY7kVHn7HSIU+HUBpbSUK1hvTVU5uAd9 +Z8MKgRO9PHev7mzlQTXKblW7pLr7I/N6Lwf6qAfiny48DVJhkk5ZPEvhv0LJgua FFyq0YUGAHjQehmmiigBZ8hsvpCwahdRShzAqYXqeDV6KQ6vHJi48dYIIz6Vks0= =l2No -----END PGP SIGNATURE----- --Apple-Mail=_809A63B6-D6BB-4306-BBEF-CE33F0F6EA92-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 21:29:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F174EFB for ; Thu, 18 Dec 2014 21:29:59 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED2C02830 for ; Thu, 18 Dec 2014 21:29:58 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id fp1so2184733pdb.24 for ; Thu, 18 Dec 2014 13:29:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=8xMcoKdxkZ0OSGQ9A3Uh7Kv6tWCSy2ty83F8QmuIcGY=; b=eEOfW0xE55YjUsg97bRWvOGBq57D4ZP715VIMWVpVPdMtry/DSDHe6ILSYY1X5Sb5E dHLDdLfGR4+g8e9D7aI9Bt9VOO5FsJJotMsIJnea6V5CGfufoLeBfaeMVYaPycTG5juq elSFdsIarskNvByLC5Xc+szRgcWO5o3RiQzX8sddYkX4+6Hf0iWrGBS6FnQzzSOnYKP8 +4YUaTtCcpwCHdrFtUO1ddq+5u113NHQmn3hjy00UCQfXmcrI1Ewbq4UXqr2WuE+ck+e 10cm0BfdCSQZyG124EhhfATF8BLZ6i8/EblkezfW+iz1n5fY4FcvLBGKv1lPTlBPqsyC qbuw== X-Gm-Message-State: ALoCoQlnM6h4Q5yRAiw8pVnt4PF1XHYuIdFX9FlNp5TMvN0fD8df7gSRo5wmSYs+zpZDNcSNO15E X-Received: by 10.70.27.225 with SMTP id w1mr7073622pdg.40.1418938192638; Thu, 18 Dec 2014 13:29:52 -0800 (PST) Received: from [10.64.25.114] ([69.53.236.236]) by mx.google.com with ESMTPSA id eo4sm7558138pbb.87.2014.12.18.13.29.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 13:29:51 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> Date: Thu, 18 Dec 2014 14:29:49 -0700 Message-Id: <8C5EFF7C-9CA0-43A4-89A3-C6BFF518E83E@bsdimp.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 21:29:59 -0000 --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 18, 2014, at 12:01 PM, Dimitry Andric wrote: >=20 > On 18 Dec 2014, at 15:47, Warner Losh wrote: > ... >>> * Mips will only have a chance with the upcoming clang 3.6.0, but = that >>> is way too late for this import. It will probably require external >>> toolchain support to get it working. >>=20 >> For native builds yes. For cross builds, clang 3.6 can be built on an >> x86 host. >=20 > Yes, and it could even be one of the ports, if that is easier to use. >=20 >=20 >> * Another ports exp-run was done [3], after fixing the problem with >>> lang/gcc, which lead to many skipped dependent ports. >>> * The second exp-run had much better results: the failure with the >>> highest number of dependencies is devel/mingw32-gcc, but this seems >>> to be due to a problem with makeinfo, not clang. The next highest = on >>> the list is java/openjdk6, for which ports r374780 [4] was very >>> recently committed. >>=20 >> Will users of our stable branch have code similar to the code that = caused >> problems? >=20 > I'm not sure which code you are referring to here, the openjdk6 code? > The code itself is basically fine, but for reasons unknown to me, the > port is compiled with -Werror (which is not the case for the other > openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings > for shaky C++ constructions, these appear during the openjdk6 build, = but > they are easily suppressed, if upstream does not fix them, or does not > care to fix them. I meant =E2=80=9Csimilar code to what=E2=80=99s causing problems=E2=80=9D = with the build run in their code they build on FreeBSD. If it is a few new warnings for obscure = things, we can advice to the release notes about what to avoid and how to = mitigate things. > I already sent Jung-uk an alternative fix for openjkd6, similar to the > one used for www/squid, where warnings are suppressed based on the > COMPILER_VERSION variable provided the ports infrastructure. In my > opinion it would still be easier to just to turn off -Werror for any > third-party code, if we don't feel like modifying it (with all the = risks > involved). Yea, we can sort out the code in src and ports. I=E2=80=99m more worried = about what to tell our users that may be compiling their own code that we = don=E2=80=99t control. If these new warnings are ubiquitous, then that could be a = problem for adoption (since many shops mandate -Werror as much as possible, and to comply with that mandate would require additional resources when = trying to upgrade). If there are a few, then we could just document them and = move on. >> One warning flag about your upgrade to the stable branch >> would be if there=E2=80=99s a significant number of user-written = programs that >> suddenly become uncompilable with the new clang using the environment >> that they have today. We know of some items that are issues, so = careful >> attention here is needed. Unless we go proactively looking for these, >> there=E2=80=99s a good chance we won=E2=80=99t find them until users = hit them and start >> to complain (by which point it is likely too late). Could you post a = summary >> of the issues that ports have hit and the fixes necessary? We may = need >> to have that in the release notes and/or UPDATING file to help = prepare >> our users for the bumps and give them solutions over them. >=20 > The base system is already completely free of warnings, as far as I = know > of, so no action is needed there. For ports, the number of failures > introduced by new warnings are quite small, as far as I can see, and > mostly for ports that are compiled with -Werror. Yea, I wasn=E2=80=99t too worried about this aspect of things. > The most encountered new warnings are, off the top of my head: >=20 > -Wabsolute-value >=20 > This warns in two cases, for both C and C++: > * When the code is trying to take the absolute value of an unsigned > quantity, which is effectively a no-op, and almost never what was > intended. The code should be fixed, if at all possible. > * When the code is trying to take the absolute value, but the called > abs() variant is of the wrong type, which may lead to truncation. > If the warning is turned off, better make sure any truncation does > not lead to unwanted side-effects. >=20 > -Wtautological-undefined-compare and > -Wundefined-bool-conversion >=20 > These warn when C++ code is trying to compare 'this' against NULL, = while > 'this' should never be NULL in well-defined C++ code. However, there = is > some legacy (pre C++11) code out there, which actively abuses this > feature, which was less strictly defined in previous C++ versions. >=20 > Squid does this, and apparently openjdk too. The warning can be = turned > off for C++98 and earlier, but compiling the code in C++11 mode might > result in unexpected behavior, for example the unreachable parts of = the > program could be optimized away. This is the kind of information I was talking about. Do we have a = process to make sure this gets into the release notes? >> I would really like to merge this branch to head in about a week, >>> pending portmgr approvall; I don't expect the base system (outside = of >>> llvm/clang) to need any further updates. >>=20 >> I think there=E2=80=99s good reason to do this, but we should chat = about the >> build issues below before doing it. They are minor, but an important >> detail. I=E2=80=99ll see if I can find a few minutes to pull the = branch and send >> patches. >>=20 >>> Lastly, to clear things up about the requirements for this branch = (and >>> thus for head, in a while); to build it, you need to have: >>> * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >>>> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) >>> * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >>>=20 >>> So from any earlier standard 10.x or 11.x installation, you should = be >>> good, unless you explicitly disabled clang or libc++. In that case, >>> you must build and install both of those first. >>=20 >> This is true only on i386, amd64, and arm hosts. Given that some = people >> do try to do weird things, tightening up how you present this will = get the >> word out a little better. >>=20 >>> On a 9.x installation, you will have clang by default, but not = libc++, >>> so libc++ should be built and installed first, before attempting to >>> build the clang350-import branch. >>=20 >> Can you make sure that the UPDATING entry you are writing for this >> contains explicit instructions. >=20 > I'm quite bad at writing UPDATING entries, so any help there is much > appreciated. :-) I=E2=80=99m happy to help with this, but I work best from a rough draft = ... >> On 8.x an earlier, you need to upgrade to at least 9.x first, follow >>> the previous instruction. >>=20 >> We should remove building on 8 support then, unless there external >> toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, = etc). >=20 > The problem with 8.x is that it still has the old binutils 2.15, and > neither clang nor libc++. It would really require some externally > supplied parts. Maybe this could be done with ports, but I'm not sure > how long ports still supports the 8.x branch? If we can=E2=80=99t bootstrap from an 8.x system and have it work, we = need to remove support for doing that from Makefile.inc1 and friends. If we = think we can still support it with the external tool chain stuff, or with the = =E2=80=98end goal=E2=80=99 for the external toolchain stuff, we should leave it in. = At this point, I think it would be best to add a .warning for 8.x saying this isn=E2=80=99= t supported without an external toolchain, and then a month out from the branch = point we can decide what to do. 8.x is supported through the summer, iirc, on ports. Right now, for example, we say if the host is < 8.0 then we = don=E2=80=99t support it. I=E2=80=99ll add something that says if the host is < = 9 then bootstrapping clang won=E2=80=99t work, but I won=E2=80=99t make it an error just yet = and send it to you for your branch. >>> As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while >>> (roughly a month), but this will cause upgrades from 9.x to 10.x to >>> start requiring the build of libc++, as described above. I don't = think >>> we can merge clang 3.5.x to 9.x, unless clang becomes the default >>> compiler there (but that is very unlikely). >>=20 >> Let=E2=80=99s see how it goes, and what the upgrade issues wind up = being >> before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers = on stable branches >> traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly >> identical to prior releases than gcc was, it might not have the same = issues >> associated with it. >=20 > We don't really use llvm or clang's own ABI for anything at the = moment, > just the resulting compiler executable, which is actually one big = binary > (and it is even statically linked, by default). Right, this isn=E2=80=99t what I=E2=80=99m worried about... > The code output by clang 3.4.1 or 3.5.0 is not different in any "ABI" > sense of the word. Of course it will be different in absolute sense, > since optimizations were improved, and so on. This is what I=E2=80=99m worried about given our past experiences with = updating compilers. If we believe there=E2=80=99s no issues here, we can tick = that box but it was traumatic enough the last time we tried this (admittedly with gcc) that I have to ask. Similar representations were made, though it turned out people forgot to ask =E2=80=9Cincluding C++=E2=80=9D until = people noticed that it failed in some cases and started asking=E2=80=A6 > The only real issue is how to bootstrap the compiler itself, since it > requires working C++11 support. In 10.x, we provide that by default, > but not in earlier releases. Yea, that=E2=80=99s something we can document with release notes. Cool! Thanks for taking the time to address my concerns. Warner --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUk0dNAAoJEGwc0Sh9sBEAmUwP/jomM0zYSx9Pn+idgoLi8od8 l/e3bSMwuQcG8jZK+O7XkH+HFPMeDHRJUbFnr3TbnkHhxJIra5x7dOr0BArwzSDW vA1XwBNYcYsUQcgIlLNZ6KLOWmJoyTc8MVoEZPveVqVIyQwCHxHockm1Sl/jdkay fQMtnjES9ToBtpp4tqEFz/kb2hD4V1jJi90CXBdnAvzb2sFAQGZroSpIATo1n+0I XCUo8v1D/28T5xpapD4KUO3hqLc/UOeuozcEi/gBltix5e8xOCkVHyg9pGkiwJ9h 44J2o7k75LWPMZ9T52sCPFtc0F8RAKLcw1pSjRwfN9chCLirx1qnOBJwUmRH863Z X3Im4zDstU5rJhD4Dejsbals308oqyvjyLwS1nvdhReRbXajrj8O3F0UazWTB3cl oOEByTILaN5yrNdw5Y0WF8rPhP4cNQTKAyPv6BFolWW8fbPe8N573DbLbaZpQuX+ 41ppg/dkuV0FEQSVXFL70qZpKA1dRvnE2gBVxNaY5UTLr2urMDpR1ncvmqEVB65y E4qtgCPA9bSx0FPbajPHH8cO2KfK7T/DpHZlTmFLQ8ELWaPu1Vb6sY6mFTJ/es6V y5F4UzwwLsPZdxL/zedpK5J3DtU2tz+mM404267T7lRNOIFupGpZM4iSS0owXcQ+ yoxSQXZj5E1Z+/SMvK+S =ZvMz -----END PGP SIGNATURE----- --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4-- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 21:33:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63EADFA1 for ; Thu, 18 Dec 2014 21:33:05 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C55A28FE for ; Thu, 18 Dec 2014 21:33:04 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id fp1so2198452pdb.5 for ; Thu, 18 Dec 2014 13:33:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=sfdp6hX7rYu9F+ns2uUe1hpK43iBlxUG3iDqMNSo0iw=; b=XgQ5LzdXOfVCvTWVyH2sYSgK7PXq2TVshql6n306jAFMtp6tV5CMlXHUs/VVTQ7TV+ CdMnWNOqjXh39GoyDsAxDIWj9Jpdp/jjiB8vWKYvdbg0KOCJ0IloA1Z/husxHtK9KEms pIvvgzHSKVpO3orOqasDzLU9VpU4NPVOeE3DXEUG1LkHG44v0EVDkUPf6DMDj9Cz081J pohl5lNzhFY2ePH5Bjt/Z8OZDOEUmXSxXi9Tj8WxODc2ZiieQfSGc/oaZ2ssSo+YtO15 9Olbj79WhoDnxHBgFh9RnzGOEzT+3KRu1tu+PjzeGE/v6OaHyR0tdjOgfLUDuN0iHjQG pnbw== X-Gm-Message-State: ALoCoQm2x4R59by78jz9/8nwpZe2SOZ7SgR70f6Y6AwichfOXdOCw8lM4BarD+5Wq2VN2fdITkf6 X-Received: by 10.70.42.172 with SMTP id p12mr7124521pdl.66.1418938384482; Thu, 18 Dec 2014 13:33:04 -0800 (PST) Received: from [10.64.25.114] ([69.53.236.236]) by mx.google.com with ESMTPSA id cm10sm7670846pad.46.2014.12.18.13.33.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 13:33:03 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A5CA1A93-A6F5-47F0-A106-C200CAC64F54"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <18CDB8BF-C24E-442D-8904-5DB777E64A62@gmail.com> Date: Thu, 18 Dec 2014 14:33:01 -0700 Message-Id: <68DB489E-7345-4D94-9CE6-44A003D4B326@bsdimp.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <21650.55288.425711.209975@jerusalem.litteratus.org> <9D9850F8-62D6-4A85-BED3-1B4AB4DE5C14@bsdimp.com> <18CDB8BF-C24E-442D-8904-5DB777E64A62@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , Robert Huff , Dimitry Andric , FreeBSD ports , FreeBSD-Current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 21:33:05 -0000 --Apple-Mail=_A5CA1A93-A6F5-47F0-A106-C200CAC64F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Dec 18, 2014, at 2:17 PM, Garrett Cooper = wrote: >=20 > On Dec 18, 2014, at 6:51, Warner Losh wrote: >=20 >> With the recent parallelism work, the is true. It might save a couple = percent >> off the build time. Before those changes, though, disabling all non = target >> arches saved about 10% of the buildworld time. >=20 > I=92m curious. How much is 10% in terms of minutes and with what -j = value? That depends on how long the build takes. For my 20 minute builds it was = about 2 minutes faster. At the time, -j didn=92t really effect build times = once you got north of 4 because parallelism really sucked. Now it doesn=92t suck and it = scales much better and I suspect that the time savings would be tiny because it = would be done at the same time as other things anyway, but I=92ve not measured it = directly. >> Creating a hack to do this is easy (which is how I measured it). But = Dimitry >> is right that creating a robust solution is hard. Even harder if you = want it >> to be completely clean. >=20 > It didn=92t seem incredibly hard =97 it just required a bit more = =93generated files=94 in clang AFAICT. I=92ll hang ten until clang35 is = in so I can re-asses what=92s going on with building it. Yea, and that file generation is a pita, or I=92d have committed my changes a while ago... >> I tend to agree. IMHO, supporting the work going on to bring the >> meta-mode stuff will pay far higher dividends than optimizing this >> corner of the build. >=20 > True=85 probably will! Yea, this isn=92t a problem worth solving today. Warner --Apple-Mail=_A5CA1A93-A6F5-47F0-A106-C200CAC64F54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUk0gNAAoJEGwc0Sh9sBEACCoQAMgYuu6g/pPHLcpndN8/cKjv g44ubOsyG8i+1ahZnP/bCGUdDRw9QitdwhV5WLktELlecYALccwPGoyiqlBg6vdt sJ/lKgDVSL0CKOhyUpPvfugB9D6qt3E1oQvqgIQ4iroxI/VeybFpPyBi0LS3L2oU +M6eSNgQWmFotss/MGHIN+6xygsQyxCskO6ft5qaOg/Vam60QrzMfcbQX/50EBZG opl8tpj8tqOuq0FZHbgPxpH6DNWrdyMzXL38yT0xQWUXtgH7OHr4n9xap6oD7iTy Nou9SwSFEEB7WJ3zgRPgg1HmASYMkHPUD7oQh7bn3OIfr777jQtBpS1z0CAdTvgW XHl4cIWuETI/5fo8aMdOj4IdMJTqnqr9M4Nelk4FYeBohp71Id0CZmUk5dSEeoam WY5mfIMgjkmxcz4oqHwJhpblVDyVQ7364wjBdanUX3Mwhv7u88NXce6K9W6T+2j9 sc5nVaDLQTUKnHAdjh7GmZcGv3SFMwMkBsu7dqipvWkK8a7HbxU1k5tggq+mdVdK USW9I7KRM+05Bqx1I6m2W5/iBQ6BmIbY0z9hdA5c0dEL/0WDgf5uuV2sHp3te2hZ g39Z1tb/Bx1axOj37ahnfsMurVSAoptO2BpgXbCnc87CsgNl24m0Z+zNdZou3moA uAYq7Xjw2xfwibX98mJC =2YY7 -----END PGP SIGNATURE----- --Apple-Mail=_A5CA1A93-A6F5-47F0-A106-C200CAC64F54-- From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 00:12:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A19C9D; Fri, 19 Dec 2014 00:12:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B5EEB2257; Fri, 19 Dec 2014 00:12:44 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sBJ0CfUV078928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 16:12:42 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sBJ0CfC9078927; Thu, 18 Dec 2014 16:12:41 -0800 (PST) (envelope-from jmg) Date: Thu, 18 Dec 2014 16:12:41 -0800 From: John-Mark Gurney To: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <20141219001241.GW25139@funkthat.com> Mail-Followup-To: Warner Losh , Dimitry Andric , FreeBSD ARM , FreeBSD-Current , portmgr@freebsd.org, FreeBSD ports , FreeBSD toolchain References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 18 Dec 2014 16:12:42 -0800 (PST) Cc: FreeBSD-Current , Dimitry Andric , FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 00:12:45 -0000 Warner Losh wrote this message on Thu, Dec 18, 2014 at 07:47 -0700: > This is excellent news Dimitry! > > > On Dec 16, 2014, at 12:36 PM, Dimitry Andric wrote: > > > > On 28 Nov 2014, at 22:03, Dimitry Andric wrote: > >> > >> We're working on updating llvm, clang and lldb to 3.5.0 in head. This > >> is quite a big update again, and any help with testing is appreciated. > >> > >> To try this out, ensure you have good backups or snapshots, then build > >> world and kernel from the projects/clang350-import branch [1]. Please > >> use a Subversion mirror [2], if you are able to. > > > > Here are some updates about the status of the 3.5.0 import. > > > > * i386 and amd64 have been tested through make universe, and everything > > should compile and run. > > * Little-endian ARM builds should now compile and run, thanks to Andrew > > Turner for putting in lots of work. > > * Big-endian ARM is apparently supposed to work, but I'm not sure if > > Andrew managed to test it on real hardware. > > I know Andrew doesn???t have the right arm gear to do this test, and emulation > environments that run FreeBSD have had poor big-endian support for arm. I have a board that I plan to test on shortly... If Andrew would like, I know Jim Thompson has a standing offer to send board(s) to people who will test it... He provided me w/ the board I will be testing on soon... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 05:42:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D96B2645; Fri, 19 Dec 2014 05:42:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8897329E5; Fri, 19 Dec 2014 05:42:32 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sBJ5gUMx002810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 21:42:31 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sBJ5gUSA002809; Thu, 18 Dec 2014 21:42:30 -0800 (PST) (envelope-from jmg) Date: Thu, 18 Dec 2014 21:42:30 -0800 From: John-Mark Gurney To: Dimitry Andric Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <20141219054230.GA1396@funkthat.com> Mail-Followup-To: Dimitry Andric , FreeBSD-Current , FreeBSD ARM , FreeBSD toolchain , FreeBSD ports , portmgr@freebsd.org References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 18 Dec 2014 21:42:31 -0800 (PST) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@freebsd.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 05:42:33 -0000 Dimitry Andric wrote this message on Tue, Dec 16, 2014 at 20:36 +0100: > * Big-endian ARM is apparently supposed to work, but I'm not sure if > Andrew managed to test it on real hardware. hmmm... I can't get it to compile... Maybe I'm missing something... I tried to do: # make buildworld TARGET_ARCH=3Darmeb WITH_BOOTSTRAP_CLANG=3D WITH_CLANG=3D= WITHOUT_GCC=3D WITHOUT_BOOTSTRAP_GCC=3D This is from an amd64 host, though it is a month or two out of date... But it ended w/: c++ -O -pipe -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/include -= I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/a/= src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. = -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include = -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MA= CROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armeb-gnueabi-fr= eebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"armeb-unknown-freebsd11.0\" -DDEFAULT_SY= SROOT=3D\"\" -fno-exceptions -fno-rtti -static -o clang cc1_main.o cc1as= _main.o driver.o /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/= clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/arm.armeb/a/src/= usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a = /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangdri= ver/libclangdriver.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../= lib/clang/libclangserialization/libclangserialization.a /usr/obj/arm.armeb/= a/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodege= n.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclan= gparse/libclangparse.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../.= ./lib/clang/libclangsema/libclangsema.a /usr/obj/arm.armeb/a/src/usr.bin/cl= ang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/a= rm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangedit/libclang= edit.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libc= langast/libclangast.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../..= /lib/clang/libclangbasic/libclangbasic.a /usr/obj/arm.armeb/a/src/usr.bin/c= lang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/arm.armeb/= a/src/usr.bin/clang/clang/../../../lib/clang/libllvmoption/libllvmoption.a = /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmlink= er/libllvmlinker.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../li= b/clang/libllvmirreader/libllvmirreader.a /usr/obj/arm.armeb/a/src/usr.bin/= clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/arm.armeb/a= /src/usr.bin/clang/clang/../../../lib/clang/libllvmvectorize/libllvmvectori= ze.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllv= minstrumentation/libllvminstrumentation.a /usr/obj/arm.armeb/a/src/usr.bin/= clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj= /arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/li= bllvmbitreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/= clang/libllvmasmparser/libllvmasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/= clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassemble= r.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvm= armcodegen/libllvmarmcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang= /../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/arm.= armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdesc/libllvmar= mdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/lib= llvmarminfo/libllvmarminfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/.= ./../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/ar= m.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdisassemble= r/libllvmmipsdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/..= /../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/arm.armeb= /a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmparser/libllvmm= ipsasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/cl= ang/libllvmmipsdesc/libllvmmipsdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clan= g/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/arm.a= rmeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinstprinter/li= bllvmmipsinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../.= ./lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/obj/arm.arme= b/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmparser/libl= lvmpowerpcasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../..= /lib/clang/libllvmpowerpcdesc/libllvmpowerpcdesc.a /usr/obj/arm.armeb/a/src= /usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcin= fo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllv= mpowerpcinstprinter/libllvmpowerpcinstprinter.a /usr/obj/arm.armeb/a/src/us= r.bin/clang/clang/../../../lib/clang/libllvmsparcdisassembler/libllvmsparcd= isassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/cla= ng/libllvmsparccodegen/libllvmsparccodegen.a /usr/obj/arm.armeb/a/src/usr.b= in/clang/clang/../../../lib/clang/libllvmsparcasmparser/libllvmsparcasmpars= er.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllv= msparcdesc/libllvmsparcdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/= ../../../lib/clang/libllvmsparcinfo/libllvmsparcinfo.a /usr/obj/arm.armeb/a= /src/usr.bin/clang/clang/../../../lib/clang/libllvmsparcinstprinter/libllvm= sparcinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../li= b/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/obj/arm.armeb/= a/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86= asmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang= /libllvmx86codegen/libllvmx86codegen.a /usr/obj/arm.armeb/a/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/= obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinte= r/libllvmasmprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../..= /lib/clang/libllvmmcparser/libllvmmcparser.a /usr/obj/arm.armeb/a/src/usr.b= in/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/obj/= arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmobjcarcopts/l= ibllvmobjcarcopts.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../l= ib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/obj/arm.armeb/a/src/usr= .bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a= /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmtra= nsformutils/libllvmtransformutils.a /usr/obj/arm.armeb/a/src/usr.bin/clang/= clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/obj/arm.armeb/a/src/u= sr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /us= r/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86desc= /libllvmx86desc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib= /clang/libllvmx86info/libllvmx86info.a /usr/obj/arm.armeb/a/src/usr.bin/cla= ng/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a /usr/obj/arm.arme= b/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86instprinter/libllv= mx86instprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib= /clang/libllvmmc/libllvmmc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/.= ./../../lib/clang/libllvmobject/libllvmobject.a /usr/obj/arm.armeb/a/src/us= r.bin/clang/clang/../../../lib/clang/libllvmx86utils/libllvmx86utils.a /usr= /obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/lib= llvmcore.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/= libllvmsupport/libllvmsupport.a -lncursesw /usr/obj/arm.armeb/a/src/tmp/usr/lib/crt1.o: In function `__start': crt1.c:(.text+0xb4): relocation truncated to fit: R_ARM_CALL against symbol= `atexit' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/= libc.a(atexit.o) crt1.c:(.text+0xbc): relocation truncated to fit: R_ARM_CALL against symbol= `_init_tls' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/l= ib/libc.a(tls.o) crt1.c:(.text+0xc4): relocation truncated to fit: R_ARM_CALL against symbol= `atexit' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/= libc.a(atexit.o) crt1.c:(.text+0x164): relocation truncated to fit: R_ARM_CALL against symbo= l `exit' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/l= ibc.a(exit.o) /usr/obj/arm.armeb/a/src/tmp/usr/lib/crt1.o: In function `finalizer': crt1.c:(.text+0x1d4): relocation truncated to fit: R_ARM_CALL against symbo= l `_fini' defined in .fini section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/= crti.o cc1_main.o: In function `__static_initialization_and_destruction_0(int, int= )': cc1_main.cpp:(.text+0xdc): relocation truncated to fit: R_ARM_CALL against = symbol `getenv' defined in .text section in /usr/obj/arm.armeb/a/src/tmp/us= r/lib/libc.a(getenv.o) cc1_main.cpp:(.text+0x2c4): relocation truncated to fit: R_ARM_CALL against= symbol `std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)' defined in .t= ext._ZNSsC1EPKcRKSaIcE[_ZNSsC1EPKcRKSaIcE] section in /usr/obj/arm.armeb/a/= src/tmp/usr/lib/libstdc++.a(string-inst.o) cc1_main.cpp:(.text+0x374): relocation truncated to fit: R_ARM_JUMP24 again= st symbol `__gnu_cxx::__exchange_and_add(int volatile*, int)' defined in .t= ext._ZN9__gnu_cxx18__exchange_and_addEPVii section in /usr/obj/arm.armeb/a/= src/tmp/usr/lib/libstdc++.a(atomicity.o) cc1_main.cpp:(.text+0x388): relocation truncated to fit: R_ARM_JUMP24 again= st symbol `std::string::_Rep::_M_destroy(std::allocator const&)' defi= ned in .text._ZNSs4_Rep10_M_destroyERKSaIcE[_ZNSs4_Rep10_M_destroyERKSaIcE]= section in /usr/obj/arm.armeb/a/src/tmp/usr/lib/libstdc++.a(string-inst.o) cc1_main.cpp:(.text+0x3a0): relocation truncated to fit: R_ARM_CALL against= symbol `std::basic_string, std::allocator >::basic_string(char const*, std::allocator const&)' defined in .t= ext._ZNSsC1EPKcRKSaIcE[_ZNSsC1EPKcRKSaIcE] section in /usr/obj/arm.armeb/a/= src/tmp/usr/lib/libstdc++.a(string-inst.o) cc1_main.cpp:(.text+0x44c): additional relocation overflows omitted from th= e output *** Error code 1 Stop. make[5]: stopped in /a/src/usr.bin/clang/clang *** Error code 1 Stop. make[4]: stopped in /a/src/usr.bin/clang *** Error code 1 Stop. make[3]: stopped in /a/src/usr.bin *** Error code 1 Stop. make[2]: stopped in /a/src *** Error code 1 Stop. make[1]: stopped in /a/src *** Error code 1 Stop. make: stopped in /a/src --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 02:23:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53566E79 for ; Sat, 20 Dec 2014 02:23:12 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D49482BD8 for ; Sat, 20 Dec 2014 02:23:11 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so2749854wgh.18 for ; Fri, 19 Dec 2014 18:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=AsKUX1RE7brIb1lNR+gyQykgUdZc2bD21N9NX5zmqn8=; b=W3kZhgiC5nBlqdQD2ekqlQ8cgr9nq49Iner9QyQscOIY2qa9YbdTJ1oHjLi04EOebY s5twKxOmud69LDQ9fuFapbMOOZolEDIaw+IgEj/W8thft8es6u3Pl2JhtjxjnagZHFxW OJJscN62t5YW8d30ytbZ2S3eNBhmwAWhWrcaHUHCO2wLpGMV4Rv02kgiz732yEAO5qTX ynd13ErcmV2JicHPtkEKvEnUn4z8SxFtrO5u3t7Kx4cCJcdSxWKUEFNwMrktxqhMNeTG Lj4CqCFriSoyJxpkTd+PSB1UbcX53NpcwhYpQQjxwQ1tgdE7M1sbIXQjepACjY9Ywcfo Cnaw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr20834867wjz.20.1419042189513; Fri, 19 Dec 2014 18:23:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Fri, 19 Dec 2014 18:23:09 -0800 (PST) Date: Fri, 19 Dec 2014 18:23:09 -0800 X-Google-Sender-Auth: KTwG1W7vvRck5B0uJx82DIAotCY Message-ID: Subject: trying to build crochet/freebsd-head raspberry pi From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 02:23:12 -0000 hiya! i'm trying to build an updated -head r-pi image, and I'm hitting problems again. I've updated to the latest crochet from tim's github. Then I run it, and it says to run this: make XDEV=arm XDEV_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 WITHOUT_TESTS=1 xdev so I do, and this happens: ===> gnu/usr.bin/binutils/libbinutils (all) ===> gnu/usr.bin/binutils/addr2line (all) cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=32 -I. -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/../libbfd -I/home/adrian/work/freebsd/head/obj/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/../libbfd -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/../../../../contrib/binutils/include -D_GNU_SOURCE -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/../libbinutils -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/../../../../contrib/binutils/binutils -std=gnu99 -fstack-protector -Qunused-arguments -o addr2line addr2line.o ../libbinutils/libbinutils.a ../libbfd/libbfd.a ../libiberty/libiberty.a ../libbfd/libbfd.a(targets.o):(.data+0x10): undefined reference to `bfd_elf64_x86_64_freebsd_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x0): undefined reference to `bfd_elf64_x86_64_freebsd_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x8): undefined reference to `bfd_elf64_x86_64_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x10): undefined reference to `bfd_efi_app_x86_64_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x18): undefined reference to `bfd_elf32_i386_freebsd_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x20): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x28): undefined reference to `bfd_efi_app_ia32_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0xc8): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0xd8): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0xe8): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0xf8): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x108): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x118): more undefined references to `bfd_elf32_i386_vec' follow ../libbfd/libbfd.a(targets.o):(.rodata+0x148): undefined reference to `bfd_elf32_i386_freebsd_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x178): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x188): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x198): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x1a8): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x1b8): undefined reference to `bfd_elf64_x86_64_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x1d8): undefined reference to `bfd_elf64_x86_64_freebsd_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x1f8): undefined reference to `bfd_elf64_x86_64_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x208): undefined reference to `bfd_elf64_x86_64_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x218): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x228): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x238): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x258): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x268): undefined reference to `bfd_elf32_i386_vec' ../libbfd/libbfd.a(targets.o):(.rodata+0x278): more undefined references to `bfd_elf32_i386_vec' follow ../libbfd/libbfd.a(archures.o): In function `bfd_scan_arch': /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text+0x2e): undefined reference to `bfd_i386_arch' ../libbfd/libbfd.a(archures.o): In function `bfd_arch_list': /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text+0x75): undefined reference to `bfd_i386_arch' /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text+0x9d): undefined reference to `bfd_i386_arch' ../libbfd/libbfd.a(archures.o): In function `bfd_default_set_arch_mach': /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text+0x5e7): undefined reference to `bfd_i386_arch' ../libbfd/libbfd.a(archures.o): In function `bfd_lookup_arch': /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text+0x665): undefined reference to `bfd_i386_arch' ../libbfd/libbfd.a(archures.o):/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text+0x705): more undefined references to `bfd_i386_arch' follow cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 ... is that known? -adrian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 15:53:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED443F49 for ; Sat, 20 Dec 2014 15:53:40 +0000 (UTC) Received: from server949-han.de-nserver.de (server949-2-han.de-nserver.de [77.75.250.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 540041F40 for ; Sat, 20 Dec 2014 15:53:39 +0000 (UTC) Received: (qmail 340 invoked from network); 20 Dec 2014 16:53:30 +0100 X-Fcrdns: Yes Received: from dslb-094-218-027-243.094.218.pools.vodafone-ip.de (HELO midgard.local) (94.218.27.243) (smtp-auth username konstantin@schukraft.org, mechanism plain) by server949-han.de-nserver.de (qpsmtpd/0.92) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Sat, 20 Dec 2014 16:53:30 +0100 Message-ID: <54959B6E.3090505@schukraft.org> Date: Sat, 20 Dec 2014 16:53:18 +0100 From: Konstantin Schukraft User-Agent: "" MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Pandaboard: problems with some kernel modules References: <548F6CB9.7020205@schukraft.org> In-Reply-To: <548F6CB9.7020205@schukraft.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-User-Auth: Auth by konstantin@schukraft.org through 94.218.27.243 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 15:53:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Addendum: some other modules that can't be loaded after being successfully built and installed are if_bridge, ipfw{,_nat}, cpufreq. The latter I don't really care about, but missing bridge and ipfw support means no vnet in jails. Konstantin On 12/16/2014 00:20, Konstantin Schukraft wrote: > Hi, > > I'm running 10.1-RELEASE on a Pandaboard as a home server, and > while most of it works great, I have some problems with some kernel > modules. geom_eli compiles and installs (make and make install) > fine, but loading it, no matter whether I use the full path or not, > always errors out with "kldload: can't load geom_eli: No such file > or directory" although it is there: > root@panda:/usr/src/sys/modules/geom/geom_eli # ls /boot/kernel/ > fdescfs.ko geom_bde.ko geom_eli.ko geom_label.ko > kernel kernel.gz.tramp kernel.symbols linker.hints nullfs.ko > procfs.ko > > The other selfbuild modules you can see here load just fine. > > opensolaris and zfs can't even be build, both error out with In > file included from > /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris.c:32: > > /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/sys/cpuvar.h:53:9: > error: 'cpu_id' macro redefined [-Werror] #define cpu_id cpuid ^ > ./machine/cpufunc.h:178:9: note: previous definition is here > #define cpu_id() cpufuncs.cf_id() ^ 1 error > generated. *** Error code 1 > > Anyone having geli encryption or ZFS working on a Pandaboard? > > > Thanks, > > Konstantin -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJUlZtqAAoJEH3raMNeVmMFt7gP+QEpnChTnhwLvGqT+7/CCsCi wOeSyyk1GZnaK8/PRS+41d/oL35AiylGs/shqQGuKDKOb1MHEe3MK6Gt5eVydpjY hhHpzCMbyfpQveVkeUZopyGKXSzQMuD0IS6jN2h/gJqBiEme8F3CXm7BjF/a/BI5 3weA2gWkOhiUAOsoAWg1ON5qozhgpy0MJi7PM4ckYDUv1NYI+Agi5NRXJIaoThLM aOn+hY6p1atRDHiHHSNr4AtA5MgtW7S6bx1j3r755dCX9LscXMKUgra1hPyBm9I9 nc7eGr50TzTYRbUyuUY2UueAVphFBvyX0pLmrjTL4WuUSwpNqmw0VOzXYFF7PwlG /G0z0HfwD7qawi7TVSSSURnc3y3h9dEUjW1iGIG09mdPqI+VWpNHYGF3tCc8vwG7 7OKM0ViOsLWfS6o2p2Bo/QbqgJ5tMTKqyGz61iz7npynxq/1ajVKOTCGgWBnuC42 D3TETNBSiAa7uQg0CnltKABxEnTTaBR5UGPQ1O9DLye0m98pZG4WI9kbzWo3vnxf zYlYe/7q6EylH+YFb0JBFC61m/v4Pq/kWYly9mGkGMTj9LoJI24l416ikDahZaQ9 vRjsH2dsxbdGvHsGPK3P4t49zfLow9qA85eMEkn77jAtgsPHjqcJs+A3ePXTFPR5 R2UQJIy44vxKbg9Mzk6y =dSOJ -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 17:25:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A94DD6 for ; Sat, 20 Dec 2014 17:25:25 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC3F02F18 for ; Sat, 20 Dec 2014 17:25:24 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id et14so3195172pad.15 for ; Sat, 20 Dec 2014 09:25:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=bPtWgeh2MnXn9n5Ozng5eTGD1b7c00A7Wbw8mriDii4=; b=OX8ed5dAADOJkSRthj1mmigPcsPMpjwfOD7oxu+tKc256egRxVpYtrbNFTCfB0hi47 fUnQz0Xn1gVPVnUjcJRpM0b0DwqQ6T+v7crA8j9FpcVZYRSrEG9I/P7QmLcBUxQTtl8n WdNzs4DqE94sAcUg6jEnrAKlPH06PWD31lEAEcPaOzmLgHbfZ7ExnC34kWDnz6fsmK/d YOEunzpapmp9PPE0YnvvYhRY4jc4QPOsiq4nt+Iyglaw02NfqXDNWk5CgNZLgbGSqA6H 9HObQAxr2OiViLksWeGpywotxnOaKacRmZgDIYt6TPsCxoFXp4Z7FuJLkSS3Y5VWgYYm BmGw== X-Gm-Message-State: ALoCoQlxwxbrYJ4QNmU+A5qT2bwd9OD3X9Nu1X9x3OJvuvVzPEgmZ0UXInPkwu67js8xLWdaB5a+ X-Received: by 10.70.45.17 with SMTP id i17mr21978572pdm.13.1419096317768; Sat, 20 Dec 2014 09:25:17 -0800 (PST) Received: from [10.64.25.114] ([69.53.236.236]) by mx.google.com with ESMTPSA id vb4sm13014346pab.19.2014.12.20.09.25.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Dec 2014 09:25:17 -0800 (PST) Sender: Warner Losh Subject: Re: trying to build crochet/freebsd-head raspberry pi Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C6A6B1B5-30F7-4CD3-9846-7621B3A08024"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Sat, 20 Dec 2014 10:25:13 -0700 Message-Id: <22621F71-5049-452C-AB8B-403E365C325D@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1993) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 17:25:25 -0000 --Apple-Mail=_C6A6B1B5-30F7-4CD3-9846-7621B3A08024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 19, 2014, at 7:23 PM, Adrian Chadd wrote: >=20 > hiya! >=20 > i'm trying to build an updated -head r-pi image, and I'm hitting = problems again. >=20 > I've updated to the latest crochet from tim's github. >=20 > Then I run it, and it says to run this: >=20 > make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC=3D1 WITH_GCC_BOOTSTRAP=3D1 > WITHOUT_CLANG=3D1 WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG_IS_CC=3D1 > WITHOUT_TESTS=3D1 xdev >=20 > so I do, and this happens: >=20 > =3D=3D=3D> gnu/usr.bin/binutils/libbinutils (all) > =3D=3D=3D> gnu/usr.bin/binutils/addr2line (all) > cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=3D32 -I. > = -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line > = -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/..= /libbfd > = -I/home/adrian/work/freebsd/head/obj/usr/home/adrian/work/freebsd/head/src= /gnu/usr.bin/binutils/addr2line/../libbfd > = -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/..= /../../../contrib/binutils/include > -D_GNU_SOURCE = -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/..= /libbinutils > = -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/..= /../../../contrib/binutils/binutils > -std=3Dgnu99 -fstack-protector -Qunused-arguments -o addr2line > addr2line.o ../libbinutils/libbinutils.a ../libbfd/libbfd.a > ../libiberty/libiberty.a > ../libbfd/libbfd.a(targets.o):(.data+0x10): undefined reference to > `bfd_elf64_x86_64_freebsd_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x0): undefined reference to > `bfd_elf64_x86_64_freebsd_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x8): undefined reference to > `bfd_elf64_x86_64_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x10): undefined reference to > `bfd_efi_app_x86_64_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x18): undefined reference to > `bfd_elf32_i386_freebsd_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x20): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x28): undefined reference to > `bfd_efi_app_ia32_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0xc8): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0xd8): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0xe8): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0xf8): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x108): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x118): more undefined > references to `bfd_elf32_i386_vec' follow > ../libbfd/libbfd.a(targets.o):(.rodata+0x148): undefined reference to > `bfd_elf32_i386_freebsd_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x178): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x188): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x198): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x1a8): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x1b8): undefined reference to > `bfd_elf64_x86_64_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x1d8): undefined reference to > `bfd_elf64_x86_64_freebsd_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x1f8): undefined reference to > `bfd_elf64_x86_64_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x208): undefined reference to > `bfd_elf64_x86_64_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x218): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x228): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x238): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x258): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x268): undefined reference to > `bfd_elf32_i386_vec' > ../libbfd/libbfd.a(targets.o):(.rodata+0x278): more undefined > references to `bfd_elf32_i386_vec' follow > ../libbfd/libbfd.a(archures.o): In function `bfd_scan_arch': > = /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../.= ./../contrib/binutils/bfd/archures.c:(.text+0x2e): > undefined reference to `bfd_i386_arch' > ../libbfd/libbfd.a(archures.o): In function `bfd_arch_list': > = /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../.= ./../contrib/binutils/bfd/archures.c:(.text+0x75): > undefined reference to `bfd_i386_arch' > = /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../.= ./../contrib/binutils/bfd/archures.c:(.text+0x9d): > undefined reference to `bfd_i386_arch' > ../libbfd/libbfd.a(archures.o): In function = `bfd_default_set_arch_mach': > = /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../.= ./../contrib/binutils/bfd/archures.c:(.text+0x5e7): > undefined reference to `bfd_i386_arch' > ../libbfd/libbfd.a(archures.o): In function `bfd_lookup_arch': > = /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../../.= ./../contrib/binutils/bfd/archures.c:(.text+0x665): > undefined reference to `bfd_i386_arch' > = ../libbfd/libbfd.a(archures.o):/usr/home/adrian/work/freebsd/head/src/gnu/= usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.text= +0x705): > more undefined references to `bfd_i386_arch' follow > cc: error: linker command failed with exit code 1 (use -v to see = invocation) > *** Error code 1 >=20 >=20 > ... is that known? This is a somewhat odd failure mode=E2=80=A6 I=E2=80=99ve not seen it, = but why is it getting i386 symbols undefined when you have an arm build = going? It=E2=80=99s xdev, which I=E2=80=99ve officially decided to not = do any more work on. I suggest using ports for the cross build compilers. Work is underway on = that, but I=E2=80=99m not sure if it has been pushed out yet. Warner --Apple-Mail=_C6A6B1B5-30F7-4CD3-9846-7621B3A08024 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUlbD6AAoJEGwc0Sh9sBEA33QQALG/2hN2xT2UYEvlLeRQ2WJH wowyw9rm8abGbca333Zh44dfOryjebH379UI4Rts9yXBKtm3zYv2DcAfcMH9Q1tB axBk75zWJGrd7Z5K/8OXfMqZbxc6PmK5osn8ZExZ5wPMUGaLvOnDBR/BQDIhfca6 obusQN+JOxSwJuRWELkgiUenKt550Yq5Emy459jBVAEFrRETE77qdAFeaIs8+lRu p53C0h6PNvuLNnf1Kq+/ZBCLkjdLdUcJ9x7Xly+joCTod/nzB4VU8n89/cmTz3vl 9dR/DFeAx+nEaOqA+KXoBn/3D+Zncs6r0TgUGCM7gGOa5LD/yZfB3Wa7AzHZEXpO 6F8Xa3lwxl3WmPVs0wbXOaS7iyNpV2fCMNk0QU5sbQZITV1ul26U2+03Gdmx2NnW sSDKNfwMcBCD2uIM/BJvZhRHKZyAktGyqGQWPQxcGfUUKECVgUDNFXOGBLbYg3Qw Azn+Q7wnh0Umt2UdrBMNYtfcZnlKxqEn4FPnycfnxoHgawz+wTXJd56S+q+n2J7z gxaMTBgndPlf8RXlbv24azG9mCyQ3n86sLJVNf/hXVBmHfVKMBD6ogCh2ArtqnLa 8LwZL/G/uimyy39qxgCjEkciiVcDV2LMVou9M6sUORwRX5d/MkykecWAvlVEgJCS A/ZjyWSEciTRtdZVe9JC =7s8s -----END PGP SIGNATURE----- --Apple-Mail=_C6A6B1B5-30F7-4CD3-9846-7621B3A08024-- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 19:30:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E62975BC for ; Sat, 20 Dec 2014 19:30:55 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C52B82ACB for ; Sat, 20 Dec 2014 19:30:55 +0000 (UTC) Received: from [192.168.200.211] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 96929193DFF; Sat, 20 Dec 2014 19:30:48 +0000 (UTC) Message-ID: <5495CE66.6020603@ignoranthack.me> Date: Sat, 20 Dec 2014 11:30:46 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: mexas@bris.ac.uk, freebsd-arm@freebsd.org Subject: Re: lang/gcc* on armv6? References: <201412120917.sBC9HACc024857@mech-as221.men.bris.ac.uk> In-Reply-To: <201412120917.sBC9HACc024857@mech-as221.men.bris.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 19:30:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/12/14 01:17, Anton Shterenlikht wrote: > Anybody successfully built any of lang/gcc48, 49 or 5? I'm on > RPi-B. > > Thanks > > Anton _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm To > unsubscribe, send any mail to > "freebsd-arm-unsubscribe@freebsd.org" > > There are patches under test this weekend. I will hopefully get some feedback to the maintainer by Monday to get a lang/gcc* available for ports building. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUlc5jXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEBIB78oecn5kgUEH/3/baI+WOuBRex7J4Ob4oPEW 0CfFdB2B7KT2d+L9X+V0Lqggka1J2aKF6EVcK0PNuysEvapsUfTc8HJEIqqI7RIg 7xSKSOhA8Nc1w9Exy8hWSoQoLfZP5XhKBvBFpi2sw6Cg3R4Hf2V1CcgZdGY9wuTF g4vwgkC0FIl4RwAJ3fLtYqrp3LdjQ/I7VL0dSMhWH82RrbDLZsXMvyPxrBBB7oIw u8tQw2uyXp1azPusfVxXYlg5Qfd4XdGYjiIdY4bsmRN9UyuThOY9YO9Pyi+HOOW2 onyATYU2LSobWujnGYzIdeKivxA2doNF4+c5HGJSWrl4sFx40fwOjN0HT0Rikxo= =1SUz -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 20:37:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E46458C for ; Sat, 20 Dec 2014 20:37:43 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 893781905 for ; Sat, 20 Dec 2014 20:37:42 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so3950993wgh.18 for ; Sat, 20 Dec 2014 12:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SkTuG5USYzCZyag5kgVCN9vq3H229/NiPZNl7BkrSK0=; b=e+5HEehP/0inkrTLi8RNc4nNqzstVo/1Rk73S3OZ7cJGu5XI66ZQdqAEJnkVx0Xl14 HA5pUjBrqSVt9Aol/hNzTfulqd92GhzC2PMm82GEusZr7ZyYf2XWtlVFULAT/oED3lNS M0QwnW4E/Q+2DkK54ORR569exeVekgRMEK7ELKSC80bVAfJB99L/jFFkFDy1JcSyyuhJ Dhm1lWx/8/Q441Mug29FIUVwH6QVSLrwjAXAtVsR1Z8XMzIhE5Woc9CyjX4rJS4/ya/j HXvhbgph6tWeYBIPrTr1sYKtP7EvA4Z7aYKBJ46kcbHmZ1rMbe8LdWMhrrX1zNfUW9Qz V6Dw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr27716085wjz.20.1419107860106; Sat, 20 Dec 2014 12:37:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Sat, 20 Dec 2014 12:37:40 -0800 (PST) In-Reply-To: <22621F71-5049-452C-AB8B-403E365C325D@bsdimp.com> References: <22621F71-5049-452C-AB8B-403E365C325D@bsdimp.com> Date: Sat, 20 Dec 2014 12:37:40 -0800 X-Google-Sender-Auth: 0q92Fg0vRC2ecf2anuYLxf06YzY Message-ID: Subject: Re: trying to build crochet/freebsd-head raspberry pi From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 20:37:43 -0000 On 20 December 2014 at 09:25, Warner Losh wrote: > >> On Dec 19, 2014, at 7:23 PM, Adrian Chadd wrote: >> >> hiya! >> >> i'm trying to build an updated -head r-pi image, and I'm hitting problem= s again. >> >> I've updated to the latest crochet from tim's github. >> >> Then I run it, and it says to run this: >> >> make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC=3D1 WITH_GCC_BOOTSTRAP=3D1 >> WITHOUT_CLANG=3D1 WITHOUT_CLANG_BOOTSTRAP=3D1 WITHOUT_CLANG_IS_CC=3D1 >> WITHOUT_TESTS=3D1 xdev >> >> so I do, and this happens: >> >> =3D=3D=3D> gnu/usr.bin/binutils/libbinutils (all) >> =3D=3D=3D> gnu/usr.bin/binutils/addr2line (all) >> cc -O2 -pipe -DBFD_DEFAULT_TARGET_SIZE=3D32 -I. >> -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line >> -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/= ../libbfd >> -I/home/adrian/work/freebsd/head/obj/usr/home/adrian/work/freebsd/head/s= rc/gnu/usr.bin/binutils/addr2line/../libbfd >> -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/= ../../../../contrib/binutils/include >> -D_GNU_SOURCE -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binut= ils/addr2line/../libbinutils >> -I/usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/addr2line/= ../../../../contrib/binutils/binutils >> -std=3Dgnu99 -fstack-protector -Qunused-arguments -o addr2line >> addr2line.o ../libbinutils/libbinutils.a ../libbfd/libbfd.a >> ../libiberty/libiberty.a >> ../libbfd/libbfd.a(targets.o):(.data+0x10): undefined reference to >> `bfd_elf64_x86_64_freebsd_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x0): undefined reference to >> `bfd_elf64_x86_64_freebsd_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x8): undefined reference to >> `bfd_elf64_x86_64_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x10): undefined reference to >> `bfd_efi_app_x86_64_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x18): undefined reference to >> `bfd_elf32_i386_freebsd_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x20): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x28): undefined reference to >> `bfd_efi_app_ia32_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0xc8): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0xd8): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0xe8): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0xf8): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x108): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x118): more undefined >> references to `bfd_elf32_i386_vec' follow >> ../libbfd/libbfd.a(targets.o):(.rodata+0x148): undefined reference to >> `bfd_elf32_i386_freebsd_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x178): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x188): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x198): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x1a8): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x1b8): undefined reference to >> `bfd_elf64_x86_64_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x1d8): undefined reference to >> `bfd_elf64_x86_64_freebsd_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x1f8): undefined reference to >> `bfd_elf64_x86_64_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x208): undefined reference to >> `bfd_elf64_x86_64_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x218): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x228): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x238): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x258): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x268): undefined reference to >> `bfd_elf32_i386_vec' >> ../libbfd/libbfd.a(targets.o):(.rodata+0x278): more undefined >> references to `bfd_elf32_i386_vec' follow >> ../libbfd/libbfd.a(archures.o): In function `bfd_scan_arch': >> /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../..= /../../contrib/binutils/bfd/archures.c:(.text+0x2e): >> undefined reference to `bfd_i386_arch' >> ../libbfd/libbfd.a(archures.o): In function `bfd_arch_list': >> /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../..= /../../contrib/binutils/bfd/archures.c:(.text+0x75): >> undefined reference to `bfd_i386_arch' >> /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../..= /../../contrib/binutils/bfd/archures.c:(.text+0x9d): >> undefined reference to `bfd_i386_arch' >> ../libbfd/libbfd.a(archures.o): In function `bfd_default_set_arch_mach': >> /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../..= /../../contrib/binutils/bfd/archures.c:(.text+0x5e7): >> undefined reference to `bfd_i386_arch' >> ../libbfd/libbfd.a(archures.o): In function `bfd_lookup_arch': >> /usr/home/adrian/work/freebsd/head/src/gnu/usr.bin/binutils/libbfd/../..= /../../contrib/binutils/bfd/archures.c:(.text+0x665): >> undefined reference to `bfd_i386_arch' >> ../libbfd/libbfd.a(archures.o):/usr/home/adrian/work/freebsd/head/src/gn= u/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/archures.c:(.tex= t+0x705): >> more undefined references to `bfd_i386_arch' follow >> cc: error: linker command failed with exit code 1 (use -v to see invocat= ion) >> *** Error code 1 >> >> >> ... is that known? > > This is a somewhat odd failure mode=E2=80=A6 I=E2=80=99ve not seen it, bu= t why is it getting i386 symbols undefined when you have an arm build going= ? It=E2=80=99s xdev, which I=E2=80=99ve officially decided to not do any mo= re work on. > > I suggest using ports for the cross build compilers. Work is underway on = that, but I=E2=80=99m not sure if it has been pushed out yet. Ok, i was hoping that this'd mostly work still so doing raspberry-pi framebuffer/gpu development on -HEAD. I'll wait until the changes hit crochet and it all works out of the box again. Thanks, -adrian