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

[Alexander Kabaev]

On Mon, 09 Apr 2018 12:27:18 -0700
John Baldwin <jhb at 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 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

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.

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 963 bytes
Desc: Цифровая подпись OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20180409/e323fc51/attachment.sig>