fix Mac install as clang no longer has that option

[srajabi]

The following error occurs when trying to pip install hnswlib:
clang: error: the clang compiler does not support '-march=native'

The command:
clang -cc1 --help | grep march
Returns nothing.

Mac no longer has "-march=native" option.

This PR modifies setup.py to not include that option for mac.

[yurymalkov]

Hi @srajabi, can you please provide more details?
It works fine on my mac with Apple clang version 12.0.0 (clang-1200.0.31.1) though clang -cc1 --help | grep march also returns nothing to me (but I see march mentioned in the clang release notes https://clang.llvm.org/docs/ReleaseNotes.html)

[searchivarius]

@yurymalkov I suspect it's M1.

[MiloTodt]

I have been able to reproduce this issue.
Clang:
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Device:

Error output:

[yurymalkov]

Yeah, it seems to be M1 specific (https://stackoverflow.com/questions/65966969/why-does-march-native-not-work-on-apple-m1 )
It seems to be already fixed in a different PR #299 ?
Can someone with M1 please test it (and I'll merge it)? I do not have access to M1

[yurymalkov]

Though it have been fixed for cmake only and it still omits march native for intel mac builds.

[srajabi]

@yurymalkov

Looks like I'm a bit ahead of you for clang version though:

$ clang --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

This issue would persistently present itself for a few days, but now I can't reproduce it at all.

I'm not on an M1 mac, and I don't think @MiloTodt is either given the screenshot.

Edit: trying to sort out if there's some caching going on with pip since installing it correctly from my branch

[yurymalkov]

Oh, got it. I was inattentive. Can this be a bug in clang?

[srajabi]

You might be able to help me here, I'm not sure why but it's no longer executing the BuildExt function. I've modified it to be something erroneous just for a sanity check.

My build now never includes the --march=native, I'm on master:

clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -I/Users/sohail.rajabi/WS/github/hnswlib/venv/include -I/usr/local/Cellar/[email protected]/3.9.7_1/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c /var/folders/k2/6ybn62qn6bj4f1g34s63h_4m88vsfm/T/tmp3ypju_q8.cpp -o var/folders/k2/6ybn62qn6bj4f1g34s63h_4m88vsfm/T/tmp3ypju_q8.o -std=c++14

Could be a bug in Clang, the above behaviour probably makes it super hard to track this down.

[srajabi]

It seems pip will continue to use the cached shared object file stubbornly despite my best efforts, tried:

• pip install -e . -vvv --isolated --no-cache-dir
• pip install -e . -vvv --isolated --no-cache-dir --force-reinstall --ignore-installed --no-binary :all:
• pip cache purge
• pip cache remove hnswlib

Only thing that consistently seems to force recompilation with the -march=native option is deleting the venv, git clean -xfd, recreating the venv and then doing pip install -e . --no-cache-dir --ignore-installed --no-binary hnswlib -v

But I can see the -march=native in the logs and it no longer throws an exception. Very confusing :(

Declining the PR as it doesn't seem to be an hnswlib issue but perhaps a clang bug.

[yurymalkov]

I see. Thanks for looking into it!