On Tue, 2024-01-02 at 18:07 +0000, Dimitri John Ledkov wrote: > For cross building, as far as I can tell one needs to build the tool > twice - once for the BUILD architecture and once for HOST > architecture, use one during the build and package the other one into > the deb.
That's correct and I am currently pondering over a clever way to do that. > > I will most likely just copy the relevant definitions out of aout.h, both > > the generic and the alpha-specific stuff in order to both be able to drop > > reliance on aout.h in the kernel as well as make the package fully cross- > > buildable. > > But why? as far as I can tell, the a.out code path is never executed > as it seems like Debian has been using ELF based vmlinuz since like > before 2009. Are you sure that the a.out codepath of objstrip.c is > needed or executed at all? > > Or am I missing something, and like objstrip.c portions are executed > against some other a.out formatted things which are not Linux kernel? > > Should I provide a patch that adds printfs during a.out codepath > block, to see if it actually is ever executed? I think it's still reasonable to keep a.out support in the tool because users might use it for a.out binaries generated from other tools. Besides, it's just a matter of copying a few header definitions, so not really a blocker unless I am missing something. > > > > I would also prefer to get all relevant changes upstreamed. > > > > Upstream has policy of not carrying dead code, which in this case its > what it is for kernels built in like last decade. I was talking about aboot upstream which is maintained by Matt Turner from Gentoo these days [1]. Adrian > [1] https://github.com/mattst88/aboot/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913