platform: support macOS and newer CPython #4
Conversation
Fix util/configure_jep_native_libraries.py to use importlib.metadata and pkg_resources if available before falling back to the old sys.path search. Also add a fallback in case (lib)jep.* can't be found, trying again by interposing the implementation cache tag. Native libraries on macOS have been known to use this filename format (e.g.: jep.cpython-310-darwin.so). Fix GhidrathonInterpreter to search for jep.so as well.
|
In general though, it would be better if the build process didn't pollute my global Python environment, so it's probably worth making sure that part is run in a virtualenv, or something. Also, instead of cherry-picking files from the Jep site-packages directory, why not copy it over wholesale under the arch-specific Ghidra directory and add it to the Python interpreter path? |
There was a problem hiding this comment.
@shizmob this is great work! Very excited about adding MacOS to the list of supported operating systems. I've left one small comment for your review.
| # Get Ghidra names | ||
| ghidra_lib_path = Path(GHIDRA_JAVA_LIB_PATH) | ||
| if sys.platform in GHIDRA_OS_LIB_NAMES: | ||
| ghidra_os_lib_path = Path(GHIDRA_OS_LIB_PATH) / (GHIDRA_OS_LIB_NAMES[sys.platform] + os.uname().machine) |
There was a problem hiding this comment.
os.uname does not work on Windows - Ghidra only supports 64-bit so we can be confident using hard-coded paths for the os directory e.g. win_x86_64. We could include the hard-coded paths for each supported OS in GHIDRA_OS_LIB_NAMES.
There was a problem hiding this comment.
Well noticed, thanks! I'll look for another way, but I don't think we can include the hard-coded directories as e.g. macOS and Linux support multiple different 64-bit architectures. It seemsplatform.machine() with a mapping may do the trick, though.
There was a problem hiding this comment.
True but Ghidra only supports a subset of those architectures: https://github.com/NationalSecurityAgency/ghidra/blob/c51183f1a262c80d45aac48d4f3343c67b6bd41a/GPL/nativePlatforms.gradle#L21-L28. We just need to make sure that the Jep native binaries are copied to the appropriate os directory where Ghidra knows to look e.g. win_x86_x64.
Thank you for the feedback! We haven't found a straightforward way to run Jep with Ghidra that doesn't require including the targeted Jep Java and native binaries in specific folders of the extension directory. We could copy everything over but I'm not sure what that gains us - we would still need to cherry-pick the Jep Java binary over to the extension's |
|
MacOS support would be nice. I did try out @shizmob's PR but wasn't able to get it working, even with some of the mentioned fixes in this thread. I'm currently on an M1 Pro (OSX v13.0.1). Interestingly, I did manage to get Ghidrathon working, but i had to manually finagle some of the library names. i used |
|
Thank you for your contribution - this has been superseded by 32f3969. |
This PR fixes
util/configure_jep_native_libraries.pyto use theimportlib.metadataandpkg_resourcesmodules if available, before falling back to the oldsys.pathsearch. It also adds a fallback in case(lib)jep.*can't be found, trying again and interposing the implementation cache tag. Native libraries on macOS have been known to use this filename format (e.g.:jep.cpython-310-darwin.so). It then changes GhidrathonInterpreter to search forjep.soas well.With this, I was able to get Ghidrathon to work under macOS with
gradle -PGHIDRA_INSTALL_DIR=/usr/local/Caskroom/ghidra/10.1.4-20220519/ghidra_10.1.4_PUBLIC -PPYTHON_BIN=python3 buildExtension.