LLVM-embedded-toolchain-for-Arm icon indicating copy to clipboard operation
LLVM-embedded-toolchain-for-Arm copied to clipboard

[bug] ninja check-llvm-toolchain fails on FreeBSD

Open n0madcoder opened this issue 1 year ago • 4 comments

First of all, it seems to be similar to what happens in issue #492 but the line mentioned there to be causing the problem is patched in the main branch I tried on, plus this happens in FreeBSD.

I'm attaching logs at the end of the text. cmake.log contains the output of the cmake instruction and ninja.log contains the output of the ninja command to build the lib.

System information:

  • FreeBSD 14.1-RELEASE GENERIC amd64
  • python 3.11.10
  • cmake 3.30.5
  • ninja 1.11.1,4
  • clang 18.1.5
  • meson 1.5.2

Steps to reproduce:

$ git clone https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm.git
$ cd LLVM-embedded-toolchain-for-Arm
$ export CC=clang
$ export CXX=clang++
$ mkdir build && cd build
$ cmake .. -GNinja -DFETCHCONTENT_QUIET=OFF
$ ninja llvm-toolchain

And it seems to fail at this point in the process:

[3291/4496] Performing build step for 'picolibc_aarch64a'
...
[1090/1090] Generating newlib/libc_duplicates with a custom command
FAILED: newlib/libc_duplicates 
/home/n0mad/workspace/git-repos/LLVM-embedded-toolchain-for-Arm/build/_deps/picolibc-src/scripts/duplicate-names /usr/bin/nm newlib/libc.a newlib/libc_duplicates
Duplicate names in newlib/libc.a
0000000000000000 N $d
ninja: build stopped: subcommand failed.

It then attempts to continue for a bit (see ninja.log) but it ends up failing to an exit.

Not sure if being a picolibc build step this should be an issue on their repo too, or just keep it here.

cmake.log ninja.log

n0madcoder avatar Nov 15 '24 19:11 n0madcoder

let's cc @keith-packard too since it seems to be more picolibc related. I'll try to deep dive a little on the building process and steps again during the weekend

n0madcoder avatar Nov 29 '24 18:11 n0madcoder

Looks like scripts/duplicate-names needs a fix to ignore 'N' symbols (the nm manual says those are debugging symbols). The build is just trying to make sure each C library symbol is defined only once which it does by running nm on the library. It's not a perfect method, but it has found enough bugs to remain a useful tool.

keith-packard avatar Nov 30 '24 06:11 keith-packard

Thanks for the response, Keith (: it seems like changing the grep instruction in scripts/duplicate-names to:

"$NM" -g "$FILE" 2>/dev/null | grep ' [A-EG-MO-TVX-Z] ' | grep -v '__x86' | sort | uniq -d > "$OUTPUT"

makes the compilation to continue without failing at that step.

Now the issue seems to happen when running the test suite. It definitely doesn't like the cplusplus test, similar to the OpenBSD issue mentioned above, and when I disable it, the process still fails at some point under FreeBSD. I'm still tracing it trying to check if it's an error of mine in the environment setup before making more noise.

n0madcoder avatar Dec 07 '24 05:12 n0madcoder

Check out https://github.com/picolibc/picolibc/pull/890 -- that has your change to fix this.

keith-packard avatar Dec 08 '24 06:12 keith-packard