Date: Mon, 09 Apr 2018 12:27:18 -0700 From: John Baldwin <jhb@freebsd.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: Mark Millard <marklmi26-fbsd@yahoo.com>, freebsd-toolchain@freebsd.org Subject: Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils Message-ID: <1666724.ZHi5oRvF8N@ralph.baldwin.cx> In-Reply-To: <20180407221447.63e016cc@kan> References: <D9BAEC2B-AED4-4031-8B60-658660DBCF28@yahoo.com> <4410009D-E857-4BB0-B865-9294D24187F5@yahoo.com> <20180407221447.63e016cc@kan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, April 07, 2018 10:14:47 PM Alexander Kabaev wrote: > On Sat, 7 Apr 2018 17:01:30 -0700 > Mark Millard <marklmi26-fbsd@yahoo.com> wrote: > > > On 2018-Apr-7, at 4:37 PM, Alexander Kabaev <kabaev at gmail.com> > > wrote: > > > > > On Sat, 7 Apr 2018 18:43:17 -0400 > > > Alexander Kabaev <kabaev@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1666724.ZHi5oRvF8N>