Closed RishabhGarg108 closed 3 years ago
Why it is trying to use x86_64
linker on arm64
machine?
I have absolutely no clue. It was also strange for me.
I tried adding arch -arm64
prefix to make command but still got no luck :(
Are you building mlpack? what is model_test
?
Can you print the cmake
?
Are you building mlpack? what is model_test? I am building the "models" repository. Mlpack is already built on my system. Can you print the cmake?
ishanki@Ishankis-MacBook-Air build % cmake -D DEBUG=ON ../ -- The C compiler identification is AppleClang 12.0.0.12000032 -- The CXX compiler identification is AppleClang 12.0.0.12000032 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Armadillo: /usr/local/lib/libarmadillo.dylib (found suitable version "10.2.0", minimum required is "8.400.0") -- Found MLPACK: /usr/local/lib/libmlpack.dylib CMake Warning (dev) at /opt/homebrew/Cellar/cmake/3.19.3/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:426 (message): The package name passed to `find_package_handle_standard_args` (ensmallen) does not match the name of the calling package (Ensmallen). This can lead to problems in calling code that expects `find_package` result variables (e.g., `_FOUND`) to follow a certain pattern. Call Stack (most recent call first): CMake/FindEnsmallen.cmake:55 (find_package_handle_standard_args) CMakeLists.txt:116 (find_package) This warning is for project developers. Use -Wno-dev to suppress it.
-- Could NOT find ensmallen (missing: ENSMALLEN_INCLUDE_DIR) -- [download 1% complete] -- [download 2% complete] -- [download 4% complete] -- [download 5% complete] -- [download 7% complete] -- [download 9% complete] -- [download 10% complete] -- [download 11% complete] -- [download 12% complete] -- [download 13% complete] -- [download 14% complete] -- [download 15% complete] -- [download 16% complete] -- [download 17% complete] -- [download 18% complete] -- [download 19% complete] -- [download 20% complete] -- [download 21% complete] -- [download 22% complete] -- [download 23% complete] -- [download 24% complete] -- [download 26% complete] -- [download 27% complete] -- [download 28% complete] -- [download 30% complete] -- [download 31% complete] -- [download 33% complete] -- [download 34% complete] -- [download 36% complete] -- [download 37% complete] -- [download 39% complete] -- [download 40% complete] -- [download 41% complete] -- [download 42% complete] -- [download 43% complete] -- [download 45% complete] -- [download 46% complete] -- [download 48% complete] -- [download 49% complete] -- [download 50% complete] -- [download 51% complete] -- [download 52% complete] -- [download 54% complete] -- [download 56% complete] -- [download 57% complete] -- [download 58% complete] -- [download 59% complete] -- [download 60% complete] -- [download 61% complete] -- [download 63% complete] -- [download 64% complete] -- [download 65% complete] -- [download 66% complete] -- [download 67% complete] -- [download 69% complete] -- [download 70% complete] -- [download 71% complete] -- [download 73% complete] -- [download 74% complete] -- [download 75% complete] -- [download 76% complete] -- [download 78% complete] -- [download 79% complete] -- [download 80% complete] -- [download 81% complete] -- [download 82% complete] -- [download 83% complete] -- [download 84% complete] -- [download 85% complete] -- [download 86% complete] -- [download 87% complete] -- [download 88% complete] -- [download 89% complete] -- [download 91% complete] -- [download 92% complete] -- [download 93% complete] -- [download 94% complete] -- [download 96% complete] -- [download 97% complete] -- [download 98% complete] -- [download 99% complete] -- [download 100% complete]
@RishabhGarg108 Sorry, I meant the source code
Also looking at the first notice it shows that you are trying to build for x86_64
, please, have a look here: building for macOS-x86_64 but attempting to link with file built for macOS-arm64
I am building the latest mlpack/models. So you can look at the cmake source here
Also looking at the first notice it shows that you are trying to build for x86_64, please, have a look here: building for macOS-x86_64 but attempting to link with file built for macOS-arm64
I simply followed the build instructions from the README and did nothing fancy. Thats why I was confused why it was building for x86_64
.
I am guessing that it is having some issue with the boost libraries.
I will give a closer look at the cmake
file.
Is boost
still required for these models? I think in the meanwhile you can start by removing the unnecessary boost libraries.
Actually I am new to this project so I don't know much. Maybe @kartikdutt18 could give you better insights.
The tests currently use boost so to remove it, we would have to transfer them to catch. I am trying to fix the build right now...after that I will raise a PR or an issue for shifting to catch as well. Also the repo uses boost regex (will also need to transfer that).
Even if we remove all boost, this will not resolve the issue, Actually, the message says that it is not able to link with boost libraries since they are built for arm64
. If I understand the issue right your cmake is trying to build for x86_64
.
Even if we remove all boost, this will not resolve the issue, Actually, the message says that it is not able to link with boost libraries since they are built for
arm64
. If I understand the issue right your cmake is trying to build forx86_64
.
I am not a cmake expert, but while looking at it, I found this block of code. Here, it is handling for MacOSX, and lower versions. But there is nothing for MacOS 11. Could this be a potential cause ?
I have never used clang or macOS, I think you need to check if this block is executing, if not I do not see how it might affect the build. Also, it seems that cmake is able to find the compiler and the entire toolchain, I do not understand why it is trying to cross-compile into a different architecture Try to comment things out inside the CMake file, delete the entire build directory and restart the process.
@shrit , I dug a bit deeper and found out something.
This issue arose after I updated my cmake. My cmake version is 3.19.5. So, starting from version 3.19.2, cmake has provided CMAKE_APPLE_SILICON_PROCESSOR
environment variable that can be used to explicitly specify the architecture.
I also faced an error similar to what I am facing here while compiling the mlpack main repository. But there I was able to get around by using set(CMAKE_APPLE_SILICON_PROCESSOR "arm64")
.
But, two more things came up after this: -
I am not at all good with cmake. So, can you please try to find some solution to this. I am putting up some references which I found on internet. Hopefully you can make more sense out of then and it might save you some time looking online :-)
https://cmake.org/cmake/help/latest/variable/CMAKE_APPLE_SILICON_PROCESSOR.html#variable:CMAKE_APPLE_SILICON_PROCESSOR https://gitlab.kitware.com/cmake/cmake/-/issues/20989 https://discourse.cmake.org/t/how-to-determine-which-architectures-are-available-apple-m1/2401 https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_ARCHITECTURES.html
I am not 100% sure about my findings. Could you please take a closer look at it. Thanks!
The tests currently use boost so to remove it, we would have to transfer them to catch. I am trying to fix the build right now...after that I will raise a PR or an issue for shifting to catch as well. Also the repo uses boost regex (will also need to transfer that).
I can start working on migrating tests to catch, I even looked at catch...
@kartikdutt18 I want to confirm whether we want to use catch v3
or catch v2
?
The tests currently use boost so to remove it, we would have to transfer them to catch. I am trying to fix the build right now...after that I will raise a PR or an issue for shifting to catch as well. Also the repo uses boost regex (will also need to transfer that).
I can start working on migrating tests to catch, I even looked at catch... @kartikdutt18 I want to confirm whether we want to use
catch v3
orcatch v2
?
Is there a catch version 3, I think there is only https://github.com/catchorg/Catch2, maybe I'm missing something.
Hello, did anyone found the root of this problem ? I am still not able to figure out why it is happening :(
@RishabhGarg108 it might worth it that you compile a hello world program in C++ using CMake and clang.
Then use file ./hello_world
in order to see what is the type of binaries.
Let me know about the results.
@shrit I will try to do that and will share the results 👍
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! :+1:
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! :+1:
@RishabhGarg108 were you able to resolve this? I'm running into a similar issue with my m1 Mac where cmake is building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Nvm resolved, just needed to set the following in CMAKE for arm64
set(CMAKE_REQUIRED_LINK_OPTIONS "-arch;arm64")
I am getting the following error while building from source on M1 macbook air.
Please help me figure out this error.