[MacPorts] #53027: binutils: libiberty installed to $prefix/include, conflicts in ports

[MacPorts]

#53027: binutils: libiberty installed to $prefix/include, conflicts in ports
-------------------------+-------------------------------------------------
 Reporter:  mojca        |      Owner:
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:
 Keywords:               |       Port:  arm-aout-binutils arm-elf-binutils
                         |  arm-none-eabi-binutils arm-none-linux-gnueabi-
                         |  binutils arm-rtems-binutils avr-binutils i386
                         |  -elf-binutils i386-mingw32-binutils i386-rtems-
                         |  binutils i960-rtems-binutils lm32-rtems-
                         |  binutils m68k-elf-binutils m68k-rtems-binutils
                         |  mips-elf-binutils mips-rtems-binutils mipsel-
                         |  linux-binutils msp430-binutils powerpc-rtems-
                         |  binutils ppc-linux-binutils sh-rtems-binutils
                         |  sparc-rtems-binutils spu-binutils x86_64-elf-
                         |  binutils
-------------------------+-------------------------------------------------
 I just noticed that when using the crossbinutils PortGroup, one ends up
 with:
 {{{
   /opt/local/${target}/host/lib/libiberty.a
   /opt/local/include/libiberty/*.h
 }}}
 The first one is not problematic, but files under `$prefix/include` are
 because any given binutils port would install that.

 I found a related commit:
 * https://github.com/macports/macports-
 ports/commit/bcdf26e5b403a4291f3c241f19e33eb86d7ca538

 Judging from the fact that bfd installs
 {{{
   /opt/local/${host}/bin/ld.bfd
   /opt/local/${host}/host/include/*.h
   /opt/local/${host}/host/lib/libbfd.a
   /opt/local/${host}/host/lib/libbfd.la
 }}}
 I guess that some recent update of binutils broke the `reinplace` patch.

 This requires:
 * a patch in the portgroup to fix the problem
 * a revbump (or ideally upgrade) of all affected `*-binutils` ports
 * probably a bit more testing with a couple of different binutils versions

 Maybe the older versions are not even affected and a fix would break older
 ports, I'm not sure.

 Existing binutils ports:
 || arm-aout-binutils                || @2.22             ||
 || arm-elf-binutils                 || @2.25             ||
 || arm-none-eabi-binutils           || @2.23.1           ||
 || arm-none-linux-gnueabi-binutils  || @2005q3-2         ||
 || arm-rtems-binutils               || @2.18             ||
 || avr-binutils                     || @2.27             ||
 || i386-elf-binutils                || @2.23.1           ||
 || i386-mingw32-binutils            || @2.21-3           ||
 || i386-rtems-binutils              || @2.18             ||
 || i960-rtems-binutils              || @2.16.1           ||
 || lm32-rtems-binutils              || @2.21.1           ||
 || m68k-elf-binutils                || @2.17             ||
 || m68k-rtems-binutils              || @2.18             ||
 || mips-elf-binutils                || @2.17             ||
 || mips-rtems-binutils              || @2.18             ||
 || mipsel-linux-binutils            || @2.16.1           ||
 || msp430-binutils                  || @2.21.1a-20120406 ||
 || powerpc-rtems-binutils           || @2.18             ||
 || ppc-linux-binutils               || @2.25             ||
 || sh-rtems-binutils                || @2.18             ||
 || sparc-rtems-binutils             || @2.18             ||
 || spu-binutils                     || @2.20.51.0.5      ||
 || x86_64-elf-binutils              || @2.23.1           ||

 See also #51935.

--
Ticket URL: <https://trac.macports.org/ticket/53027>
MacPorts <https://www.macports.org/>
Ports system for macOS