From owner-freebsd-toolchain@freebsd.org Sun May 29 04:13:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA077B532E9; Sun, 29 May 2016 04:13:58 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (mail.xzibition.com [52.11.127.251]) (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 A81BD1DAB; Sun, 29 May 2016 04:13:58 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 614D41E851; Sun, 29 May 2016 04:13:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id e5Wzyzv_T25p; Sun, 29 May 2016 04:13:48 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 28BC91E84A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shatow.net; s=mxc204805312015; t=1464495228; bh=gHxuIR5q7ZWJFkMpm9CTZo55bX2XpwKg7/NmoyrlL9k=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=jDBzpZ5r8GoH4cuEky+0z8fBk6b36RXzg6l8WRkWoLz5Br5Ei/rwgVhe2zkPPfNPT arfzDsnzCy7WcO9Wic8HS9zPhG/h8kNfwKCXFdOJ5YFULnBGckTvPTV/8hC6Y65Elk qwODhTKVL6yFZY8D9fawnd0/X9nJSCcaLJY0kxwcwoGl3TrONLzIN48vczr909lFLT 0Mbz+sE3auTVvRJwTsbtIzebQeapFlXNCsOCgixR34ApzOFCUYBdYXK/tHHjY7iTJy OysPUuUUY+ka4uHXJsQoNxsTnSsQk0LRhSkgODNSHQwUJinaMJ2+no4txUy09iad8/ rI0nwroxlBhDw== To: Adrian Chadd , Mark Millard References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric From: Bryan Drewery Message-ID: <0f681095-9876-cb42-b158-7420174c0409@shatow.net> Date: Sat, 28 May 2016 21:13:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 04:13:58 -0000 On 5/28/2016 12:03 PM, Adrian Chadd wrote: > [snip] I beg of you to *stop* snipping all context. > > hi, > > please don't patch the ports compiler assumptions about things like I said it was not right, and was an experiment. > this. We should be targeting external toolchains on OSes (eg macosx) > where it may already generate freebsd binaries and as such we should > be calling the compiler/linker with all the flags it needs. > > Having a patched compiler default for mips made things way, way harder > than it needed to be. > > -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-toolchain@freebsd.org Sun May 29 04:50:14 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6953DB4F324 for ; Sun, 29 May 2016 04:50:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BF351BDE for ; Sun, 29 May 2016 04:50:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id z123so15291696itg.0 for ; Sat, 28 May 2016 21:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ruanxs6t+dBMtT5ehzs+ZxHsFfXkGJfzBOf1K6ZpQP4=; b=nO85F9FUrc/nRP24ZtJdz6gipvLtsYrPYJ6SUFVmq822njLtNqI8cDwxF77gwgqXd/ GOoHAcxC6XhZ0YrcJieO8saoVVPEGmaXW776bhGr8HnV6fharVeUNk/nQ2OZ5tt2R4xZ CRkQZXepoLO09XWgKgjlL7DWIk6XpCfVlILBF/NU3FyLujqwy/eHZ4gwCU+pfHr/fMV/ FrpT5ETDqde0LPKZZcuTXnYowXPCNu7cMckwwAW48iN2OY1A3myeAGtjYkfAnjXOarFk hNuN4xQ97uJYpE+zeixuctVrevkI98Uswng0FtWUG44unuF6T0ggl4VpQKpXTLCQ3/LW CiEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ruanxs6t+dBMtT5ehzs+ZxHsFfXkGJfzBOf1K6ZpQP4=; b=Ff7CBpZU/52j4VaRgs2Jus97NPh/9RX3aZyiyFdOFGmgJX63ctxy7hDC72To2moPAA BNPTISSh4495NB0u8oyuFaretjpXVpNNSyzWtNWzpobjjn46/LWygx41mqLCo37g+zzP oq3Mteix0VaLt4M3zS8B966H9i4/cvoC1a60SCxIO5EBzrn7GdhDFJ8Jo1cyhqlgtUv8 u1Y42ZWkB49Om5DITT9NUC/5ZMhRXDaxZ8ZOF4MJitzaQrD9+ln91fJhqKF/JQwPw88Z n/i5FIYYQQQfBYLCg/Xpb4ViTZTjOZ1W+BMx9q+UYyMCngOaKRA22YY96J5cGG31J3o1 o6Ag== X-Gm-Message-State: ALyK8tLWB/x9ADuUyFjniIzJDwHOq2vZhupgFH8uIYavsjUzsR20Pyy/QZ4sZOsrzONPtgEtqLVuQUgKq9VtJA== MIME-Version: 1.0 X-Received: by 10.36.46.67 with SMTP id i64mr4329040ita.60.1464497413416; Sat, 28 May 2016 21:50:13 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Sat, 28 May 2016 21:50:13 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1E66E56C-E615-4180-A3F2-E8E48E26B6CD@dsl-only.net> References: <1E66E56C-E615-4180-A3F2-E8E48E26B6CD@dsl-only.net> Date: Sat, 28 May 2016 22:50:13 -0600 X-Google-Sender-Auth: WOtrra4rDRn6xBzlme7RvuSlv1k Message-ID: Subject: Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float) From: Warner Losh To: Mark Millard Cc: Gerald Pfeifer , Brooks Davis , FreeBSD Ports , FreeBSD Toolchain Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 04:50:14 -0000 On Wed, May 25, 2016 at 10:12 AM, Mark Millard wrote: > I'm not sure that Gerald or Brooks were CC'd on a report made to the arm list about armv6 builds of gcc and llvm being broken now because of hard float now being implicit: > (the first report listed below has more detail directly visible for gcc examples) > > https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html > and: > https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html > https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html > https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html > > The first (013931.html) shows that xgcc for configure:3686 for contest.c ends up with the likes of: > > /usr/local/bin/ld: error: a.out uses VFP register arguments, > /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not > /usr/local/bin/ld: failed to merge target specific data of file > /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o > /usr/local/bin/ld: error: a.out uses VFP register arguments, > /tmp//cchNL2QG.o does not > /usr/local/bin/ld: failed to merge target specific data of file /tmp//cchNL2QG.o > /usr/local/bin/ld: error: a.out uses VFP register arguments, > /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not > /usr/local/bin/ld: failed to merge target specific data of file > /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o > collect2: error: ld returned 1 exit status > > and points to gcc/config.gcc only having TARGET_FREEBSD_ARM_HARD_FLOAT=1 for arm*hf-*-freebsd* . But now armv6*-*-freebsd* is also hard float for 11.0-CURRENT. armv6*-*-freebsd is only hard float ABI for FreeBSD 11. > Of course until everyone updates to modern enough armv6 context a mix of softfloat and hardfloat will be around. Are you saying that we need to get these changes to the ports in place to support hard float? Are you saying we need to support a mix better (which is unlikely to happen, btw, without a passionate champion)? Is there some other point I'm missing? Warner From owner-freebsd-toolchain@freebsd.org Sun May 29 06:00:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 531BBB521E1 for ; Sun, 29 May 2016 06:00:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-191.reflexion.net [208.70.211.191]) (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 14B1018E0 for ; Sun, 29 May 2016 06:00:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3346 invoked from network); 29 May 2016 06:01:12 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 May 2016 06:01:12 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 29 May 2016 02:01:17 -0400 (EDT) Received: (qmail 16367 invoked from network); 29 May 2016 06:01:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 May 2016 06:01:17 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D45E1B1E001; Sat, 28 May 2016 23:00:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float) From: Mark Millard In-Reply-To: Date: Sat, 28 May 2016 23:00:39 -0700 Cc: Gerald Pfeifer , Brooks Davis , FreeBSD Ports , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <93022D2B-29D1-4422-A7B0-5366C0182973@dsl-only.net> References: <1E66E56C-E615-4180-A3F2-E8E48E26B6CD@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 06:00:47 -0000 On 2016-May-28, at 9:50 PM, Warner Losh wrote: > On Wed, May 25, 2016 at 10:12 AM, Mark Millard = wrote: >> I'm not sure that Gerald or Brooks were CC'd on a report made to the = arm list about armv6 builds of gcc and llvm being broken now because of = hard float now being implicit: >> (the first report listed below has more detail directly visible for = gcc examples) >>=20 >> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html >> and: >> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html >> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html >> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html >>=20 >> The first (013931.html) shows that xgcc for configure:3686 for = contest.c ends up with the likes of: >>=20 >> /usr/local/bin/ld: error: a.out uses VFP register arguments, >> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not >> /usr/local/bin/ld: failed to merge target specific data of file >> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o >> /usr/local/bin/ld: error: a.out uses VFP register arguments, >> /tmp//cchNL2QG.o does not >> /usr/local/bin/ld: failed to merge target specific data of file = /tmp//cchNL2QG.o >> /usr/local/bin/ld: error: a.out uses VFP register arguments, >> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not >> /usr/local/bin/ld: failed to merge target specific data of file >> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o >> collect2: error: ld returned 1 exit status >>=20 >> and points to gcc/config.gcc only having = TARGET_FREEBSD_ARM_HARD_FLOAT=3D1 for arm*hf-*-freebsd* . But now = armv6*-*-freebsd* is also hard float for 11.0-CURRENT. >=20 > armv6*-*-freebsd is only hard float ABI for FreeBSD 11. My understanding is that the older rpi's are ARM1176JZF-S, "which IS = armv6" to quote Ian Lepore. I've not used such under 10.x at all so I = may be making some implicit bad assumptions below. Feel free to correct = my stupidities. . . Unless 10.x FreeBSD is also switching to hardfloat I do not expect that = the above part of your note is fully descriptive for compiler ports. = (Presumes continued targeting of 10.x armv6 for rpi.) armv6*-*-freebsd10* (such as for a 10.x rpi) is softfloat and stays that = way in 10.x . armv6*-*-freebsd11* (such as for a 11.x rpi or rpi2) is hardfloat now. (I'm guessing those naming patterns.) The compiler ports and their supporting runtime files deal with both = targeting contexts for some amount of time (until 10.x can be dropped by = ports). (Forms of on-the-fly code generation might also have such = issues.) >> Of course until everyone updates to modern enough armv6 context a mix = of softfloat and hardfloat will be around. >=20 > Are you saying that we need to get these changes to the ports in place > to support hard float? Are you saying we need to support a mix better > (which is unlikely to happen, btw, without a passionate champion)? Is > there some other point I'm missing? >=20 > Warner A compiler toolchain in ports that targeted softfloat ABI before now = needs to target the hardfloat ABI for 11.0 --and that apparently now = uses "VFP register arguments". gcc/crtbegin.o , gcc/crtend.o , and the like for hardfloat contexts need = to handle at least "VFP register arguments" now but do not yet do so. The old armv6*-*-freebsd* pattern used to identify a softfloat context = and some text matching that pattern now identifies a hardfloat context ( = armv6*-*-freebsd11* as far as I can tell). The toolchain example above = is/was based on the pattern arm*hf-*-freebsd* to identify hardfloat vs. = armv6*-*-freebsd* for softfloat (both 10.x and 11.0?). This is no longer = sufficient. Of course until someone rebuilds and installs replacing an older 11.0 = build that had text matching the pattern armv6*-*-freebsd11*, the build = it really is still softfloat so there is a transition-time issue because = the text used does not uniquely identify the context: Once the ports = they needed are ready folks then need to upgrade the 11.0 vintage to = track. Before then the lack of ports might break their context if they = update the 11.0 vintage.=20 So I think the answer to the first question is: Yes there are changes = that need to be made for the compiler ports to work for 11.0 and its = hardfloat use. I'm guessing that building the ports for targeting 10.x = is also to be possible for some time. For the second question: hardfloat is not supported yet in ports. It = needs to be for targeting armv6*-*-freebsd11* (11.0). Softfloat needs to = be supported for targeting armv6*-*-freebsd10* (10.x). I do not see 11.0 = supporting softfloat going forward. I do not see 10.x supporting = hardfloat going forward. The relevant ports have 2 contexts to span = unless 10.x ( armv6*-*-freebsd10* ) support is to be dropped now. Am I clearer this time? (I leave the 3rd question to you: Did I make any = new points here?) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun May 29 03:55:57 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5982BB500AC; Sun, 29 May 2016 03:55:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BF221E9B; Sun, 29 May 2016 03:55:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id t40so92866533ioi.0; Sat, 28 May 2016 20:55:57 -0700 (PDT) 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; bh=2GtFzeJ86K7vfz1Tgc3Gacxik7q8YBKpnHK6g/jBy4k=; b=BGNx56Wd8gIhs+XJQIdNadvCW5rTgSwUEAFq3s4UD7GQH5MN8bU0Gr1D2wpu3E51+q RNlAKQeHFBDEuWk8NTGQy2FVgOdCxj4dw8e2RLLuzPKnFzJyrbViIGt+gl3dFN35EojN OWyb9xlBd0noBldAEPzyJqrI+7meI2m2+VRBtS+QCCfgnSqVUeUuIgB+yD8+uBUltqIX S2jUa+IlLY5bjdrrBY/3LE0Zdu+OAtpQGzCGgsq/O7fhnamCyhpF2RGYrJHT5+KT30Tt PIKMGUnpQNgLUZIvFrplUezV78oncWB7FwsJGp+1md2ZLGblfUWBcNbMJqWmrt7YGCDS MhVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2GtFzeJ86K7vfz1Tgc3Gacxik7q8YBKpnHK6g/jBy4k=; b=THS5P7yGlAeo389M0anwaHUZ1UH1tL8q2u/mjNjm/iN1Riw9Y8kilsyGd/kjwf7JqI z1iLfhQ2awKwtlsf1DiqcqaQxwgJyswll/p+n1yTmWIGJC891+TPGzMnnwQhkW2cOPRQ 8Fr+WkZiI99yHrigHAkXjoWV5FEbQ7LbBE21XiMCOFoxRXIIzXS/xsoh2zCc+rVsqEyB DygtN7K2aqymgfey6W9xZRQYnzdx856x2fxAe/tB4lW+TwgSkOi8xIViTBMDgp8owhRw 5GVkoeIuva7xPubYfR1Gv15aXqrmLpEEMo5gkySmLTSJ8ohHW8t8V29vb76xMgkUr/Nm w0Hg== X-Gm-Message-State: ALyK8tIwXq7wwYdytp8nxn5gLw3qyem0d6CNZvn5bLkBSm7s3Q6yRsiFbWBKtOC+PluVDbRuEczt1kPreCsM+g== MIME-Version: 1.0 X-Received: by 10.107.15.234 with SMTP id 103mr18461765iop.75.1464494156467; Sat, 28 May 2016 20:55:56 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Sat, 28 May 2016 20:55:56 -0700 (PDT) In-Reply-To: References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> Date: Sat, 28 May 2016 20:55:56 -0700 Message-ID: Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Adrian Chadd To: Mark Millard Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 03:55:57 -0000 On 28 May 2016 at 14:30, Mark Millard wrote: > On 2016-May-28, at 12:03 PM, Adrian Chadd wrote: > >> [snip] >> >> hi, >> >> please don't patch the ports compiler assumptions about things like >> this. We should be targeting external toolchains on OSes (eg macosx) >> where it may already generate freebsd binaries and as such we should >> be calling the compiler/linker with all the flags it needs. >> >> Having a patched compiler default for mips made things way, way harder >> than it needed to be. >> >> >> >> -adrian > > Are there specific technical examples of specific lessons learned from the "patched compiler default for mips" context? > > Is there an intent to use /usr/src/. . . materials for buildworld/buildkernel and the like from a non-FreeBSD context? Are there examples? Well, I'd like to be able to build it from non-freebsd environment. Eg, eventually from the macosx shipped clang/llvm, or various other external toolchains. Doubly so for whatever commercial / internal / bring-up compilers that are used during platform bringup. The hurt is that our Makefile stuff is still a bit messy. On the plus side, Brian, Warner in particular have done a great job undoing all of that and making things cleaner, so big props to them! -adrian From owner-freebsd-toolchain@freebsd.org Mon May 30 04:19:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5162CB51477 for ; Mon, 30 May 2016 04:19:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-192.reflexion.net [208.70.211.192]) (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 0EF151A9C for ; Mon, 30 May 2016 04:19:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30995 invoked from network); 30 May 2016 04:20:26 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 May 2016 04:20:26 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 00:20:01 -0400 (EDT) Received: (qmail 580 invoked from network); 30 May 2016 04:20:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 May 2016 04:20:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 38563B1E001; Sun, 29 May 2016 21:19:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] From: Mark Millard Date: Sun, 29 May 2016 21:19:54 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 04:19:58 -0000 This was my first-time-ever WITH_META_MODE attempt. I show a chunk of = the log later below. Retrying without WITH_META_MODE=3Dyes resulted in no problems, unlike = below. A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc as = the so-called "cross compiler" also did not have this problem =E2=80=94-bu= t powerpc64 does not have WITH_META_MODE (no filemon.ko to load). [The 2 "no problem" examples suggest that -r300944 has gotten to the = point that xtoolchain like contexts work again [non-META], even self = hosted ones.] Here is the part of the script log around the WITH_META_MODE failure. = The compiles had -v . . . --- ctld.full --- Using built-in specs. COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /5.3.0/lto-wrapper Target: powerpc64-portbld-freebsd11.0 Configured with: ./../gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dx86_64-portbld-freebsd11.0 Thread model: posix gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 = COMPILER_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/libexec/gcc/p= owerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portb= ld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /:/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/lib/g= cc/powerpc64-portbld-freebsd11.0/ = LIBRARY_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/lib/gcc/powerp= c64-portbld-freebsd11.0/5.3.0/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/s= rc/tmp/lib/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/ COLLECT_GCC_OPTIONS=3D'-isystem' = '/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include' = '-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib' '-B' = '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-I' = '/usr/src/usr.sbin/ctld/../../contrib/libucl/include' '-I' = '/usr/src/usr.sbin/ctld' '-I' '/usr/src/usr.sbin/ctld/../../sys' '-I' = '/usr/src/usr.sbin/ctld/../../sys/cam/ctl' '-I' = '/usr/src/usr.sbin/ctld/../../sys/dev/iscsi' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wextra' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wpointer-arith' = '-Wreturn-type' '-Wcast-qual' '-Wwrite-strings' '-Wswitch' '-Wshadow' = '-Wunused-parameter' '-Wcast-align' '-Wchar-subscripts' '-Winline' = '-Wnested-externs' '-Wredundant-decls' '-Wold-style-definition' = '-Wno-pointer-sign' '-Wno-error=3Dunused-function' = '-Wno-error=3Denum-compare' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dbool-compare' '-Wno-error=3Duninitialized' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dclobbered' = '-Wno-error=3Dcast-align' '-Wno-error=3Dextra' '-Wno-error=3Dattributes' = '-Wno-error=3Dinline' '-Wno-error=3Dunused-but-set-variable' = '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-aliasing' = '-Wno-error=3Daddress' '-v' '-o' 'ctld.full' /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/collect2 = -plugin = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/liblto_plugin.s= o = -plugin-opt=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/l= to-wrapper -plugin-opt=3D-fresolution=3D/tmp//ccDS76mK.res = -plugin-opt=3D-pass-through=3D-lgcc -plugin-opt=3D-pass-through=3D-lgcc_s = -plugin-opt=3D-pass-through=3D-lc -plugin-opt=3D-pass-through=3D-lgcc = -plugin-opt=3D-pass-through=3D-lgcc_s = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = --eh-frame-hdr -V -melf64ppc_fbsd -V -dynamic-linker = /libexec/ld-elf.so.1 -o ctld.full = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crt1.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crti.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtbegin.o = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = -L/usr/local/powerpc64-freebsd/bin = -L/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib chap.o = ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o = token.o uclparse.o -lbsdxml -ll -lmd -lsbuf -lutil -lprivateucl -lm = -lssp_nonshared -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc = --as-needed -lgcc_s --no-as-needed = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtend.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtn.o GNU ld (GNU Binutils) 2.25.1 Supported emulations: elf64ppc_fbsd elf64ppc elf32ppc_fbsd elf32ppc GNU ld (GNU Binutils) 2.25.1 Supported emulations: elf64ppc_fbsd elf64ppc elf32ppc_fbsd elf32ppcuclparse.o: In function `uclparse_chap': /usr/src/usr.sbin/ctld/uclparse.c:61: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:68: undefined reference to = `ucl_object_find_key' uclparse.o: In function `uclparse_chap_mutual': /usr/src/usr.sbin/ctld/uclparse.c:91: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:98: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:105: undefined reference to = `ucl_object_find_key' uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:112: more undefined = references to `ucl_object_find_key' follow uclparse.o: In function `uclparse_toplevel': /usr/src/usr.sbin/ctld/uclparse.c:235: undefined reference to = `ucl_iterate_object' /usr/src/usr.sbin/ctld/uclparse.c:278: undefined reference to = `ucl_iterate_object' /usr/src/usr.sbin/ctld/uclparse.c:317: undefined reference to = `ucl_iterate_object' uclparse.o: In function `uclparse_auth_group': /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to = `ucl_iterate_object' /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to = `ucl_iterate_object' uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined = references to `ucl_iterate_object' follow uclparse.o: In function `uclparse_target_lun': /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to = `ucl_object_find_key' /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to = `ucl_object_find_key' uclparse.o: In function `uclparse_target': /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to = `ucl_iterate_object' collect2: error: ld returned 1 exit status *** [ctld.full] Error code 1 make[4]: stopped in /usr/src/usr.sbin/ctld 1 error make[4]: stopped in /usr/src/usr.sbin/ctld *** [all_subdir_usr.sbin/ctld] Error code 2 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon May 30 06:32:59 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B52D2B54D2F for ; Mon, 30 May 2016 06:32:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-174.reflexion.net [208.70.211.174]) (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 5658313D9 for ; Mon, 30 May 2016 06:32:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6287 invoked from network); 30 May 2016 06:32:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 May 2016 06:32:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 02:32:49 -0400 (EDT) Received: (qmail 3821 invoked from network); 30 May 2016 06:32:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 May 2016 06:32:49 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F73CB1E001; Sun, 29 May 2016 23:32:44 -0700 (PDT) Subject: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc via system clang use] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Mark Millard In-Reply-To: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> Date: Sun, 29 May 2016 23:32:50 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 06:32:59 -0000 [It may well be that powerpc is not an intended cross compile target via = clang since clang is insufficient for an FreeBSD/powerpc ABI compliant = buildworld as stands. Still I use this to illustrate the more general = points for clang use in cross builds.] The failure: > --- libc.so.7.full --- > /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd > Supported emulations: elf_x86_64_fbsd elf_i386_fbsd > clang: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [libc.so.7.full] Error code 1 >=20 > make[4]: stopped in /usr/src/lib/libc > 1 error >=20 > make[4]: stopped in /usr/src/lib/libc > *** [lib/libc__L] Error code 2 Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link = operation. The log shows the ld command was via clang=E2=80=99s front end as far as = what the build did directly (just a prefix shown): > --- libc.so.7.full --- > /usr/bin/clang -target powerpc-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'nm' NMFLAGS=3D'' lorder trivial-vdso_tc.So bt_close.So bt_conv.So = bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So . . . The -B does not point to a place with a powerpc specific ld command: > # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin > total 1395 > -rwxr-xr-x 1 root wheel 827248 May 29 22:20 ctfmerge > -rwxr-xr-x 1 root wheel 534712 May 29 22:20 sysinit > -rwxr-xr-x 1 root wheel 960784 May 29 22:20 ctfconvert As far as I can tell a potentially proper path would have been: /usr/local/powerpc-freebsd/bin/ld if a devel/powerpc-binutils port existed and was installed. (No such = port exists.) I do not know if other TARGET_ARCH=E2=80=99s have similar problems or = not (even if they have a binutils port). This was not a WITH_META_MODE=3Dyes context. make.conf was empty and src.conf was: TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon May 30 15:29:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D439B54FE2; Mon, 30 May 2016 15:29:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 65BCB19A7; Mon, 30 May 2016 15:29:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 5211A1BDA; Mon, 30 May 2016 15:29:47 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id F01411D7F7; Mon, 30 May 2016 15:29:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id A446IqALvo5R; Mon, 30 May 2016 15:29:38 +0000 (UTC) Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 6BE421D7F1 To: Mark Millard , FreeBSD Current References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> Cc: FreeBSD Toolchain , FreeBSD PowerPC ML From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Mon, 30 May 2016 08:29:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7LtOeSibHtIO8t59R5B8g4SBwcj8du689" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 15:29:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7LtOeSibHtIO8t59R5B8g4SBwcj8du689 Content-Type: multipart/mixed; boundary="lVaeJohqt2ddjA7OEtiafs3N49wEqwKMN" From: Bryan Drewery To: Mark Millard , FreeBSD Current Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Message-ID: Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> In-Reply-To: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> --lVaeJohqt2ddjA7OEtiafs3N49wEqwKMN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This failure is not likely related to META_MODE. I should have mentioned that to enable META_MODE after not having it on you should do a 'make cleanworld' first. On 5/29/2016 9:19 PM, Mark Millard wrote: > This was my first-time-ever WITH_META_MODE attempt. I show a chunk of t= he log later below. >=20 > Retrying without WITH_META_MODE=3Dyes resulted in no problems, unlike b= elow. >=20 > A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc a= s the so-called "cross compiler" also did not have this problem =E2=80=94= -but powerpc64 does not have WITH_META_MODE (no filemon.ko to load). >=20 > [The 2 "no problem" examples suggest that -r300944 has gotten to the po= int that xtoolchain like contexts work again [non-META], even self hosted= ones.] >=20 > Here is the part of the script log around the WITH_META_MODE failure. T= he compiles had -v . . . >=20 > --- ctld.full --- > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd1= 1.0/5.3.0/lto-wrapper > Target: powerpc64-portbld-freebsd11.0 > Configured with: ./../gcc-5.3.0/configure --target=3Dpowerpc64-portbld-= freebsd11.0 --disable-nls --enable-languages=3Dc,c++ --without-headers --= with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD Ports Collection for p= owerpc64' --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd= -as --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local= --localstatedir=3D/var --mandir=3D/usr/local/man --infodir=3D/usr/local/= info/ --build=3Dx86_64-portbld-freebsd11.0 > Thread model: posix > gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 > COMPILER_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/libexec/gc= c/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-p= ortbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portbld-freebs= d11.0/:/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local= /lib/gcc/powerpc64-portbld-freebsd11.0/ > LIBRARY_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/lib/gcc/pow= erpc64-portbld-freebsd11.0/5.3.0/:/usr/obj/xtoolchain/powerpc.powerpc64/u= sr/src/tmp/lib/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib= / > COLLECT_GCC_OPTIONS=3D'-isystem' '/usr/obj/xtoolchain/powerpc.powerpc64= /usr/src/tmp/usr/include' '-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/sr= c/tmp/usr/lib' '-B' '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-I= ' '/usr/src/usr.sbin/ctld/../../contrib/libucl/include' '-I' '/usr/src/us= r.sbin/ctld' '-I' '/usr/src/usr.sbin/ctld/../../sys' '-I' '/usr/src/usr.s= bin/ctld/../../sys/cam/ctl' '-I' '/usr/src/usr.sbin/ctld/../../sys/dev/is= csi' '-g' '-std=3Dgnu99' '-fstack-protector-strong' '-Wsystem-headers' '-= Wall' '-Wno-format-y2k' '-Wextra' '-Wstrict-prototypes' '-Wmissing-protot= ypes' '-Wpointer-arith' '-Wreturn-type' '-Wcast-qual' '-Wwrite-strings' '= -Wswitch' '-Wshadow' '-Wunused-parameter' '-Wcast-align' '-Wchar-subscrip= ts' '-Winline' '-Wnested-externs' '-Wredundant-decls' '-Wold-style-defini= tion' '-Wno-pointer-sign' '-Wno-error=3Dunused-function' '-Wno-error=3Den= um-compare' '-Wno-error=3Dlogical-not-parentheses' '-Wno-error=3Dbool-com= pare' '-Wno-error=3Duninitialized' '-Wno-error=3Darray-bounds' '-Wno-erro= r=3Dclobbered' '-Wno-error=3Dcast-align' '-Wno-error=3Dextra' '-Wno-error= =3Dattributes' '-Wno-error=3Dinline' '-Wno-error=3Dunused-but-set-variabl= e' '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-aliasing' '-Wno-error= =3Daddress' '-v' '-o' 'ctld.full' > /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/collect2 -p= lugin /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/liblto_p= lugin.so -plugin-opt=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11= =2E0/5.3.0/lto-wrapper -plugin-opt=3D-fresolution=3D/tmp//ccDS76mK.res -p= lugin-opt=3D-pass-through=3D-lgcc -plugin-opt=3D-pass-through=3D-lgcc_s -= plugin-opt=3D-pass-through=3D-lc -plugin-opt=3D-pass-through=3D-lgcc -plu= gin-opt=3D-pass-through=3D-lgcc_s --sysroot=3D/usr/obj/xtoolchain/powerpc= =2Epowerpc64/usr/src/tmp --eh-frame-hdr -V -melf64ppc_fbsd -V -dynamic-li= nker /libexec/ld-elf.so.1 -o ctld.full /usr/obj/xtoolchain/powerpc.powerp= c64/usr/src/tmp/usr/lib/crt1.o /usr/obj/xtoolchain/powerpc.powerpc64/usr/= src/tmp/usr/lib/crti.o /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/= usr/lib/crtbegin.o -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/us= r/lib -L/usr/local/powerpc64-freebsd/bin -L/usr/local/lib/gcc/powerpc64-p= ortbld-freebsd11.0/5.3.0 -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/= tmp/lib -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib chap.= o ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o t= oken.o uclparse.o -lbsdxml -ll -lmd -lsbuf -lutil -lprivateucl -lm -lssp_= nonshared -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed = -lgcc_s --no-as-needed /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/= usr/lib/crtend.o /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtn.o > GNU ld (GNU Binutils) 2.25.1 > Supported emulations: > elf64ppc_fbsd > elf64ppc > elf32ppc_fbsd > elf32ppc > GNU ld (GNU Binutils) 2.25.1 > Supported emulations: > elf64ppc_fbsd > elf64ppc > elf32ppc_fbsd > elf32ppcuclparse.o: In function `uclparse_chap': > /usr/src/usr.sbin/ctld/uclparse.c:61: undefined reference to `ucl_objec= t_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:68: undefined reference to `ucl_objec= t_find_key' > uclparse.o: In function `uclparse_chap_mutual': > /usr/src/usr.sbin/ctld/uclparse.c:91: undefined reference to `ucl_objec= t_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:98: undefined reference to `ucl_objec= t_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:105: undefined reference to `ucl_obje= ct_find_key' > uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:112: more undefined refere= nces to `ucl_object_find_key' follow > uclparse.o: In function `uclparse_toplevel': > /usr/src/usr.sbin/ctld/uclparse.c:235: undefined reference to `ucl_iter= ate_object' > /usr/src/usr.sbin/ctld/uclparse.c:278: undefined reference to `ucl_iter= ate_object' > /usr/src/usr.sbin/ctld/uclparse.c:317: undefined reference to `ucl_iter= ate_object' > uclparse.o: In function `uclparse_auth_group': > /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to `ucl_iter= ate_object' > /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to `ucl_iter= ate_object' > uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined refere= nces to `ucl_iterate_object' follow > uclparse.o: In function `uclparse_target_lun': > /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to `ucl_obje= ct_find_key' > /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to `ucl_obje= ct_find_key' > uclparse.o: In function `uclparse_target': > /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to `ucl_iter= ate_object' > collect2: error: ld returned 1 exit status >=20 > *** [ctld.full] Error code 1 >=20 > make[4]: stopped in /usr/src/usr.sbin/ctld > 1 error >=20 > make[4]: stopped in /usr/src/usr.sbin/ctld > *** [all_subdir_usr.sbin/ctld] Error code 2 >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --lVaeJohqt2ddjA7OEtiafs3N49wEqwKMN-- --7LtOeSibHtIO8t59R5B8g4SBwcj8du689 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJXTFxmAAoJEDXXcbtuRpfPuDEH/3xdXoTGLHD82ImCgBtRXbTA pnEBvllA1+vAVMX1EuqvFiN4kdQqQLM7vX6N5pHihmCFQMnXgTfhdTUBAghlTisT lwmv5doqM0WdBii+LXr6ePVY8cyNF51/grQ81j/oLmiTOMuUKs5QeK4Vg/+oXhjH io57WQ89rZ3Hp6vyW8bXCoeSGS2UkR3mZlwiU7hkGnXv6bFH8HuCwrxcN+wC0/d7 kjk3BRCCE9eftejIapVdoWBHpm1xncL+cLzJi8QarEXaLqO2Kmxh+E1rB2I6PnQ2 ev4LSZQp6Tv4DmvHo+5EabAHvniN+GUyymkHgkk/IGbsp061Bo+wQdcznFr3BWQ= =80kK -----END PGP SIGNATURE----- --7LtOeSibHtIO8t59R5B8g4SBwcj8du689-- From owner-freebsd-toolchain@freebsd.org Mon May 30 18:01:12 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73F23B556A5 for ; Mon, 30 May 2016 18:01:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-194.reflexion.net [208.70.211.194]) (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 394FB1193 for ; Mon, 30 May 2016 18:01:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32453 invoked from network); 30 May 2016 18:01:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 May 2016 18:01:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 14:01:07 -0400 (EDT) Received: (qmail 1943 invoked from network); 30 May 2016 18:01:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 May 2016 18:01:07 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 342A21C439B; Mon, 30 May 2016 11:01:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] From: Mark Millard In-Reply-To: Date: Mon, 30 May 2016 11:01:08 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 18:01:12 -0000 On 2016-May-30, at 8:29 AM, Bryan Drewery = wrote: > This failure is not likely related to META_MODE. >=20 > I should have mentioned that to enable META_MODE after not having it = on > you should do a 'make cleanworld' first. >=20 > On 5/29/2016 9:19 PM, Mark Millard wrote: >> This was my first-time-ever WITH_META_MODE attempt. I show a chunk of = the log later below. >>=20 >> Retrying without WITH_META_MODE=3Dyes resulted in no problems, unlike = below. >>=20 >> A self-hosted powerpc64 11.0 -r300944 build using devel/powerpc64-gcc = as the so-called "cross compiler" also did not have this problem =E2=80=94= -but powerpc64 does not have WITH_META_MODE (no filemon.ko to load). >>=20 >> [The 2 "no problem" examples suggest that -r300944 has gotten to the = point that xtoolchain like contexts work again [non-META], even self = hosted ones.] >>=20 >> Here is the part of the script log around the WITH_META_MODE failure. = The compiles had -v . . . >>=20 >> --- ctld.full --- >> Using built-in specs. >> COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc >> = COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /5.3.0/lto-wrapper >> Target: powerpc64-portbld-freebsd11.0 >> Configured with: ./../gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dx86_64-portbld-freebsd11.0 >> Thread model: posix >> gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 >> = COMPILER_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/libexec/gcc/p= owerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portb= ld-freebsd11.0/5.3.0/:/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0= /:/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/:/usr/local/lib/g= cc/powerpc64-portbld-freebsd11.0/ >> = LIBRARY_PATH=3D/usr/local/powerpc64-freebsd/bin/:/usr/local/lib/gcc/powerp= c64-portbld-freebsd11.0/5.3.0/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/s= rc/tmp/lib/:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/ >> COLLECT_GCC_OPTIONS=3D'-isystem' = '/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include' = '-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib' '-B' = '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-I' = '/usr/src/usr.sbin/ctld/../../contrib/libucl/include' '-I' = '/usr/src/usr.sbin/ctld' '-I' '/usr/src/usr.sbin/ctld/../../sys' '-I' = '/usr/src/usr.sbin/ctld/../../sys/cam/ctl' '-I' = '/usr/src/usr.sbin/ctld/../../sys/dev/iscsi' '-g' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wextra' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wpointer-arith' = '-Wreturn-type' '-Wcast-qual' '-Wwrite-strings' '-Wswitch' '-Wshadow' = '-Wunused-parameter' '-Wcast-align' '-Wchar-subscripts' '-Winline' = '-Wnested-externs' '-Wredundant-decls' '-Wold-style-definition' = '-Wno-pointer-sign' '-Wno-error=3Dunused-function' = '-Wno-error=3Denum-compare' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dbool-compare' '-Wno-error=3Duninitialized' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dclobbered' = '-Wno-error=3Dcast-align' '-Wno-error=3Dextra' '-Wno-error=3Dattributes' = '-Wno-error=3Dinline' '-Wno-error=3Dunused-but-set-variable' = '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-aliasing' = '-Wno-error=3Daddress' '-v' '-o' 'ctld.full' >> /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/collect2 = -plugin = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/liblto_plugin.s= o = -plugin-opt=3D/usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/5.3.0/l= to-wrapper -plugin-opt=3D-fresolution=3D/tmp//ccDS76mK.res = -plugin-opt=3D-pass-through=3D-lgcc -plugin-opt=3D-pass-through=3D-lgcc_s = -plugin-opt=3D-pass-through=3D-lc -plugin-opt=3D-pass-through=3D-lgcc = -plugin-opt=3D-pass-through=3D-lgcc_s = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = --eh-frame-hdr -V -melf64ppc_fbsd -V -dynamic-linker = /libexec/ld-elf.so.1 -o ctld.full = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crt1.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crti.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtbegin.o = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = -L/usr/local/powerpc64-freebsd/bin = -L/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/lib = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib chap.o = ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o = token.o uclparse.o -lbsdxml -ll -lmd -lsbuf -lutil -lprivateucl -lm = -lssp_nonshared -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc = --as-needed -lgcc_s --no-as-needed = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtend.o = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib/crtn.o >> GNU ld (GNU Binutils) 2.25.1 >> Supported emulations: >> elf64ppc_fbsd >> elf64ppc >> elf32ppc_fbsd >> elf32ppc >> GNU ld (GNU Binutils) 2.25.1 >> Supported emulations: >> elf64ppc_fbsd >> elf64ppc >> elf32ppc_fbsd >> elf32ppcuclparse.o: In function `uclparse_chap': >> /usr/src/usr.sbin/ctld/uclparse.c:61: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:68: undefined reference to = `ucl_object_find_key' >> uclparse.o: In function `uclparse_chap_mutual': >> /usr/src/usr.sbin/ctld/uclparse.c:91: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:98: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:105: undefined reference to = `ucl_object_find_key' >> uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:112: more undefined = references to `ucl_object_find_key' follow >> uclparse.o: In function `uclparse_toplevel': >> /usr/src/usr.sbin/ctld/uclparse.c:235: undefined reference to = `ucl_iterate_object' >> /usr/src/usr.sbin/ctld/uclparse.c:278: undefined reference to = `ucl_iterate_object' >> /usr/src/usr.sbin/ctld/uclparse.c:317: undefined reference to = `ucl_iterate_object' >> uclparse.o: In function `uclparse_auth_group': >> /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to = `ucl_iterate_object' >> /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to = `ucl_iterate_object' >> uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined = references to `ucl_iterate_object' follow >> uclparse.o: In function `uclparse_target_lun': >> /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to = `ucl_object_find_key' >> /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to = `ucl_object_find_key' >> uclparse.o: In function `uclparse_target': >> /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to = `ucl_iterate_object' >> collect2: error: ld returned 1 exit status >>=20 >> *** [ctld.full] Error code 1 >>=20 >> make[4]: stopped in /usr/src/usr.sbin/ctld >> 1 error >>=20 >> make[4]: stopped in /usr/src/usr.sbin/ctld >> *** [all_subdir_usr.sbin/ctld] Error code 2 >>=20 >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery Confirmed: after a cleanworld without WITH_META_MODE=3Dyes a (re-)build = with WITH_META_MODE=3Dyes based buidlworld buildkernel sequence = completed just fine. (I did not try a cleanworld with = WITH_META_MODE=3Dyes.) [My other note about "/usr/bin/ld: unrecognised emulation mode: = elf32ppc_fbsd" for an amd64 host to powerpc cross build via clang still = applies as it was without WITH_META_MODE=3Dyes in the first place.] Side note: devel/powerpc64-gcc has differing /usr/local/include related search path = behavior for: A) amd64 host -> powerpc64 cross builds: no /usr/local/include in the = search path. (No devel/powerpc64-gcc Makefile with-local-prefix addition = involved.) B) powerpc64 host -> powerpc64 "self hosted cross builds": has = /usr/local/include in the search path. (With or without = with-local-prefix in the Makefile.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon May 30 23:42:13 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 966E5B546CD; Mon, 30 May 2016 23:42:13 +0000 (UTC) (envelope-from rionda@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F37C1E74; Mon, 30 May 2016 23:42:13 +0000 (UTC) (envelope-from rionda@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id h185so91976273qke.2; Mon, 30 May 2016 16:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=vlFuNRulj12hXbaTb9UvP7eLlYaMM1xDdwASShlV6SA=; b=yEkMAdQ5i/KnsIZDIYwK/H9MqqeGSCMMdJotsT2/Wo3LhjEkDW0/G+gMU0lhlrqpYq 3B2kVWMYvKZfUht1KAOSFUmEnlOn6S+IBBPnEYLaMUXZHDNZ0o9Z1drB9GO56i9DH9Q2 AepyVYZ6noj3K69oSwRufop0RdUB92rdgFZqF4oxrEYUYZKll8HdUKFOb2jK+idgt65d /q3YHjFeYAFx+8LxBhDug5swp9vMoR4+fonz+U7kYGa/3uvHeeW5ilWgW4p04Hya8kGz +ITK6cLDilskf5daX9a2O+jKygbOW/hrpL5ku7bZCgT9mf0kiozsSFAztfjMQEJkXGfl VCqg== 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:from:in-reply-to :date:cc:message-id:references:to; bh=vlFuNRulj12hXbaTb9UvP7eLlYaMM1xDdwASShlV6SA=; b=fvcPY7q5+2PcZepY+BaO+7Od8V8m31vsPPGVWy2bRHFKw1MXOQcx+1THo3/T+E/E1L frOE60Wkr+xowgExrWBKWomX8/M9nnz/qnSzUJq3pcB4H3ThV4M7fV28M1VpHorxcw5D /RjygRMibj78+ghf8r63RhzQfN2b5rNjUQYkyECx+GDumvjkI6QWw4wRwCd0fqfCjyXs wrECNcuy4OaxOFN+ELtYi8vnbsOq78dGK+gllMPafNPCu4rgUEyZO3HVzi9AkmTqw5Aw VkdEcG3W9/vyTxd0lYCQmh4nVI/0aYgM4TYtkwiP5cV8znE2EgKw7OBTfzgkoT6u38vP D04A== X-Gm-Message-State: ALyK8tKtHwNVI33r0sgtJSUdwxgvaHjb0aW1a14EQiwZTDExnNYehLqJQP7eQ2tH9wxB3g== X-Received: by 10.55.173.84 with SMTP id w81mr2938569qke.115.1464651732527; Mon, 30 May 2016 16:42:12 -0700 (PDT) Received: from [10.78.107.164] ([64.94.31.206]) by smtp.gmail.com with ESMTPSA id s106sm7486638qge.3.2016.05.30.16.42.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 16:42:11 -0700 (PDT) Sender: Matteo Riondato Subject: Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Matteo Riondato In-Reply-To: Date: Mon, 30 May 2016 19:42:07 -0400 Cc: Mark Millard , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 23:42:13 -0000 --Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On May 30, 2016, at 11:29 AM, Bryan Drewery wrote: > > I should have mentioned that to enable META_MODE after not having it on > you should do a 'make cleanworld' first. This should probably be mentioned in src.conf(5) then. Best, Matteo --Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F 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----- iEYEARECAAYFAldMz88ACgkQ2Mp4pR7Fa+xgXACeOwMGgrSXFypvwkbQSYQtMcyX a2QAoIQuTpBpcMK4Im+cYkm3uEhTUHsm =8eEK -----END PGP SIGNATURE----- --Apple-Mail=_4A4C2305-76CE-49FE-86D9-33E44EB3E42F-- From owner-freebsd-toolchain@freebsd.org Tue May 31 00:40:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F089B5352E for ; Tue, 31 May 2016 00:40:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 E8721185F for ; Tue, 31 May 2016 00:40:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14136 invoked from network); 31 May 2016 00:40:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 May 2016 00:40:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 20:40:47 -0400 (EDT) Received: (qmail 5876 invoked from network); 31 May 2016 00:40:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 May 2016 00:40:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2522DB1E001; Mon, 30 May 2016 17:40:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use] From: Mark Millard In-Reply-To: Date: Mon, 30 May 2016 17:40:41 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 00:40:45 -0000 [This adds armv6 information to a prior note that was just powerpc = based. The powerpc example material is listed first then it is noted = that armv6 ended up similar in my attempt.] On 2016-May-29, at 11:32 PM, Mark Millard = wrote: > [It may well be that powerpc is not an intended cross compile target = via clang since clang is insufficient for an FreeBSD/powerpc ABI = compliant buildworld as stands. Still I use this to illustrate the more = general points for clang use in cross builds.] >=20 > The failure: >=20 >> --- libc.so.7.full --- >> /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd >> Supported emulations: elf_x86_64_fbsd elf_i386_fbsd >> clang: error: linker command failed with exit code 1 (use -v to see = invocation) >> *** [libc.so.7.full] Error code 1 >>=20 >> make[4]: stopped in /usr/src/lib/libc >> 1 error >>=20 >> make[4]: stopped in /usr/src/lib/libc >> *** [lib/libc__L] Error code 2 >=20 > Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link = operation. >=20 > The log shows the ld command was via clang=E2=80=99s front end as far = as what the build did directly (just a prefix shown): >=20 >> --- libc.so.7.full --- >> /usr/bin/clang -target powerpc-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'nm' NMFLAGS=3D'' lorder trivial-vdso_tc.So bt_close.So bt_conv.So = bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So > . . . >=20 > The -B does not point to a place with a powerpc specific ld command: >=20 >> # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin >> total 1395 >> -rwxr-xr-x 1 root wheel 827248 May 29 22:20 ctfmerge >> -rwxr-xr-x 1 root wheel 534712 May 29 22:20 sysinit >> -rwxr-xr-x 1 root wheel 960784 May 29 22:20 ctfconvert >=20 > As far as I can tell a potentially proper path would have been: >=20 > /usr/local/powerpc-freebsd/bin/ld >=20 > if a devel/powerpc-binutils port existed and was installed. (No such = port exists.) >=20 > I do not know if other TARGET_ARCH=E2=80=99s have similar problems or = not (even if they have a binutils port). >=20 >=20 > This was not a WITH_META_MODE=3Dyes context. >=20 >=20 > make.conf was empty and src.conf was: >=20 > TO_TYPE=3Dpowerpc > # > KERNCONF=3DGENERICvtsc-NODEBUG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITH_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > # lldb requires missing atomic 8-byte operations for powerpc (non-64) > WITHOUT_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I finally tried a amd64 host -> armv6 (rpi2) cross build for freebsd = 11.0. amd64 -> armv6 for freebsd 11.0 also ended up with linker vs. file = format/content mismatches: in this case what was reported was about the = crti.o format when attempting to link libc.so.7.full . The error = messages were not explicit about the linker path used, unfortunately. = .../tmp/usr/bin as listed in the -B had only the same 3 file names (and = no ld) as was shown above for the powerpc context. Again it is a context of using the clang front end to indirectly get to = the linker with "-target" needing to guide details if the selection of = the linker is to be automatic. (Otherwise -B likely needs to point to = where an appropriate tool set is to be found [including ld].) armv6 for freebsd 11.0 is likely intended to be supported, unlike = powerpc possibly being viewed as irrelevant currently because of clang's = code generation issues for powerpc variants. armv6-gnueabihf-freebsd11.0 for modern hardfloat vs. = armv6-gnueabi-freebsd11.0 for temporary softfloat may need distinct = linkers (or other tools)? (Possibly via distinct -B's?) I'm not sure if the following additional item is a potential issue or = not: While there is a devel/arm-gnueabi-binutils there is no = devel/arm-gnueabihf-binutils. But I notice that -target = armv6-gnueabihf-freebsd11.0 is in use now for freebsd 11.0. Targets of = the form armv6-gnueabi-freebsd10* are probably still needed to support = 10.x for rpi's and the like. (So is another port needed?) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue May 31 02:21:02 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 833D3B55958 for ; Tue, 31 May 2016 02:21:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-192.reflexion.net [208.70.211.192]) (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 4919E1F52 for ; Tue, 31 May 2016 02:21:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15856 invoked from network); 31 May 2016 02:20:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 May 2016 02:20:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 30 May 2016 22:21:00 -0400 (EDT) Received: (qmail 8883 invoked from network); 31 May 2016 02:21:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 May 2016 02:21:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 644F5B1E001; Mon, 30 May 2016 19:20:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: 11.0 -r300944 buildworld amd64 -> armv6/armv7a cross build: Some XCPP and XCC use without -target specified so it rejects -march=armv7a From: Mark Millard Date: Mon, 30 May 2016 19:20:54 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <80DF38BA-CC08-4E58-9B19-CFBE72CF7262@dsl-only.net> To: Bryan Drewery , FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 02:21:02 -0000 [Warning: The following report is already based on trying to work around = prior problems already noted elsewhere. That makes these somewhat more = suspect. The -march=3Darmv7a that is rejected below is from = XCC/XCXX/XCPP content in my src.conf. I later list the src.conf content = used.] [WITH_META_MODE=3Dyes is in use. cleanworld had been done before hand.] Example failure: > # more = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/include/rpcsvc/key_prot= .h.meta > # Meta data file = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/include/rpcsvc/key_prot= .h.meta > CMD RPCGEN_CPP=3D/usr/bin/clang-cpp\ -march=3Darmv7a\ -mcpu=3Dcortex-a7\= -B/usr/local/arm-gnueabi-freebsd/bin\ -DCOMPAT_SOFTFP\ = -mfloat-abi=3Dsoftfp\ \ = -L/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft\ \ = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/libsoft\ \ = -B/usr/obj/clang/arm.armv6/usr/src/tmp/usr/bin\ = -B/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft rpcgen -C -h = -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > CWD /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/include/rpcsvc > TARGET key_prot.h > -- command output -- > clang-cpp: warning: argument unused during compilation: = '-mcpu=3Dcortex-a7' > clang-cpp: warning: argument unused during compilation: = '-mfloat-abi=3Dsoftfp' > clang-cpp: warning: argument unused during compilation: = '-L/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft' > error: unknown target CPU 'armv7a' > *** Error code 1 . . . rpcb_prot.h was similar. These appear to be because -target armv6-???-freebsd11.0 was not = supplied to clang-cpp (given that -march=3Darmv7a was supplied to = clang-cpp via src.conf material but armv7a is not a variation of the = host (amd64) context). (I try to be sure that clang-cpp is always told the specific -march that = I=E2=80=99m targeting in case clang-cpp provides macro definitions on = that basis that might be used.) Adding a -target in XCPP and retrying got farther but failed for XCC not = getting a -target and so another rejection of -march=3Darmv7a happened: > # more = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/gnu/lib/libssp/libssp_n= onshared/ssp-local.o* > # Meta data file = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/gnu/lib/libssp/libssp_n= onshared/ssp-local.o.meta > CMD /usr/bin/clang -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/arm-gnueabi-freebsd/bin -DCOMPAT_SOFTFP -mfloat-abi=3Dsoftfp = -L/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/libsoft = -B/usr/obj/clang/arm.armv6/usr/src/tmp/usr/bin = -B/usr/obj/clang/arm.armv6/usr/src/libsoft/usr/libsoft -O -pipe = -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libssp_nonshared/.. = -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/lib= ssp = -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/inc= lude -fPIC -DPIC -fvisibility=3Dhidden -mfloat-abi=3Dsoftfp -std=3Dgnu99 = -Qunused-arguments -c = /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libss= p/ssp-local.c -o ssp-local.o > CMD=20 > CWD = /usr/obj/clang/arm.armv6/usr/src/worldsoft/usr/src/gnu/lib/libssp/libssp_n= onshared > TARGET ssp-local.o > -- command output -- > error: unknown target CPU 'armv7a' > *** Error code 1 . . . Some of the other clang command line arguments (-mcpu and -B) are also = from my src.conf file. More is missing for a normal compile than just = -target material. [Note that having even just a "redundant" -march=3Darmv6 in = XCC/XCXX/XCPP is a good testing technique for proving that all the usage = has sufficient context to allow such an explicit specification from the = right family.] Supporting details. . . make.conf empty. src.conf (before forcing XCPP to have an armv6 family -target): TO_TYPE=3Darmv6 TOOLS_TO_TYPE=3Darm-gnueabi # KERNCONF=3DRPI2-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBSOFT=3D WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D # # # To based on clang (via system)... # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils... # .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/bin/clang -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/${TOOLS_TO_TYPE}-freebsd/bin XCXX=3D/usr/bin/clang++ -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/${TOOLS_TO_TYPE}-freebsd/bin XCPP=3D/usr/bin/clang-cpp -march=3Darmv7a -mcpu=3Dcortex-a7 = -B/usr/local/${TOOLS_TO_TYPE}-freebsd/bin .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system)... # #COMPILER_TYPE=3Dclang .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue May 31 04:20:02 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC73AB55E1D for ; Tue, 31 May 2016 04:20:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 6D5AE19E3 for ; Tue, 31 May 2016 04:20:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29423 invoked from network); 31 May 2016 04:19:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 May 2016 04:19:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 31 May 2016 00:20:00 -0400 (EDT) Received: (qmail 8665 invoked from network); 31 May 2016 04:20:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 May 2016 04:20:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E3745B1E001; Mon, 30 May 2016 21:19:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use] From: Mark Millard In-Reply-To: <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> Date: Mon, 30 May 2016 21:19:54 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <311011FA-F5B0-499D-AE47-31D430257A8A@dsl-only.net> References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> To: FreeBSD Current , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 04:20:02 -0000 On 2016-May-30, at 5:40 PM, Mark Millard wrote: > [This adds armv6 information to a prior note that was just powerpc = based. The powerpc example material is listed first then it is noted = that armv6 ended up similar in my attempt.] >=20 > On 2016-May-29, at 11:32 PM, Mark Millard = wrote: >=20 >> [It may well be that powerpc is not an intended cross compile target = via clang since clang is insufficient for an FreeBSD/powerpc ABI = compliant buildworld as stands. Still I use this to illustrate the more = general points for clang use in cross builds.] >>=20 >> The failure: >>=20 >>> --- libc.so.7.full --- >>> /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd >>> Supported emulations: elf_x86_64_fbsd elf_i386_fbsd >>> clang: error: linker command failed with exit code 1 (use -v to see = invocation) >>> *** [libc.so.7.full] Error code 1 >>>=20 >>> make[4]: stopped in /usr/src/lib/libc >>> 1 error >>>=20 >>> make[4]: stopped in /usr/src/lib/libc >>> *** [lib/libc__L] Error code 2 >>=20 >> Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link = operation. >>=20 >> The log shows the ld command was via clang=E2=80=99s front end as far = as what the build did directly (just a prefix shown): >>=20 >>> --- libc.so.7.full --- >>> /usr/bin/clang -target powerpc-unknown-freebsd11.0 = --sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'nm' NMFLAGS=3D'' lorder trivial-vdso_tc.So bt_close.So bt_conv.So = bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So >> . . . >>=20 >> The -B does not point to a place with a powerpc specific ld command: >>=20 >>> # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin >>> total 1395 >>> -rwxr-xr-x 1 root wheel 827248 May 29 22:20 ctfmerge >>> -rwxr-xr-x 1 root wheel 534712 May 29 22:20 sysinit >>> -rwxr-xr-x 1 root wheel 960784 May 29 22:20 ctfconvert >>=20 >> As far as I can tell a potentially proper path would have been: >>=20 >> /usr/local/powerpc-freebsd/bin/ld >>=20 >> if a devel/powerpc-binutils port existed and was installed. (No such = port exists.) >>=20 >> I do not know if other TARGET_ARCH=E2=80=99s have similar problems or = not (even if they have a binutils port). >>=20 >>=20 >> This was not a WITH_META_MODE=3Dyes context. >>=20 >>=20 >> make.conf was empty and src.conf was: >>=20 >> TO_TYPE=3Dpowerpc >> # >> KERNCONF=3DGENERICvtsc-NODEBUG >> TARGET=3D${TO_TYPE} >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER=3D >> WITH_SYSTEM_COMPILER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> # lldb requires missing atomic 8-byte operations for powerpc (non-64) >> WITHOUT_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > I finally tried a amd64 host -> armv6 (rpi2) cross build for freebsd = 11.0. >=20 > amd64 -> armv6 for freebsd 11.0 also ended up with linker vs. file = format/content mismatches: in this case what was reported was about the = crti.o format when attempting to link libc.so.7.full . The error = messages were not explicit about the linker path used, unfortunately. = .../tmp/usr/bin as listed in the -B had only the same 3 file names (and = no ld) as was shown above for the powerpc context. >=20 > Again it is a context of using the clang front end to indirectly get = to the linker with "-target" needing to guide details if the selection = of the linker is to be automatic. (Otherwise -B likely needs to point to = where an appropriate tool set is to be found [including ld].) >=20 > armv6 for freebsd 11.0 is likely intended to be supported, unlike = powerpc possibly being viewed as irrelevant currently because of clang's = code generation issues for powerpc variants. >=20 > armv6-gnueabihf-freebsd11.0 for modern hardfloat vs. = armv6-gnueabi-freebsd11.0 for temporary softfloat may need distinct = linkers (or other tools)? (Possibly via distinct -B's?) >=20 >=20 > I'm not sure if the following additional item is a potential issue or = not: >=20 > While there is a devel/arm-gnueabi-binutils there is no = devel/arm-gnueabihf-binutils. But I notice that -target = armv6-gnueabihf-freebsd11.0 is in use now for freebsd 11.0. Targets of = the form armv6-gnueabi-freebsd10* are probably still needed to support = 10.x for rpi's and the like. (So is another port needed?) >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I looked around some more and I think I've found one or two points = missed in some of the WITH_SYSTEM_COMPILER coverage. Such may explain = part of the above. A) The bootstrap clang compiler is built to automatically use the = WITH_BINUTILS_BOOTSTRAP instances of the binutils if I understand right. B) The system clang compiler is not. So, for example, it by default uses = /usr/bin/ld as the linker. C) =46rom what I've seen WITH_SYSTEM_COMPILER for cross-builds is not = building the WITH_BINUTILS_BOOTSTRAP binutils (and so is not putting the = them in a place that it would use via -B, which might then manage to = redirect the system clang to find those WITH_BINUTILS_BOOTSTRAP = binutils). D) This may get odder when hardfloat vs. libsoft is considered: what = tools need to be different tool instances for building libsoft? Are the = armv6-gnueabihf-freebsd11.0 related tools sufficient to cover = armv6-gnueabi-freebsd11.0 (libsoft's softfloat) without switching to any = other tool(s)? Side note: There is also another difference [this just mentions some material from = another, later report that I made on the lists]: E) The bootstrap clang compilers/cpp does not need -target and allows = selection of -march from the target family and tracks when such is done. = But there are contexts that still assume this status when = WITH_SYSTEM_COMPILER is in use but the system compiler does not have = this property for cross-build usage. The examples that I've noticed are = tied to building libsoft. An appropriate -target is always needed, = potentially even for clang-cpp to have the fully correct behavior. =3D=3D=3D Mark Millard markmi at dsl-only.net