I’m aware that the elftoaout utility exists, this isn’t really my concern though.
I’m concerned about an upstream solution, preferably with an elftoaout utility being part of the upstream sources.
Hi Gregor, Adrian
I don't know if this is helpful, but Ubuntu Launchpad has a ppa package for elftoaout which has been built recently.
Cheers -- Rick
On August 10, 2018 8:12:47 PM ADT, Gregor Riepl <firstname.lastname@example.org
We could modify sparc-utils maybe that it builds on the release
architectures similar to what the hppa porters do with their palo package.
I'll have a look. It doesn't look like this package would only build/work on
sparc. Usefulness is a different matter - but that's probably outside the
scope of acceptance criteria?
Correct. Usefulness doesn't matter. Maybe there is another package or
upstream project that offers an elftoaout tool?
So for now, I manually modified the boot image build step to strip with
objcopy first, then convert with elftoaout from sparc-utils.
The resulting boot.img is identical to the one installed by
grub-ieee1275-bin_2.02+dfsg1-4 - that looks promising!
This means we have at least a method to build the boot code without a.out
support in objcopy. I also looked into making OpenBoot run the ELF binary
directly, but that seems impossible for an unexpected reason: boot.img is
written directly into the boot sector of the /boot partition, and there is
simply not enough space to accommodate the ELF binary. It's 816 bytes, while
the a.out is exactly 512.
I'll discuss integrating the change with the grub2 package maintainer and
upstream, if that's ok for you. And I'll take a look at the sparc-utils
package, maybe making it build for any instead of just sparc64 (as discussed).
Sorry for being brief. Alternate email is rickleir at yahoo dot com