`libutf8proc.a: error adding symbols: file format not recognized` blocking build on Windows 11 on ARM via WSL

[BioTurboNick]

`libutf8proc.a: error adding symbols: file format not recognized` blocking build on Windows 11 on ARM via WSL

[giordano]

Ah, yeah, I don't think cleanall is supposed to touch the cache in deps, on a git bisect run running make cleanall is useful but if it cleaned the also the deps cache you'd be downloading, unpacking and installing llvm all the time.

[giordano]

Since utf8proc is compiled locally from source it sounds like a problem in your toolchain? What compiler are you using? What version? What's the output of

file /mnt/c/users/nicho/repos/julia/usr/lib/libutf8proc.a

?

[BioTurboNick]

Hmm. Why just that one file though? A toolchain issue is possible, though I don't think I did anything unusual.

The output is:

/mnt/c/users/nicho/repos/julia/usr/lib/libutf8proc.a: current ar archive

Compiler version:

nicho@AuroraSurface11:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

[giordano]

Why just that one file though?

I don't know, but building on aarch64-linux is regularly tested and it works fine, I also build often on another aarch64-linux system and I have no problems.

The output is:

Right, file on an archive isn't particularly enlightening. Try this instead:

cd $(mktemp -d)
ar x /mnt/c/users/nicho/repos/julia/usr/lib/libutf8proc.a
file utf8proc.o
readelf -h utf8proc.o

[BioTurboNick]

utf8proc.o: Intel amd64 COFF object file, no line number info, not stripped, 8 sections, symbol offset=0x53f14, 62 symbols, 1st section name ".text"
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start

Possibly relevant is that I initially started with Make.user pointing to mingw. I removed that line since, and had done make cleanall many times.

Just investigated further, and make -C deps clean-utf8proc fixed it. Should cleanall have caught this? Or should the build process have noticed something needed rebuilding? Or is this just an expected hazard of this kind of thing? If the latter I'll close this.

[giordano]

 Intel amd64 COFF object file

That's the wrong format, and it explains the error message.

[giordano]

Should cleanall have caught this?

I think make cleanall deletes the entire usr/ subdir, no?

Or should the build process have noticed something needed rebuilding?

Make checks timestamps, not file formats.

[BioTurboNick]

Should cleanall have caught this?

I think make cleanall deletes the entire usr/ subdir, no?

Yeah, though it doesn't do anything to deps/scratch subfolders, which seems to be where the dependencies get compiled. Based on the make VERBOSE=1 output I was seeing, all it was doing was copying the libutf8proc.a file from the scratch\utf8proc-<hash> subfolder. make -C deps clean-utf8proc actually removes the libutf8proc.a file.