OSX build error: "/etc/os-release" does not exist
maparent opened this issue · comments
Could you create a PR for it as I don't know if we have an OSX maintainer? Thanks!
I will do it over the weekend, and try to build atomspace properly as well. I found many issues with install_location in both code bases. No promises for long-term maintanance, but I am confident I can make it work short-term.
Here's a quick hack:
diff --git a/cmake/Summary.cmake b/cmake/Summary.cmake
index fe4a99727..a2cbf2789 100644
--- a/cmake/Summary.cmake
+++ b/cmake/Summary.cmake
@@ -4,9 +4,13 @@ set(summary_willnotbuild "")
set(summary_willnotbuild_d "")
set(max_name_length "0")
-file(READ "/etc/os-release" _OSR)
-string(REGEX MATCH "PRETTY_NAME=\"([a-xA-Z0-9 \\.,:;!@%#/()]*)" _BARF ${_OSR})
-set(OS_RELEASE ${CMAKE_MATCH_1})
+if (APPLE)
+ set(OS_RELEASE "APPLE Unknown release")
+else (APPLE)
+ file(READ "/etc/os-release" _OSR)
+ string(REGEX MATCH "PRETTY_NAME=\"([a-xA-Z0-9 \\.,:;!@%#/()]*)" _BARF ${_OSR})
+ set(OS_RELEASE ${CMAKE_MATCH_1})
+endif (APPLE)
macro(summary_add name description test)
string(LENGTH ${name} namelength)
does it work?
That problem is solved by the following:
@@ -4,10 +4,6 @@ set(summary_willnotbuild "")
set(summary_willnotbuild_d "")
set(max_name_length "0")
-file(READ "/etc/os-release" _OSR)
-string(REGEX MATCH "PRETTY_NAME=\"([a-xA-Z0-9 \\.,:;!@%#/()]*)" _BARF ${_OSR})
-set(OS_RELEASE ${CMAKE_MATCH_1})
-
macro(summary_add name description test)
string(LENGTH ${name} namelength)
if (${namelength} GREATER ${max_name_length})
@@ -45,7 +41,7 @@ endmacro(summary_show_part)
macro(summary_show)
message("")
- message("Building for ${OS_RELEASE}")
+ message("Building for ${CMAKE_SYSTEM_NAME}")
summary_show_part(summary_willbuild summary_willbuild_d
"The following components will be built:")
summary_show_part(summary_willnotbuild summary_willnotbuild_d
I'm now moving on to RPATH issues. I have atomspace built and passing most tests, except 27 tests using libsmob.so. But some of my cmake code is not portable yet. I will keep you posted.
But ${CMAKE_SYSTEM_NAME} doesn't actually report the release... it only reports the OS name (e.g. Linux, for me)
added CMAKE_SYSTEM_VERSION
I've set CMAKE_BUILD_WITH_INSTALL_RPATH to TRUE. I could put that in if (APPLE) if you want; but I think it may be a good idea in general. Open to discuss.
But I clearly needed this so libraries would load.
For me, CMAKE_SYSTEM_VERSION returns the OS kernel version, not the actual system version. For me, it returns 4.8.0-0.bpo.2-amd64 which is just some rando kernel; whereas /etc/os-release is Debian GNU/Linux 9 (stretch)
fair enough. I'll hide it in an IF.
I suspect that setting CMAKE_BUILD_WITH_INSTALL_RPATH to TRUE will break unit tests.
We've had repeated arguments about the unit tests, there is a strong contingent that wants to be able to run them without installing first. Which kind-of makes sense - you don't want to install something that's broken.
I see this:
# RPATH handling (see https://cmake.org/Wiki/CMake_RPATH_handling)
# Note: RPATH only supported under Linux!
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib/opencog")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
and so I am guessing that for OSX, the path "${CMAKE_INSTALL_PREFIX}/lib/opencog" is somehow wrong.
Actually, with the base configuration as is, I have the bare name of the library (which fails.) I tried using INSTALL_NAME, and cmake kept trying to use the build path. RPath works fine on Mac (contra the cmake page quoted.)
I had to move the calculation in the macro, because CMAKE_SYSTEM_NAME is not yet defined at the point where you calculated OS_VERSION.
The CI tests are failing: 23% tests passed, 10 tests failed out of 13 -- https://circleci.com/gh/opencog/cogutil/253 which is almost surely due to the rpath change.
Thank you, I just made it conditional to APPLE.
Thank you, I just made it conditional to APPLE.
Hang on, the tests are running now, and cogutil passed, lets see if atomspace passes.
PS: this works with gcc-9 in homebrew, not with clang.
this works with gcc-9 in homebrew, not with clang.
I'll take patches for that, or an error message that prints "clang won't work".