From owner-freebsd-toolchain@freebsd.org Mon Apr 9 19:52:47 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C983FF9E2C8 for ; Mon, 9 Apr 2018 19:52:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5ABB66EB85 for ; Mon, 9 Apr 2018 19:52:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id B3F4210B45D; Mon, 9 Apr 2018 15:52:46 -0400 (EDT) From: John Baldwin To: Alexander Kabaev Cc: Mark Millard , freebsd-toolchain@freebsd.org Subject: Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils Date: Mon, 09 Apr 2018 12:27:18 -0700 Message-ID: <1666724.ZHi5oRvF8N@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180407221447.63e016cc@kan> References: <4410009D-E857-4BB0-B865-9294D24187F5@yahoo.com> <20180407221447.63e016cc@kan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 09 Apr 2018 15:52:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 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, 09 Apr 2018 19:52:48 -0000 On Saturday, April 07, 2018 10:14:47 PM Alexander Kabaev wrote: > On Sat, 7 Apr 2018 17:01:30 -0700 > Mark Millard wrote: > > > On 2018-Apr-7, at 4:37 PM, Alexander Kabaev > > wrote: > > > > > On Sat, 7 Apr 2018 18:43:17 -0400 > > > Alexander Kabaev wrote: > > > > > > Come to think of it, I am not sure I understand the problem. > > > amd64-binutils installs "proper" x86_64-freebsd-prefixed binaries. > > > Did you expect amd64-freebsd-* ? > > > > My understanding was that cross-build tools are now supposed > > to have the -unknown and the os version (12.0 here) even > > when the cross-build is targeting the same environment as the > > host environment. In other words: that it is not supposed to > > be the same as plain binutils for the host but as-if it was > > from a different architecture. > > > > But I was checking my understanding. In part because it used > > to be that, for example, on amd64 the aarch64-binutils also > > omitted the -unknown and 12.0 but now has them. I just had > > to update my environment's references to such for that. (This > > was not a self-hosted cross-build context and it changed.) > > > > Also, there is a recent check-in, -r466699 , for ports that, > > in part, says: > > > > Log: > > Fix two more issues with r465416. > > > > - Force build of a cross-compiler by defining > > CROSS_DIRECTORY_STRUCTURE in CFLAGS even if the build host matches > > the build target. This fixes such a cross compiler to not > > include /usr/local/lib in its default library path (e.g. amd64-gcc > > when built on amd64). > > > > > > > > But that was for powerpc64-gcc, not powerpc64-binutils (for example). > > I do not know for sure if similar points should also apply to > > *-binutils ports. So, again, I was checking. > > > > (I might have just got involved between already-made and other pending > > updates for all I know.) > > > > > > Since I am not the maintainer of binutils ports, I missed wholesale > rename. I suspect something like the patch below will make > amd64-binutils follow the convention: > > P164: https://reviews.freebsd.org/P164 Huh, I didn't need this change when using amd64-xtoolchain-gcc, but it does seem correct. I wonder if you will need to fix the amd64-xtoolchain-gcc package as well. In general I actually don't like having the OS version present as the xtoolchain packages should not be version-specific (that is, I can use mips-gcc to compile 10, 11, or 12), and even if it was, it the _host's_ OS version is not necessarily the OS version of the target I want to build. However, GCC's FreeBSD specific bits currently require a major version for FBSD_MAJOR, and I had to resort to the hack in the commit above to set CROSS_DIRECTORY_STRUCTURE explicitly. If we were to drop OSREL from the GCC and BU targets then the normal cross logic in GCC would work such that I wouldn't have needed the hack. We could perhaps patch GCC to assume that if FBSD_MAJOR is not set it should assume some minimum default version (I think any value >= 6 is treated the same). We could then drop OSREL from the external toolchain ports (binutils and GCC) which I would prefer. -- John Baldwin