Date: Tue, 10 Apr 2018 08:46:05 -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: <1889186.M1zOzkklTl@ralph.baldwin.cx> In-Reply-To: <20180409205829.37a11479@kan> References: <D9BAEC2B-AED4-4031-8B60-658660DBCF28@yahoo.com> <1666724.ZHi5oRvF8N@ralph.baldwin.cx> <20180409205829.37a11479@kan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, April 09, 2018 08:58:29 PM Alexander Kabaev wrote: > On Mon, 09 Apr 2018 12:27:18 -0700 > John Baldwin <jhb@freebsd.org> wrote: > > > 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. > > > > OSREL is an artifact of old times where we had wildly different specs. > This is not true anymore, so deorbiting the OSREL suffix makes sense. > For the time being, having binutils with same prefox as corresponding > GCC is actually a good thing. Note that the riscv64-binutils hack in Makefile.inc1 doesn't currently work since it assumes no OSREL suffix btw: src/Makefile.inc1: # If we do not have a bootstrap binutils (because the in-tree one does not # support the target architecture), provide a default cross-binutils prefix. # This allows riscv64 builds, for example, to automatically use the # riscv64-binutils port or package. .if !make(showconfig) .if !empty(BROKEN_OPTIONS:MBINUTILS_BOOTSTRAP) && \ ${MK_LLD_BOOTSTRAP} == "no" && \ !defined(CROSS_BINUTILS_PREFIX) CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_ARCH}-freebsd/bin/ However, it's hard to fix this right, so long term I'd like us to strip the OSREL instead. (Right now make tinderbox still happens to work for riscv64 because src/Makefile forces CROSS_TOOLCHAIN for riscv64 before Makefile.inc1 is included which sets CROSS_BINUTILS_PREFIX explicitly.) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1889186.M1zOzkklTl>