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

Don't invoke make directly; use CMAKE_BUILD_TOOL #10

Merged
merged 5 commits into from
Feb 23, 2021

Conversation

ke6jjj
Copy link
Contributor

@ke6jjj ke6jjj commented Feb 23, 2021

This project depends on GNUMake, which may not be called make on
all systems. Use the more portable CMAKE_BUILD_TOOL variable instead.

This project depends on GNUMake, which may not be called `make` on
all systems. Use the more portable `CMAKE_BUILD_TOOL` variable instead.
Use `CMAKE_BUILD_TOOL` instead of `make`.
@JayKickliter
Copy link
Contributor

let's hold off on merging this because erlang-pbc builds are failing on at least macOS after merging a similar PR. It shouldn't break anything, but I want to find the root cause

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

@JayKickliter which branch is failing? I can test on MacOS and probably get to that root cause.

@evanmcc
Copy link
Contributor

evanmcc commented Feb 23, 2021

master and patch-1 are failing on big sur

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

I see it:

checking whether we are cross compiling... configure: error: in `/Users/jeremy/src/git/erlang-erasure-check/_build/c_src/gf-complete/src/gf-complete':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[3]: *** [gf-complete/src/gf-complete-stamp/gf-complete-configure] Error 1
make[2]: *** [CMakeFiles/gf-complete.dir/all] Error 2
make[1]: *** [all] Error 2

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

Haven't gotten to the bottom of it yet, but I see the issue:

configure:3485: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -o conftest -O3 -DNDEBUG   conftest.c  >&5
conftest.c:11:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
         ^~~~~~~~~
1 error generated.

@JayKickliter
Copy link
Contributor

That's exactly the error that prompted this PR: helium/erlang-pbc#8

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

What I'm noticing is that invoking cc as /usr/bin/cc produces different behavior than invoking it directly as /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc, even though, nominally, /usr/bin/cc is just a link for the latter. When compiling with /usr/bin/cc things work just fine.

It appears that this version of clang is checking argv[0] to determine how it should behave.

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

I'm currently reading this Cmake article, which may be our solution:

https://discourse.cmake.org/t/help-with-cc-clang-environment-and-cmake/2221

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

This works:

make SDKROOT=`xcrun --show-sdk-path`

Now to just find a portable/easy way to ensure it runs.

@JayKickliter
Copy link
Contributor

JayKickliter commented Feb 23, 2021

this looks like a potential solution:

index e3b1f2b..41249e4 100644
--- a/c_src/CMakeLists.txt
+++ b/c_src/CMakeLists.txt
@@ -12,6 +12,11 @@ include(ASan)
 IF (APPLE)
   set(CMAKE_MODULE_LINKER_FLAGS "-flat_namespace -undefined suppress")
   set(CMAKE_MACOSX_RPATH 1)
+  execute_process(COMMAND
+    xcrun --show-sdk-path
+    OUTPUT_VARIABLE APPLE_SDK_ROOT
+    )
+  set(sludgeOS_SDKENV "SDKROOT=${APPLE_SDK_ROOT}")
 ENDIF()

 #
diff --git a/c_src/cmake/FindGFComplete.cmake b/c_src/cmake/FindGFComplete.cmake
index 18fa5ba..6cdd09b 100644
--- a/c_src/cmake/FindGFComplete.cmake
+++ b/c_src/cmake/FindGFComplete.cmake
@@ -19,7 +19,8 @@ ExternalProject_Add(gf-complete
                     $ENV{CONFIGURE_ARGS}
                     CC=${CMAKE_C_COMPILER}
                     CFLAGS=${CMAKE_C_FLAGS_${BUILD_TYPE_UC}}
-  BUILD_COMMAND     make -j
+                    ${sludgeOS_SDKENV}
+  BUILD_COMMAND     make -j ${sludgeOS_SDKENV}
   BUILD_BYPRODUCTS  ${CMAKE_CURRENT_BINARY_DIR}/lib/libgf_complete.a
   INSTALL_COMMAND   make install
   )
diff --git a/c_src/cmake/FindJerasure.cmake b/c_src/cmake/FindJerasure.cmake
index 3b7e800..87db016 100644
--- a/c_src/cmake/FindJerasure.cmake
+++ b/c_src/cmake/FindJerasure.cmake
@@ -23,7 +23,8 @@ ExternalProject_Add(jerasure
                     CC=${CMAKE_C_COMPILER}
                     "CFLAGS=-I${CMAKE_CURRENT_BINARY_DIR}/include ${CMAKE_C_FLAGS_${BUILD_TYPE_UC}}"
                     LDFLAGS=-L${CMAKE_CURRENT_BINARY_DIR}/lib
-  BUILD_COMMAND     make -j
+                    ${sludgeOS_SDKENV}
+  BUILD_COMMAND     make -j ${sludgeOS_SDKENV}
   BUILD_BYPRODUCTS  ${CMAKE_CURRENT_BINARY_DIR}/lib/libJerasure.a
   INSTALL_COMMAND   make install
   )

the same needs to be done for the jerasure dep and it we'd need to make sure it's portable (unless there's a better, less-ugly fix you can think of)

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

It's definitely ugly, but I can't think of anything better for now. I tried this and it Works On My Box.

@JayKickliter
Copy link
Contributor

do you want to incorporate it into your PR (see updated suggested diff above) so you don't have to rebase? either way is fine

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

Yes, I'm testing right now. Will update this branch with OSX fixes.

@JayKickliter
Copy link
Contributor

thanks! And sorry for mixing concerns and stepping on your PR

@JayKickliter
Copy link
Contributor

JayKickliter commented Feb 23, 2021

once updated I make check that it still works on older macOS (which I usually run) and linux

I still don't know why passing SDKROOT to autools+make fixes the problem.

Fix builds for Mac OS X hosts using a method that JayKickliter and I derived
while researching this current problem with CMake. In the future, CMake will
probably come up with some reasonable defaults that update CFLAGS properly
on Mac OS X so that it gets the proper `-isysroot <PATH>` that is sorely
needed when invoking `clang` as directly as CMake is doing.
@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

Happy to mix concerns here. I am an OS X user as well, so this is a two-bugs with one patch win-win for me.

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

Builds under FreeBSD 12.1-amd64 as well, now, too.

@JayKickliter
Copy link
Contributor

I've confirmed this works on macOS 10.14 Mojave. CI will test linux

@JayKickliter
Copy link
Contributor

we'll need to add this same fix to erlang-pbc

Copy link
Contributor

@JayKickliter JayKickliter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I'll merge when you think you're done tweaking.

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Feb 23, 2021

I think I'm done! I also updated my patch-1 branch of erlang-pbc just now.

@JayKickliter
Copy link
Contributor

branch of erlang-pbc just now
that PR merged. mind doing a rebase and reopening a new PR with your branch?

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

Successfully merging this pull request may close these issues.

3 participants