Fatal error: 'elf.h' file not found on macOS 10.15 #1744
Comments
asbjornu
changed the title
|
Are you able to build dotnet/coreclr on macOS 10.15 at all? This issue should probably be raised in dotnet/runtime (since dotnet/coreclr was consolidated there), ideally without source-build infra involved so there aren't as many variables to consider. |
|
I do build runtime on 10.15 without problems. I did not try source build for a while. |
|
I don't have a machine with 10.15 available, so I have to resort to GitHub Actions and the help from others (such as Homebrew/homebrew-core#60929 (comment)) and from everything I've seen, 10.15 fails consistently. I assume you've got |
|
@asbjornu I wonder, does Homebrew not require Xcode to be installed, and would that be where it normally comes from? I'm not particularly familiar with the Homebrew project, but my impression is that it builds an OSS ecosystem on top of macOS and other OSes, so perhaps avoiding using Xcode is something they're interested in. dotnet/runtime (and dotnet/coreclr) list Xcode as a requirement: https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/macos-requirements.md I'm sure this can be patched to work with different dependencies, but I have no idea how extensive a patch would be or if it would be reasonable to try to maintain it in the dotnet org repos. |
|
I did not find elf.h on my system, besides src/coreclr/src/pal/src/libunwind_mac/include/elf.h - but I don't think that is the one as added recently. And I realized I don't build old coreclr repo but runtime. The code looks similar but there may be some caveats. cc: @janvorli as expert in this area. |
|
I have upgraded my macOS to the latest version last week (10.15.6) and also the xcode to the latest one (11.7 IIRC). I can still build the runtime repo without issues. Let me check where the elf.h comes from. |
|
The exact commit being built above is https://github.com/dotnet/coreclr/tree/v3.1.8, FYI in case this is different in runtime/5.0. |
|
I was able to build the coreclr repo release/3.1 just fine too. |
|
|
|
So the build doesn't include the elf.h on my mac at all. Neither in coreclr nor in runtime repos. Using build.sh in coreclr and src/coreclr/build-runtime.sh in the runtime repo with no arguments. And it is not supposed to include it. I wonder if the problem somehow arises from the non-apple libunwind being installed and used by accident. It looks like in the runtime repo, it would cause the I can see that the build is being passed You can verify which libunwind.h the build is including e.g. this way (assuming you've ran the build.sh for debug configuration before, even though it has failed): Now you can open ./CMakeFiles/coreclrpal.dir/exception/remote-unwind.cpp.i and search for libunwind.h in it. In my case, it is |
|
I just checked inside and outside the homebrew sandbox. It works outside of it, but not inside. In the sandbox I get the following failure if I try and run |
|
@SMillerDev just delete the line that includes elf.h when generating the preprocessing file. Then the preprocessing should succeed and you should be able to see the path to the libunwind.h. |
|
Thanks, it's |
|
No, the check is based on whether the following compiles: |
What is this path relative too? I can't seem to find it. |
|
I have a file |
|
I am sorry, I've accidentally given you path for the runtime repo, not the coreclr one. The path you have found is correct. |
|
Right, the output file proves that the cmake check has found a libunwind.h that contained definitions for #include <libunwind.h>
int main(int argc, char **argv) {
unw_addr_space_t as;
unw_get_accessors(as);
return 0;
}This should fail to compile with the default macos libunwind. The log shows the following command line being used to compile the file: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -D_FILE_OFFSET_BITS=64 -DHAVE_UNW_GET_ACCESSORS -c -Werror=implicit-function-declaration -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -o CMakeFiles/cmTC_b34a8.dir/src.c.o -c /tmp/dotnet-20200914-75099-1je1col/artifacts/src/coreclr.f897710bc4efe6a046068fde0acf641667a8fff5/bin/obj/OSX.x64.Release/CMakeFiles/CMakeTmp/src.cYou can try to run it manually by creating the source file with the above mentioned context anywhere, naming it e.g. test.c and then running /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -D_FILE_OFFSET_BITS=64 -DHAVE_UNW_GET_ACCESSORS -c -Werror=implicit-function-declaration -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -o test.c.o -c test.cIt should fail with: |
|
When I do that it fails as expected. Any way I can run this in a cmake context somehow to figure out if that's the problem? |
|
You could try to let the compiler at the check in cmake dump more details using additional clang command line option. This will dump the whole include tree the compiler has used into the CMakeOutput.log |
|
I did that and assumed I needed to run these commands again but nothing seems to have changed. |
|
No, you need to delete the whole bin/obj folder and run regular coreclr build. I am sorry for forgetting to mention that. |
|
Here's the |
|
This is really strange. It includes the correct grep --context=7 -e unw_get_accessors /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/libunwind.hOn my machine, it shows just /*
* traditional libuwind "remote" API
* NOT IMPLEMENTED on Mac OS X
*
* extern int unw_init_remote(unw_cursor_t*, unw_addr_space_t, thread_t*);
* extern unw_accessors_t unw_get_accessors(unw_addr_space_t);
* extern unw_addr_space_t unw_create_addr_space(unw_accessors_t, int);
* extern void unw_flush_cache(unw_addr_space_t, unw_word_t, unw_word_t);
* extern int unw_set_caching_policy(unw_addr_space_t, unw_caching_policy_t);
* extern void _U_dyn_register(unw_dyn_info_t*);
* extern void _U_dyn_cancel(unw_dyn_info_t*);
*/ |
|
Yeah, that shows the same thing for me. |
|
Thanks for the time you've invested in this, @SMillerDev and @janvorli. Anything I can do to help progress this issue? |
|
@asbjornu is there an easy way how I can try to repro the issue locally? I would like to check whether is it a problem specific to certain configurations or whether it is a general problem that occurs even on my local device. I don't know much about the homebrew. |
|
If you have a macOS device, you'd need to:
That will allow you to drop into a shell and look around in the build directorty after a build fails (that's how I created most output). EDIT: if you don't have a macOS device it might also work on linux but that's not what the formula is written to support. |
|
Thank you @SMillerDev, I have a mac mini that I use for local development, so I can test it on it. |
|
I confirm that I hit the same issue when building on my device. However, I don't hit it if I just check out and build the source-build repo manually. Does brew itself introduce any environment variables that would change compiler settings? |
|
It mostly just removes a lot of them. If there is any specific ones you're wondering about maybe @MikeMcQuaid can help. |
|
It avoids picking things up from inside Homebrew that haven't been specified. As mentioned: it changes a lot of things, too many to spell out in particular. We can do whatever we can to help debug these, though, and point towards logging. |
|
It would be helpful to dump all the env vars at the time the build.sh is called so that I can try to see what could possibly interfere. Is it something that I can somehow do easily? |
|
binlogs keep track of all the env vars at the time of the build, and shows them up at the top in the binlog viewer. Source-build infra has a binlog, and we generate them for each repo we build. Try |
|
Similarly if you build with |
|
Additionally if you drop into the shell after |
|
So, I've debugged it a bit and found that for some reason, the compilation of the test code during cmake configuration succeeds even if I put a call to a fake function there. For example, this still successfully compiles: #include <libunwind.h>
int main(int argc, char **argv) {
unw_addr_space_t as;
unw_get_accessors(as);
foofoofoo();
return 0;
}Since the C compiler was invoked with I've tried to change the |
|
So, I've found a bug in configure.cmake, the following should not include the set(CMAKE_REQUIRED_FLAGS "-c -Werror=implicit-function-declaration")Removing the |
|
@asbjornu Is there a way to patch this in the homebrew recipe or will you need to wait for the fix in the coreclr repo? |
|
I think build.sh downloads that repo, so I doubt it would be possible to patch it. |
|
Yes, we will just have to wait for a fix. |
Can you place a file in a repo after cloning it? If so, you can place a file at |
Yep, I poked at this a bit with an earlier macOS-specific issue at #1685 (comment):
|
|
That said, if someone would like to contribute a patch file into dotnet/source-build |
The clang script that's included with homebrew gets confused with the -c flag and returns a wrong result for some configure tests. The -c flag is not needed for this check. See dotnet/source-build#1744 (comment) and dotnet/source-build#1744 (comment) for more details.
See: dotnet#1744 This is a backport of the fix that was merged into runtime for master: dotnet/runtime#42756
See: #1744 This is a backport of the fix that was merged into runtime for master: dotnet/runtime#42756
|
Fixed with #1789 for release/3.1. Fix is already merged in runtime master and release/5.0 |
In Homebrew/homebrew-core#60929 I've got
dotnetto build for macOS 10.13 and 10.14, but on 10.15 the build fails with the following error:The end result reports something completely unrelated, but I suspect it's the missing
elf.hfile causing problem and not this:Here's the
coreclr.logfile for inspection.I don't have any good ideas how to resolve this. Since Homebrew's
libelfformula does not seem to bundleelf.h, taking a dependency onlibelfwon't help. There's also no easy way to make dependencies conditional on the macOS version afaik.As suggested in the same SO thread, there's a possibility to source
elf.hfrom Apple's dtrace, but even better would be ifelf.hwas provided out of the box fromsource-builditself somehow.The text was updated successfully, but these errors were encountered: