Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
BioTurboNick opened this issue Sep 10, 2024 · 8 comments

Comments

@BioTurboNick
Copy link
Contributor

BioTurboNick commented Sep 10, 2024

Error when building on WIndows 11 on ARM via WSL (for Linux, not trying to cross-compile):

    LINK src/flisp/flisp
/usr/bin/ld: /mnt/c/users/nicho/repos/julia/usr/lib/libutf8proc.a: error adding symbols: file format not recognized
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:109: /mnt/c/users/nicho/repos/julia/src/flisp/flisp] Error 1
make[1]: *** [Makefile:363: flisp/libflisp.a] Error 2
make: *** [Makefile:62: julia_flisp.boot.inc.phony] Error 2

Bisected to: [0be0b38] support Unicode 15.1 via utf8proc 2.9.0 (#51799)

@BioTurboNick BioTurboNick changed the title libutf8proc.a: error adding symbols: file format not recognized blocking build on WIndows 11 on ARM via WSL libutf8proc.a: error adding symbols: file format not recognized blocking build on Windows 11 on ARM via WSL Sep 10, 2024
@giordano
Copy link
Contributor

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
Copy link
Contributor Author

BioTurboNick commented Sep 10, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

 Intel amd64 COFF object file

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

@giordano
Copy link
Contributor

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
Copy link
Contributor Author

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.

@giordano
Copy link
Contributor

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.

@BioTurboNick BioTurboNick closed this as not planned Won't fix, can't repro, duplicate, stale Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants