On 11 Apr 2022, at 19:53, Fernando Apesteguía <fern...@freebsd.org> wrote: > > On Mon, Apr 11, 2022 at 7:24 PM <jbo@insane.engineer> wrote: ... >> gmake[1]: Entering directory >> '/wrkdirs/usr/ports/sysutils/cpufetch/work/cpufetch-1.00' >> Makefile:38: Unsupported arch detected: i386. See >> https://github.com/Dr-Noob/cpufetch#1-support >> Makefile:39: If your architecture is supported but the compilation fails, >> please open an issue in https://github.com/Dr-Noob/cpufetch/issues >> Makefile:40: *** Aborting compilation. Stop. >> gmake[1]: Leaving directory >> '/wrkdirs/usr/ports/sysutils/cpufetch/work/cpufetch-1.00' >> ===> Compilation failed unexpectedly. >> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to >> the maintainer. >> *** Error code 1 >> >> Upstream's Makefile uses $(shell uname -m) to determine the architecture >> [2]. My VMs are successfully reporting this as >> i386 which upstream's Makefile appears to support explicitly. After all, I'm >> also able to build this software >> on those VMs if just cloning & running gmake manually. >> >> I'm not really sure where to go from here. As I can build the software in >> FreeBSD i386 VMs I think >> that the issue is related to my port and not upstream. But then again, the >> build fails "within" upstream's Makefile. >> >> Could somebody help me out here? > > When the Makefile checks the output of uname -m, it compares the > result with a list of values that includes i686 but not i386. > I think a simple REINPLACE_CMD would suffice here. > > Since I failed to detect this, do you want me to fix it in the repo? I > will also send a patch upstream.
No need :) https://github.com/Dr-Noob/cpufetch/commit/0db9f1f5c26e57a6383f4609c5605ed5d3d41fd1 -Dimitry
signature.asc
Description: Message signed with OpenPGP
