On 5/14/19 7:48 PM, Jeremy O'Brien wrote:
On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote:
Jeremy O'Brien writes:
I noticed this port was committed today. I have to
ask, did you actually try to use it? In its current
state, (sans my above changes), there is no decompiler
nor symbol demangler. This might have been OK to omit,
except for the fact that you will get a "Could not
find decompiler executable decompile" popup every
single time you click anywhere in the disassembly pane,
which makes this port unusable.
Indeed they are very annoying. I agree the port is not
"finished." But I've used Ghidra to do some minor work despite that, so
I'm happy to see it in. Revising the port to add the native tools would
be very welcome though.
If you're willing to compile it yourself, my MR here:
https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the native components
build perfectly in OpenBSD. Just follow the ghidra DevGuide.md instructions after
applying the patch. I also have my personal build here (but that of course requires that
you trust a stranger on the internet):
https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip if you don't feel
like compiling but want the "full" ghidra experience. I do like that the
current ghidra port requires no compilation, as the compilation process is a bit
heavy-handed and takes some time to complete, but I personally would prefer to see a
fully-working port over a fast-installing one.
Thank you for feedback, I will try your patch to build ghidra and I will
let you know.
If you are motivated, you can send a diff that applies on the ghidra
port to integrate your work.
Cheers,
Remi.
