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
extconf: add sdk helper, primarily for macOS #757
Conversation
macOS removed `/usr/include` in recent versions of macOS, which has broken the logic in this file and forced the usage of the internal libffi when macOS has a perfectly usable one itself. ``` checking for ffi.h... no checking for ffi.h in /usr/local/include,/usr/include/ffi... no ``` The internal libffi also seems to have some issues building on at least macOS 10.15/Catalina, and seemed to be the cause of my recent issues with other gems that depend on this one. ``` linking shared-object ffi_c.bundle ld: warning: ignoring file ext/ffi_c/libffi-x86_64-darwin19/.libs/libffi_convenience.a, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 ) ``` This change allows us to use the built-in libffi, and works fine: ``` checking for ffi.h... no checking for ffi.h in /usr/local/include,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/ffi... yes checking for ffi_call() in -lffi... yes checking for ffi_closure_alloc()... yes checking for shlwapi.h... no checking for rb_thread_call_without_gvl()... yes checking for ruby_native_thread_p()... yes checking for ruby_thread_has_gvl_p()... yes checking for ffi_prep_cif_var()... yes checking for ffi_raw_call()... yes checking for ffi_prep_raw_closure()... yes ```
macOS removed `/usr/include` in recent versions of macOS. This forces the usage of the internal libffi although macOS has a usable one itself. Related to ffi#757
@DomT4 Thank you very much for this PR! Unfortunately I don't have a Mac and have little to no knowledge about macOS. So any contributions are most welcome. I think the paths can be moved directly into the Also could you please have a look at the build error with builtin libffi? You can force it as described in the README. Both ways to install should work on common systems. |
#758 would work fine 👍. I mostly wrote it this way to avoid having to check redundant paths on older versions of macOS or different platforms, and because it's a little more verbose about why we're checking paths other than the standard ones; figured that could be handy in a year or two when Apple inevitably make some other kind of major change that force further changes here 🙃.
I'm not completely sure what/why is going on yet but it seems If I do a
there is no such error. I'm guessing that aforementioned "environment contamination" is Homebrew given any time I put For what it's worth the issue seems to persist both before and after 0b4e779. |
macOS removed `/usr/include` in recent versions of macOS. This forces the usage of the internal libffi although macOS has a usable one itself. Related to ffi#757
macOS removed `/usr/include` in recent versions of macOS. This forces the usage of the internal libffi although macOS has a usable one itself. Related to ffi#757
MacOS removed `/usr/include` in recent versions of macOS. That forced the usage of the internal libffi although macOS has a usable one itself. This commit adds typical paths of the SDK which contain libffi. Since it's possible to use non default SDK paths, there is another fallback to determine the path per "xcrun" command. Fixes ffi#757 Closes ffi#765 Closes ffi#758
macOS removed
/usr/include
in recent versions of macOS, which has broken the logic in this file and forced the usage of the internal libffi when macOS has a perfectly usable one itself.The internal libffi also seems to have some issues building on at least macOS 10.15/Catalina, and seemed to be the cause of my recent issues with other gems that depend on this one.
This change allows us to use the built-in libffi, and works fine: