-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Bug: ld: symbol(s) not found for architecture arm64 #8211
Comments
What command(s) are you using to build? |
make clean && LLAMA_METAL=1 make -j |
Hmmm. Just ran this on a 2021 M1 MBP:
And then: And it succeeds without issue. Complete build logs
Which commit are you compiling against? I'll try resetting to that and see if I get the same issue. In the meantime, can you please fetch / pull and try again against latest master? This is really puzzling to me. |
Also, can you please paste in the section of your build output that includes Thank you! |
Quick note: While deprecated, the replacement for |
|
What is the output of |
Also, do you have any local changes? You can check with |
git rev-parse HEAD git status Untracked files: nothing added to commit but untracked files present (use "git add" to track) git stash |
I reset to the same commit hash as you and ran the same commands -- not getting the same errors that you are. From your last build log, this line is troubling:
I'm confused by a few things about this line.
Regardless, I'm wondering if the object file inclusion script in the makefile is causing problems and accidentally referencing these orphaned object files, and I'm wondering what an EDIT: Better yet, another possible solution is to do a completely fresh checkout of the repo in a new folder. That would let you keep the old folder around and better do root-cause-analysis if/when things work. Though I'm still curious how these bad files got here in the first place, and I'm wondering if there is a way we can program our makefile to be more defensive and not include spurious object files like this. |
Good points, but I didn't copy it over from an x86 box, and I'm able to build it fine by going back a week in commits. I blew it all out (having moved models elsewhere), and did a fresh close and fresh build, same issue. |
Here's uname -a: |
git reset --hard b3233 |
Same issue here. My device is Macbook Air M1 make cc -Iggml/include -Iggml/src -Iinclude -Isrc -Icommon -D_XOPEN_SOURCE=600 -D_DARWIN_C_SOURCE -DNDEBUG -DGGML_USE_ACCELERATE -DGGML_USE_BLAS -DACCELERATE_NEW_LAPACK -DACCELERATE_LAPACK_ILP64 -DGGML_USE_LLAMAFILE -DGGML_USE_METAL -DGGML_METAL_EMBED_LIBRARY -std=c11 -fPIC -O3 -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -pthread -Wunreachable-code-break -Wunreachable-code-return -Wdouble-promotion -c ggml/src/ggml-metal.m -o ggml/src/ggml-metal.o |
It looks like the assembler is building the object file for x86_64 instead of the native arm64, which is unexpected. What is the output of |
|
Does it work with this change to the diff --git a/Makefile b/Makefile
index bbfe0f12..19bec528 100644
--- a/Makefile
+++ b/Makefile
@@ -810,7 +810,7 @@ ggml/src/ggml-metal-embed.o: \
@echo ".incbin \"ggml/src/ggml-metal-embed.metal\"" >> $(TEMP_ASSEMBLY)
@echo ".globl _ggml_metallib_end" >> $(TEMP_ASSEMBLY)
@echo "_ggml_metallib_end:" >> $(TEMP_ASSEMBLY)
- @$(AS) $(TEMP_ASSEMBLY) -o $@
+ @$(AS) $(TEMP_ASSEMBLY) -target arm64-apple-darwin23.5.0 -o $@
@rm -f ${TEMP_ASSEMBLY}
endif
endif # GGML_METAL |
You saved my day!!! This works for me. I can build the latest llama.cpp finally. lol |
The suggested change fixes the issue. Thank you for your help. |
@slaren, you're a wizard. Trying to figure out where this problem was introduced, and my best guess is that it was somehow inserted with #8006. It's a fairly large change, and it was merged shortly after the last good release b3233 as reported by @quarterturn. There are a ton of changes in that PR, and I fear that it could be something innocuous like setting Otherwise, no major findings to report. Unless I can find a way to recreate this issue on my M1, then I think I'm a bit dead-ended in tracking this one down. |
#8006 made Maybe something like this would work to determine the native arch and pass it explicitly to the assembler: diff --git a/Makefile b/Makefile
index bbfe0f12..dfab0034 100644
--- a/Makefile
+++ b/Makefile
@@ -810,7 +810,8 @@ ggml/src/ggml-metal-embed.o: \
@echo ".incbin \"ggml/src/ggml-metal-embed.metal\"" >> $(TEMP_ASSEMBLY)
@echo ".globl _ggml_metallib_end" >> $(TEMP_ASSEMBLY)
@echo "_ggml_metallib_end:" >> $(TEMP_ASSEMBLY)
- @$(AS) $(TEMP_ASSEMBLY) -o $@
+ $(eval ARCH=$(shell uname -m))
+ @$(AS) $(TEMP_ASSEMBLY) -arch $(ARCH) -o $@
@rm -f ${TEMP_ASSEMBLY}
endif
endif # GGML_METAL Another option could be to use the C compiler instead, if the source file has the correct extension it should be able to compile it: diff --git a/Makefile b/Makefile
index bbfe0f12..dc3fc61a 100644
--- a/Makefile
+++ b/Makefile
@@ -803,14 +803,14 @@ ggml/src/ggml-metal-embed.o: \
ggml/src/ggml-common.h
@echo "Embedding Metal library"
@sed -e '/#include "ggml-common.h"/r ggml/src/ggml-common.h' -e '/#include "ggml-common.h"/d' < ggml/src/ggml-metal.metal > ggml/src/ggml-metal-embed.metal
- $(eval TEMP_ASSEMBLY=$(shell mktemp))
+ $(eval TEMP_ASSEMBLY=$(shell mktemp).s)
@echo ".section __DATA, __ggml_metallib" > $(TEMP_ASSEMBLY)
@echo ".globl _ggml_metallib_start" >> $(TEMP_ASSEMBLY)
@echo "_ggml_metallib_start:" >> $(TEMP_ASSEMBLY)
@echo ".incbin \"ggml/src/ggml-metal-embed.metal\"" >> $(TEMP_ASSEMBLY)
@echo ".globl _ggml_metallib_end" >> $(TEMP_ASSEMBLY)
@echo "_ggml_metallib_end:" >> $(TEMP_ASSEMBLY)
- @$(AS) $(TEMP_ASSEMBLY) -o $@
+ @$(CC) -c $(TEMP_ASSEMBLY) -o $@
@rm -f ${TEMP_ASSEMBLY}
endif
endif # GGML_METAL Somebody with intel and arm64 macs will need to test that. |
today I pull the latest commit, but it still fail to build with original makefile. but I tried this modification
this can work fine in MBA m1. just report this test result on mac. |
Today I pull the latest commit and modified the makefile as below, but it appears another error message. I ccache not found. Consider installing it for faster compilation. c++ -std=c++11 -fPIC -O3 -g -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wmissing-declarations -Wmissing-noreturn -pthread -Wunreachable-code-break -Wunreachable-code-return -Wmissing-prototypes -Wextra-semi -Iggml/include -Iggml/src -Iinclude -Isrc -Icommon -D_XOPEN_SOURCE=600 -D_DARWIN_C_SOURCE -DNDEBUG -DGGML_USE_ACCELERATE -DGGML_USE_BLAS -DACCELERATE_NEW_LAPACK -DACCELERATE_LAPACK_ILP64 -DGGML_USE_LLAMAFILE -DGGML_USE_METAL -DGGML_METAL_EMBED_LIBRARY -c ggml/src/ggml-blas.cpp -o ggml/src/ggml-blas.o Appreciate all your help. |
@napyang make sure you run |
@slaren Super thanks for your help. After run make clean and modified But if build without modified makefile, it still broken with this error. Super thanks again. ^_^ |
Until that is fixed, you should be able to fix that error with the changes listed in my previous comment #8211 (comment). You can also use |
I had exactly the same issue on Apple Silicon M3. In Makefile inside ifdef GGML_METAL_EMBED_LIBRARY I modified and it finally worked! |
What happened?
symbol not found compile error for Mac metal build. If I wind back a week with "git reset --hard master@{"7 days ago"}" it builds and executes fine.
2023 M2 MBP
Name and Version
Current master branch
What operating system are you seeing the problem on?
Mac
Relevant log output
The text was updated successfully, but these errors were encountered: