Open byrnedo opened 1 year ago
ah damn, I just realised that there's possibly no actual debian openresty armv7 package for instance...
The reason for the architecture suffix is to identify them for the manifest step. If all of it works without them, then I think that's OK? I never advertised them, so any compatibility issue is people's own problem. Plus they should use tagged releases, of which these would be a new tag.
There are two kinds of images, built-from-source and built-from-upstream. If there's no architecture release upstream, we obviously can't support it directly. We can try still try to build it from source, but the QA level is different.
It looks like arm7
is not supported by LuaJIT? That is a blocker for sure.
Ok good, might make things a bit simpler.
Well I got it to build and run locally last night from source but it took absolutely ages. Would running any aspect of openresty confirm if luajit is working? Or would I have to have it evaluate some custom lua code to know?
Perhaps you can start with looking at LuaJIT itself and running its test suite in isolation. You should use OpenResty's fork. I'm curious what your hardware is.
I ran the build last night on a raspberry-pi 2b and then cross compiled on my mac M1 and both 'seem to work'. Ok yeah, good idea, can try that.
In searching for it I also found this for OpenResty luajit2-test-suite
. . Searching around, it seems people use LuaJIT and OpenResty on Raspberry Pi. Is this because it is older or 32-bit?
Have you tried the aarch64
images? Maybe they just work?
It takes about 2-3 hours to build using qemu, including architectures linux/amd64, linux/arm64, linux/s390x, linux/ppc64le, linux/arm/v7
Issue:
@neomantra Hi again. Is it vital that openresty images keep the arch suffix on the image names? Would it be ok to skip those?