On Thu, Sep 08, 2022 at 04:45:13PM -0400, Dave Vandervies wrote:
> 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
I take a look at what you've got.
Thanks.
> 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.)
This was because it was non-trivial to get that bootstrapped junk to
build. Telling make the path to my tools was.
>
>
> > 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.
No problem, and thanks.
>
>
> dave
>
> --
> Dave Vandervies
> dj3vande@terse.ca
>
> Plan your future! Make God laugh!
--
Tracey Emery
No comments:
Post a Comment