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

[Mark Millard]

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.)


-- 
Alexander Kabaev

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)