Josh Grosse <[email protected]> writes: > On Thu, Nov 12, 2015 at 12:34:03AM +0100, J??r??mie Courr??ges-Anglas wrote: >> >> Right now p7zip fails to build on several archs, because of the rather >> lame approach to endianness taken by this port. This patch should allow >> to build p7zip on all archs supported by OpenBSD. >> >> ok? > > jca@, > > I'm fine with the changes, once the architectures can all be > tested. Back in the spring of 2007, this was tested on many > archs. And naddy@ had reported a failure on Alpha, which is included > in the patch to C/CpuArch.h.
IIUC this was a runtime failure, not a build failure. Right now p7zip doesn't *build* on those archs. > I'm just a maintainer. So I've added naddy in copy, as I'd like > someone with *prior* anxiety about the quality of the application > for portability to weigh in on this recommended revision. > > I'm fine with it, if it can be tested on these architectures. And I'm not > sure a vax/simh test would pass naddy's sniff test. I've heard it time > and again that real hardware may behave differently than an emulator. > > If this *can* run on vax, then the SHARED_ONLY can be dropped from the > Makefile, too. I didn't notice the SHARED_ONLY marker, but I'm tempted to keep the vax addition in this patch. It doesn't add maintenance burden, and perhaps one day vax will have shared libs, and unicorns will fly. Back to your concern: I don't think it's a reasonable approach to ask for tests on all architectures before introducing a change in a port. If we did that, the ports tree would be ridiculously small and lagging behind upstream. This fixes a *build* issue. A package broken at runtime on one arch or two is better than no package at all on ten architectures. http://build-failures.rhaalovely.net/alpha/2015-10-30/archivers/p7zip.log http://build-failures.rhaalovely.net/sparc64/2015-10-30/archivers/p7zip.log http://build-failures.rhaalovely.net/hppa/2015-10-30/archivers/p7zip.log -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
