Somebody claiming to be Tracey Emery wrote: > Hello ports, > > I'm not sure anyone is particularly interested in this but me, and the > patch is pretty gross and a significant change, so I'm sure it'll take > awhile before anyone really wants to review this.
I have a version of arm-none-eabi-* in mystuff that requests the R/M profile multilib config, which I use regularly at my day job. (For some Cortex-M parts, and some operations, having the appropriate multilib configuration available can be necessary to avoid pulling in library routines with illegal instructions.) While you're doing surgery on the build process to support a particular Cortex-M-targeted environment anyways might not be the worst possible time to pull that in as well. Previous work: https://marc.info/?l=openbsd-ports&m=159897831109275&w=2 It's a fairly small change in the Makefile (adding '--with-multilib-list=rmprofile' to CONFIGURE_ARGS for the arm-none-eabi flavour) but propagates to the PLIST for both gcc and newlib (which configures itself based on the GCC multilib configuration.) > In order to be able to work with Raspberry Pi Pico boards, and the like, > we need to have C++ headers. This patch adds a bootstrap and flavors the > whole port so that those can be built. > > I changed this to be more inline with the various Espressif xtensa > ports, in which the cross-compile tools are within their own > subdirectories of LOCALBASE. I'm not a fan of having my cross-compilers not be in the default $PATH. (I've never worked with xtensa parts so have not been paying attention to why it's done that way there.) > Now, I don't know if this is the right direction for the aarch64 > flavour, as I don't have anything to test that with, but it builds and > the arm flavour compiles code for the Raspberry Pi Pico SDK and it runs > on a board on at least amd64. I think one of the reasons my patch to enable R/M profile multilib didn't get any love was that the aarch64 flavour is needed for building the aarch64 bootloader, which makes it a critical system component. (I'm not sure whether or how it would work out to split the port into parallel copies so that the system boot people and the embedded devs don't interfere with each other, but that might be less worse than having the embedded devs maintain their own local versions?) > If this makes it, I'll send a port for the Raspberry Pi SDK which seems > to work great! And if not, I'm happy keeping this local. > > If you are currently using either or both flavours of this port > currently, please test this out to your devices. That would be greatly > appreciated! > > Thoughts? ok? A quick glance through the rewiring for the bootstrap build looks sensible to me. It might be a few weeks before I manage to allocate time to actually try it out on nontrivial builds. dave -- Dave Vandervies dj3va...@terse.ca Plan your future! Make God laugh!
