amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils

[John Baldwin]

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 at 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 at 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