https://github.com/theAkito/docker-nim/actions/runs/6496642640/job/17644036806
Related to https://forum.nim-lang.org/t/9821.
Pointer size mismatch between Nim and C/C++ backend. You probably need to setup the backend compiler for target CPU.
The compiler runs on i386, but wants to be compiled as amd64.
Can anyone test if manually compiling Nim works on an actual i386 device?
I don't think Nim will figure out that you want to build it for 32-bit then unless you specify the --cpu flag yourself.
Generally it’s best to not provide the —cpu option
According to https://forum.nim-lang.org/t/9821#64816.
maybe something in the environment is messing it up? Like maybe the linux/386 env is actually all 64-bit but only with a 32-bit C compiler
I don't know that & I don't have a quick way to check it, but considering the environment is made by Docker, something used by thousands of machines every single day, I doubt there would be such an obvious error in it. At least, I could not find any bug report or complaint about this type of thing on the Docker side, yet.
unless you specify the --cpu flag yourself.
If that is the case, that'd be a shame, because this would mean quite some extra work, just to make it run for i386...
Try something like
static: echo sizeof(pointer)
The issue is in the build.sh script, it uses 'uname -m' to detect the arch, but within Docker container this command returns cpu architecture of the host machine (x86_64), and not the cpu of Docker's target platform.
Docker has global environment variables for easy multi-platform compiling. You can use it in your 'alpine.Dockerfile' like this:
ARG TARGETARCH
RUN \
...
sh build.sh --cpu ${TARGETARCH} && \
...
But, there's another problem. Default Docker's name for i386 arch is '386', but build.sh expects one of these: "i386 | i486 | i586 | i686 | bepc | i86pc".
I can only suggest you to band-aid fix the script (e.g. with sed) and submit a pull request for the Docker's '386' in 'build.sh' .
Generally it’s best to not provide the —cpu option According to https://forum.nim-lang.org/t/9821#64816.
I believe it's "Generally it’s best to not provide the —cpu option" in the context of Nim installed with choosenim on the arm cpu MacOS. And not directly related to your problem.
The issue is in the build.sh script, it uses 'uname -m' to detect the arch, but within Docker container this command returns cpu architecture of the host machine (x86_64), and not the cpu of Docker's target platform.
Yes. But all other architectures work (except s390x for other reasons I think?), just i386 does not. So, still fishy.
But, there's another problem. Apparently, default name for i386 arch in Docker is '386', but build.sh expects one of these: "i386 | i486 | i586 | i686 | bepc | i86pc".
Indeed. I wasn't sure if that might be a problem. Was aware of this "casual" adjustment, though.
I can only suggest you to band-aid fix the script (e.g. with sed) and submit a pull request for the Docker's '386' in 'build.sh' .
As a last resort, there are of course workarounds & I might use them. However, I'm not sure whether it's worth it & I don't even know, if anyone would use an i386 Nimage, in the first place. I sure don't need it.
I personally only need arm, arm64 & amd64. All other architectures are a courtesy to fellow Nim users & my curiousity.
Does anyone truly have interest in the i386 Nimage? If yes, I would find it worth working on it, if there are at least a couple of people truly needing it.
That said, thanks for your input. It is highly appreciated.
https://github.com/Archargelod/docker-nim
I also thank you very much for playing around with the image, trying to make it work somehow. :)