:LeaderfInstallCExtension Fails to build on MacOS with Xcode

[Herk2]

• vim or neovim?
  • vim
  • [x ] neovim
• Output of vim --version or nvim --version: NVIM v0.10.0-dev-2983+g55f6a1cab-Homebrew
• Output of :echo has("python"): has 0
• Output of :echo has("python3"): 1
• Output of :echo &pythondll(only vim, not neovim):
• Output of :echo &pythonthreedll(only vim, not neovim):
• Output of :py print(sys.version): 3.11.4 (main, Jun 20 2023, 17:37:48) [Clang 14.0.0 (clang-1400.0.29.202)]
• Output of :py3 print(sys.version): 3.11.4 (main, Jun 20 2023, 17:37:48) [Clang 14.0.0 (clang-1400.0.29.202)]
• Output of :echo g:Lf_Debug_Cmd:
• Output of :echo g:Lf_FilesFromCache:
• Operating system:
  • Linux
  • [ x] Mac OS X
  • Windows
  • Etc.
• Configurations related to LeaderF in vimrc: No

Describe your question, feature request, or bug.

The problem is a bug in the way the -arch flag is passed to clang.
Running 'LeaderfInstallCExtension' fails and generates the following output:
Begin to compile C extension of Python3 ...
running build
running build_ext
building 'fuzzyMatchC' extension
clang -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -
fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX
12.sdk -I/opt/homebrew/opt/binutils/include arm64 -I/opt/homebrew/opt/pyth
[email protected]/Frameworks/Python.framework/Versions/3.11/include/python3.11 -c fu
zzyMatch.c -o build/temp.macosx-12-arm64-cpython-311/fuzzyMatch.o
clang: error: no such file or directory: 'arm64'
error: command '/usr/bin/clang' failed with exit code 1
The problem was determined to be an incorrect passing of the arch flag. The -arch flag was passed with a trailing space. This resulted in a wrong invocation, where the command inculded this flag like this: 'arch ' arm64.
See "Clang Error on Mac: No Such File or Directory: 'arm64' · Issue #3847 · Ericsson/codechecker"
Ericsson/codechecker#3847
The "[fix] is simply to pass arch flag correctly. See [fix] Pass arch flag correctly by vodorok · Pull Request #3854 · Ericsson/codechecker Ericsson/codechecker#384

I believe I can create the C-Extension myself if I have access to the source-file (fuzzyMatch.c).

Steps to reproduce

Run :LeaderfInstallCExtension

Actual behaviour

See the next section.

Build fails with the output:

Running 'LeaderfInstallCExtension' fails and generates the following output:
Begin to compile C extension of Python3 ...
running build
running build_ext
building 'fuzzyMatchC' extension
clang -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -
fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX
12.sdk -I/opt/homebrew/opt/binutils/include arm64 -I/opt/homebrew/opt/pyth
[email protected]/Frameworks/Python.framework/Versions/3.11/include/python3.11 -c fu
zzyMatch.c -o build/temp.macosx-12-arm64-cpython-311/fuzzyMatch.o
clang: error: no such file or directory: 'arm64'

Expected behaviour

The Python C Extension would be created.

[Yggdroot]

The problem was determined to be an incorrect passing of the arch flag. The -arch flag was passed with a trailing space. This resulted in a wrong invocation, where the command inculded this flag like this: 'arch ' arm64.
See "Clang Error on Mac: No Such File or Directory: 'arm64' · Issue #3847 · Ericsson/codechecker"
Ericsson/codechecker#3847
The "[fix] is simply to pass arch flag correctly. See [fix] Pass arch flag correctly by vodorok · Pull Request #3854 · Ericsson/codechecker Ericsson/codechecker#384

Could you fix it as per the information?

[Herk2]

I found a more concrete reason for the “LeaderfInstallCExtension”  build process is not finding an ‘arm64’ folder - at least not on my device. The -I include path to the ‘arm64’ folder used by “LeaderfInstallCExtension” does not match the path to the ‘arm64’ folder on my machine, which has an empty dir named 240 between the binutils & include dirs. Leaderf’s path: ( -/opt/homebrew/opt/binutils/include/arm64 ) Mydevice’s path ( /opt/homebrew/opt/binutils/240/include/arm64 ). That shouldn’t be hard to fix. As for the initial problem I reported, I’m beginning to think that the incorrect specification of the -arch flag was committed by a third party program’s invocation of clang, and doesn’t have anything to do with LeaderF. For now, I will remove the empty ‘240’ dir from my device’s path to ‘arm64 and re-run “LeaderfInstallCExtension”  I will let you know the result as soon as possible.  I have to go into town for a while, so it may not be for a couple of hours.

…

On Jul 12, 2023, 10:40 AM +0700, Yggdroot ***@***.***>, wrote: > The problem was determined to be an incorrect passing of the arch flag. The -arch flag was passed with a trailing space. This resulted in a wrong invocation, where the command inculded this flag like this: 'arch ' arm64. > See "Clang Error on Mac: No Such File or Directory: 'arm64' · Issue #3847 · Ericsson/codechecker" > Ericsson/codechecker#3847 > The "[fix] is simply to pass arch flag correctly. See [fix] Pass arch flag correctly by vodorok · Pull Request #3854 · Ericsson/codechecker Ericsson/codechecker#384 Could you fix as per the information? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Yggdroot]

tensorflow/tensorflow#15484 is similar issue, hope this may help.

[Herk2]

Thanks for the tensorflow link.  I tried the solution mentioned, but since I wasn’t lacking a value for the location of the Command Line Tools, nothing happened. The error reporting output by :LeaderfInstallCExtension isn’t, in itself, enough to tell what’s going on.  After double & tripple checking the error reporting output by :LeaderfInstallCExtension, I cannot see any problems with the paths. On my Mac M1, there are two paths leading to an ‘arm64' file/dir. Earlier I didn’t notice that and mistakenly (& carelessly) followed the first path I saw.  So, if all 3 of the paths in the :LeaderfInstallCExtension's output are valid and culminate in apparently existing files or dirs (the 2nd of which is ‘arm64’ — which has no content), I can't see why the build is failing — unless the '-arch arm64' specification was misapplied and its misapplied value was subsequently used to designate a src/dest file or dir and failed. For reference, here is the complete output from :LeaderfInstallCExtension, lines broken out for easy viewing. Begin to compile C extension of Python3 ... running build running build_ext building 'fuzzyMatchC' extension clang -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g - fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -I/opt/homebrew/opt/binutils/include/arm64 ***@***.***/Frameworks/Python.framework/Versions/3.11/include/python3.11 -c fuzzyMatch.c -o build/temp.macosx-12-arm64-cpython-311/fuzzyMatch.o clang: error: no such file or directory: 'arm64' error: command '/usr/bin/clang' failed with exit code 1 I think I’ll install LeaderF on my Intel Mac and see if the C-Extension installation works there. Do you have access to the source code or the programmer(s) who install the C-Extension wrote :LeaderfInstallCExtension?

…

On Jul 12, 2023, 12:56 PM +0700, Yggdroot ***@***.***>, wrote: tensorflow/tensorflow#15484 is similar issue, hope this may help. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Yggdroot]

The source code is at https://github.com/Yggdroot/LeaderF/tree/master/autoload/leaderf/fuzzyMatch_C.
:LeaderfInstallCExtension is just call https://github.com/Yggdroot/LeaderF/blob/master/install.sh.

[Herk2]

Thank you. I’ll see what I can do.

…

On Jul 12, 2023, 9:46 PM +0700, Yggdroot ***@***.***>, wrote: The source code is at https://github.com/Yggdroot/LeaderF/tree/master/autoload/leaderf/fuzzyMatch_C. :LeaderfInstallCExtension is just call https://github.com/Yggdroot/LeaderF/blob/master/install.sh. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>