Different bindings generated on aarch64 vs x86

[weskerfoot]

I am getting this error with https://github.com/weskerfoot/NimPath. But strangely it only happens on one machine (rockpro64 running Manjaro). On my other Arch Linux machines (x86), it detects it properly as cstring not ptr uint8 .

/home/wes/NimPath/src/nimpath.nim(87, 29) Error: type mismatch: got <cstring, cint, cstring, cstring, cint>
but expected one of:
proc htmlreadmemory(buffer: ptr uint8; size: cint; Url: ptr uint8;
                    encoding: ptr uint8; options: cint): htmldocptr_1258292046
  first type mismatch at position: 1
  required type for buffer: ptr uint8
  but expression 'input_p' is of type: cstring

Same version of clang (15.0.7), same version of Futhark (0.9.3), same version of Nim (1.6.10). The only differences are, Manjaro vs. Arch and aarch64 vs x86, and libxml2 2.11.4-1 vs 2.10.4-4 (Arch vs Manjaro)

This is the declaration in the Arch version:

XMLPUBFUN htmlDocPtr
		htmlReadMemory		(const char *buffer,
					 int size,
					 const char *URL,
					 const char *encoding,
					 int options);

This is the declaration in the Manjaro version

XMLPUBFUN htmlDocPtr XMLCALL
		htmlReadMemory		(const char *buffer,
					 int size,
					 const char *URL,
					 const char *encoding,
					 int options);

The only difference is the macro XMLCALL which I'm not sure about. Could that be causing issues?
Any idea what could be going on here?
Removing XMLCALL doesn't seem to help.

I'm guessing it has something to do with the different architectures and how clang detects things.

[weskerfoot]

I also tried running with -d:futharkRebuild -d:opirRebuild just in case that was causing issues and it didn't change anything.

[PMunch]

Hmm, that is quite strange. It's not impossible that libclang behaves differently between architectures, but this particular instance of a char * should be picked up the same I believe. Could you check a couple things for me? In your Nim cache folder for your project (normally in ~/.cache/nim/), what is the full name of the futhark_X.nim and opir_X.nim files? Are they the same on both machines? Have either machine used a newer Nim version at some point and have ended up with a .nimble/pkgs2 folder? Does this contain an older version of Futhark? Are you sure you only have one version of libclang in your /usr/lib folder? I'm leaning towards it somewhere just picking up the incorrect version of something and messing up, but it's hard to tell.

[weskerfoot]

Looks like I did actually have multiple versions installed at some point on the x86 (Arch) machine

[wes@stark .nimble]$ ls pkgs2/ | grep futhark
futhark-0.9.3-f2d7e2a7bef17c386cfa6a2cce5cba987f96081d
[wes@stark .nimble]$ ls pkgs/ | grep futhark
futhark-0.7.3

Not sure how this happened. Removed everything and reinstalled nimble and now I just have pkgs.

There was a pkgs2 on the other machine but it was empty.

I just reinstalled nim/nimble on the aarch64 machine to see if that had any effect but still getting the same error.

This is the cache on the Arch machine

[wes@stark nimpath_r]$ pwd
/home/wes/.cache/nim/nimpath_r
[wes@stark nimpath_r]$ ls *futhark*
futhark_2612907DDC8BF5D2.nim  futhark_278229342F556C3A.nim  futhark_F2EF75AAFFF9F270.nim  futhark-includes.h

The other one didn't have anything cached yet.

I tried deleting both caches, but that didn't help. It still detects it as ptr uint8 on the Manjaro/aarch64 machine.

Here are the libclang .so files

aarch64

[wes@hircine ~]$ ls /usr/lib/libclang
libclang-cpp.so     libclang-cpp.so.15  libclang.so         libclang.so.15      libclang.so.15.0.7

x86

[wes@stark ~]$ ls /usr/lib/libclang
libclang-cpp.so     libclang-cpp.so.15  libclang.so         libclang.so.15      libclang.so.15.0.7

clang -print-resource-dir points to 15.0.7 on both machines.

I will try setting everything up in a docker container and see if it works there.

Just to confirm, which version would be the correct one that should be getting picked up?

[PMunch]

The other one didn't have anything cached yet.

That's a bit suspect. Once Futhark runs it should cache both the opir_X.json file and the futhark_X.nim file in the Nim cache folder. If they aren't there something has gone wrong.

The correct behaviour should be cstring for char *.

[weskerfoot]

The other one didn't have anything cached yet.

That's a bit suspect. Once Futhark runs it should cache both the opir_X.json file and the futhark_X.nim file in the Nim cache folder. If they aren't there something has gone wrong.

The correct behaviour should be cstring for char *.

Ah, I must have missed it because I wasn't thinking it would be named test1, sorry for the confusion.

I see this on the aarch64 one

[wes@hircine ~]$ find . -name "*opir*json"
./.cache/nim/opir_r/opir.json
./.cache/nim/test1_d/opir_6BDFCD00C2BBABDC.json
[wes@hircine ~]$ find . -name "*futhark*nim"
./.cache/nim/test1_d/futhark_FD472F41297393B2.nim

and then on x86

[wes@stark ~]$ find . -name "*opir*json"
./.cache/nim/test1_d/opir_6BDFCD00C2BBABDC.json
./.cache/nim/opir_r/opir.json

[wes@stark ~]$ find . -name "*futhark*nim"
./.cache/nim/test1_d/futhark_FD472F41297393B2.nim

So it looks like they are generating the same files I guess

[weskerfoot]

I get the same error inside a docker container running https://hub.docker.com/r/agners/archlinuxarm/tags

I installed Nim using pacman since choosenim doesn't support aarch64 BTW.

I'll try to package it up into a Dockerfile I suppose, but not sure if you can run it without a VM.

[weskerfoot]

Ok, I tested it again with this Dockerfile and I still get the same error, which is very weird.

FROM --platform=linux/arm64/v8 agners/archlinuxarm:latest

RUN pacman -Syu --noconfirm
RUN pacman -S --noconfirm nim clang git pkg-config
RUN git clone https://github.com/weskerfoot/NimPath.git
ENV PATH $PATH/root/.nimble/bin
ENTRYPOINT ["/bin/sh", "-c", "export PATH=$PATH:/root/.nimble/bin; cd NimPath && nimble install -y && nimble test"]

Just running docker build . and then docker run <image id> should trigger it

[weskerfoot]

If I change the image to pull from archlinux:latest and run it on x86 it works.

libxml2 is still using a different version as mentioned before, 2.10.4-4 on aarch64 and 2.11.4-1 on x86.