Skip to content
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

Compilation of rc-3.5.0 on Mac M1 2020 #1551

Closed
andrew-platt opened this issue Apr 28, 2023 · 5 comments
Closed

Compilation of rc-3.5.0 on Mac M1 2020 #1551

andrew-platt opened this issue Apr 28, 2023 · 5 comments

Comments

@andrew-platt
Copy link
Collaborator

Bug description
A new clone of rc-3.5.0 does not directly compile on MacbookPro17,1 (early M1 chipset) with Monterey

From HomeBrew:

  • CMake v 3.22.4
  • gcc/gfortran v 12.2
  • make 3.8.1
  • XCode command line 13.4?

Interestingly v 3.4.1 compiles just fine on this hardware. So there must be something in the rc-3.5.1 changes to CMake that cause linking issues on this specific hardware configuration.

IMG_9638

To troubleshoot, we checked everything in CMakeCache.txt, specified exact paths to all compilers and linkers, and checked the SDK version. Nothing appeared out of the ordinary in any of that. We also compared the link.txt and other files in CMake build system with a clean compile of rc-3.5.0 on an Intel based Mac, but did not find anything unusual.

I will attempt to commandeer a 2020 M1 and attempt this build process to reproduce.

To Reproduce
Steps to reproduce the behavior:

  1. Fresh clone of OpenFAST from GH
  2. checkout branch rc-3.5.0
  3. mkdir build; cmake .. -DBUILD_SHARED=On; make -j4 openfastlib
  4. Everything compiles, but linking fails

After checking this, git checkout v3.4.1 followed by removing everything in build and repeating step 3 above works just fine.

OpenFAST Version
rc-3.5.0 branch of OpenFAST

@deslaughter
Copy link
Collaborator

I think the CMake flag -DBUILD_SHARED=On needs to be changed to -DBUILD_SHARED_LIBS=On.

When I ran the CMake command in the "To Reproduce" section, it picked the following compilers

-- The CXX compiler identification is AppleClang 14.0.0.14000029
-- The C compiler identification is AppleClang 14.0.0.14000029
-- The Fortran compiler identification is GNU 12.2.0

Usually when I run the build on an M1 Mac, I set the C and C++ compilers to be gcc and g++, respectively.

@andrew-platt , do you know which compilers were used the bug report compilation?

I was able to reproduce the error with Undefined symbols for architecture arm64 in libmaplib.dylib. I expect this is an issue with the object libraries, but I'll have to do some more digging.

@andrew-platt
Copy link
Collaborator Author

That was a typo on my part, we used -DBUILD_SHARED_LIBS=On (I was typing from memory).

The CXX and C compilers were picked up by cmake as g++-12 and gcc-12 respectively. We double checked these in CMakeCache.txt to be certain.

Thanks for checking looking at this!

@andrew-platt
Copy link
Collaborator Author

andrew-platt commented Apr 28, 2023

The linker used was from /usr/bin/ld for both the 3.5.0 (failed linking), and in the 3.4.1 (successful compilation). I suspect you are right and it is an issue with the object libraries added in 3.5.0.

@deslaughter
Copy link
Collaborator

This issue should be resolved with PR #1555 which is now in the dev branch. Please give it a try when you have a chance.

@reos-rcrozier
Copy link
Contributor

This is probably just an issue with the order of compilation and ensuring the dependencies are correct. Object libraries were added for very good reasons on Linux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants