Reported by MacPorts: Sonoma w/16.2 compiler fails with pure cmake.
I just tried a pure cmake build under
macOS 14.7.3 23H417 arm64
Xcode 16.2 16C5032aI still get the same implicit function declaration errors as before.
Tested on seqouia, and the member-xdr tests are failing.
To do:
- Fix pure cmake build on macos, find out why this is failing. both sys/quota.h and rpcsvc/quota.h are being found.
- Add pure cmake testing to all machines with cmake.
Damned cmake is doing weird things....
Potential solution. I don't know if XCode includes any other compilers within its suite.
This could be incorrect if XCode supports compilers other than clang.
It probably won't hurt anything, as this is only used for the XDR type determination.
I use the command-line-tools compiler.
Sequoia (intel):
Last edit: Brad Lanam 2025-02-09
Big Sur (m1):
Sonoma (intel):
Fixed in 5.0.6.
And Sequoia (m1):
Fixed in 5.0.6
I still see the same comple error when using pure cmake for version 5.0.6:
config.h has the following lines
and then the compile fails with
I have no idea where
xdr_would come from.Was this on Sonoma again?
Sonoma:
I think my path check for MacOS fails for XCode.
I need to know what cmake's CMAKE_C_COMPILER is set to when using XCode.
I don't have enough disk space available to install xcode.
Can you try beta/di-5.0.7.tar.gz?
5.0.7 beta still does the same thing.
In config.h I pure cmake generates
define xdr_rq_bhardlimit xdr_
define xdr_rq_bsoftlimit xdr_
define xdr_rq_curblocks xdr_
define xdr_rq_fhardlimit xdr_
define xdr_rq_fsoftlimit xdr_
define xdr_rq_curfiles xdr_
define xdr_gqa_uid xdr_
white having autotools call cmake gnerates
define xdr_rq_bhardlimit xdr_u_int
define xdr_rq_bsoftlimit xdr_u_int
define xdr_rq_curblocks xdr_u_int
define xdr_rq_fhardlimit xdr_u_int
define xdr_rq_fsoftlimit xdr_u_int
define xdr_rq_curfiles xdr_u_int
define xdr_gqa_uid xdr_int
The only other difference I see is that autotools creates the build folder within the di-5.0.x, while MacPorts cmake creates the build folder at the same level as di-5.0.x.
Thanks for taking the time to test with 5.0.7.
The problem is that cmake is setting the compiler path to
/Library/Developer/CommandLineTools/usr/bin/cc(for command line tools), which is not a user-friendly compiler -- it will not compile a source file without additional arguments. I need a path such as/usr/bin/clang.I have to run the compiler on a small test file (
${MYCC} -I ${tinc} -E ${membernm}.c) in order to get and extract the xdr types.I put in a test in 5.0.7 to check for
/Applications/Xcode.app/, but I was mostly guessing at what path Xcode would use.Can you add a line to CMakeLists.txt:
message (FATAL_ERROR "== compiler: ${CMAKE_C_COMPILER}")around line 78 or so.
Or I can make a new beta version with some debugging in it.
Sorry, I can't install Xcode as I have no disk space for it, and I don't have access to MacOS with Xcode.
Sure enough:
This is really weird.
/usr/bin/clangshould work fine.I have an assumption that
/usr/bin/clangwill work if Xcode is installed. It does when command line tools is installed.The test file that gets compiled (actually just pre-processed) is:
As you can see, the
CMAKE_C_COMPILERthat gets set with command line tools doesn't have the include path built in.Essentially I just need any working C compiler. I will do some research on cmake and see if I can figure out how to run theirs. If you have any ideas, I am completely open.
Here is a bit more info about what Xcode/CLT install
However, they are not the same
Last edit: Marius Schamschula 2025-02-15
Well, this works. I guess I can try to put this in the CMakeLists.txt file.
I think we're trying to set things that the cmake PortGroup has already set for us.
Here's what the configure command invokes:
Of course some items are ignored:
The last one was deliberately set to deal with https://trac.macports.org/ticket/71791
Ok, can you try beta/di-5.0.8.tar.gz ?
I set SDKROOT if it is not already set. This works with CLT.
The cmake documentation says that CMAKE_SYSTEM_PREFIX_PATH is not supposed to be for users to mess with, but whatever works.
Setting DI_MATH is fine, nothing wrong with that. pkg-config is deliberately excluded, so it won't find libtommath, but I would leave DI_MATH there until such time someone wants to create a GMP variant. The non-GMP variant would need to set DI_MATH=DI_INTERNAL, otherwise the bad libtommath might be picked up.
Whoops. 5.0.8 is an abject failure.