Linux/ghidraRun: results in java.lang.ClassNotFoundException error

Describe the bug

Running the ./Ghidra/RuntimeScripts/Linux/ghidraRun script to launch Ghidra results in a java.lang.ClassNotFoundException error after a fresh build on Linux, following the instructions outlined in DevGuide.

To Reproduce Steps to reproduce the behavior:

1. Build Ghidra by following the steps in DevGuide.
2. Run the ./Ghidra/RuntimeScripts/Linux/ghidraRun script.
3. See error java.lang.ClassNotFoundException: LaunchSupport.

u@x1 ~/D/g/ghidra> ./Ghidra/RuntimeScripts/Linux/ghidraRun
Error: Could not find or load main class LaunchSupport
Caused by: java.lang.ClassNotFoundException: LaunchSupport
Error: Could not find or load main class LaunchSupport
Caused by: java.lang.ClassNotFoundException: LaunchSupport
Error: Could not find or load main class LaunchSupport
Caused by: java.lang.ClassNotFoundException: LaunchSupport

Failed to find a supported JDK.  Please refer to the Ghidra Installation Guide's Troubleshooting section.

Expected behavior

Running the Ghidra program without any issues.

Environment (please complete the following information):

• OS: Arch Linux

$ uname -a
Linux x1 5.0.5-arch1-1-ARCH #1 SMP PREEMPT Wed Mar 27 17:53:10 UTC 2019 x86_64 GNU/Linux

• Java Version: jdk-openjdk 11.0.3.u4-1

• Ghidra Version: 49c2010b63b56c8f20845f3970fedd95d003b1e9 (Ghidra_9.0.2_build)

Additional context

The issue seems to be either in the Ghidra/RuntimeScripts/Linux/support/launch.sh script or the output location of build artefacts. In particular, CPATH and LS_CPATH in the launch.sh script both point to bin/main subdirectories (e.g. ${INSTALL_DIR}/Ghidra/Framework/Utility/bin/main) that are not present after a fresh build of Ghidra.

Note, this is in the Development environment, so the INSTALL_DIR is the repository root of ghidra.

The bin directory is not present after a fresh build of Ghidra. However, the build directory is.

u@x1 ~/D/g/ghidra> ls Ghidra/Framework/Utility/bin/main
ls: cannot access 'Ghidra/Framework/Utility/bin/main': No such file or directory
u@x1 ~/D/g/ghidra> ls Ghidra/Framework/Utility
Module.manifest  build/  build.gradle  certification.manifest  src/

Replacing e.g. LS_CPATH as follows, makes the script go further, before receiving another java.lang.ClassNotFoundException error.

-       LS_CPATH="${INSTALL_DIR}/GhidraBuild/LaunchSupport/bin/main"
+       LS_CPATH="${INSTALL_DIR}/GhidraBuild/LaunchSupport/build/classes/java/main"

What is the proper solution to finding specifying the Java class after building Ghidra?

Cheers, Robin

[hedgeberg]

While working on trying to get around this exact problem, I went ahead and tried to mess with getting the bin folder to behave as though it were built with eclipse by symlinking. I only tested it for the Features/Utility sub-project, but I was able to rm -r bin/main and then ln -s build/classes/java/main bin/main, and I can load ghidra in dev mode using ghidraRun, and it launches just fine.

I need to do further testing to see if I can remove eclipse fully from the loop, but it seems like writing a script to traverse all the sub-project directories, and generating a symlink, should “just work ™️”.

It may be possible to even add a gradle method like gradle cmdLineDev which would do this as part of the setup process, and gets around the issue of needing to change all of the source files. If this is something worth adding to the project, I’ll look at figuring out gradle well enough to do this, and submit a pull request at some point.

[fmagin]

@hedgeberg I am currently trying to also setup a dev environment with IntelliJ and running into similar issues. Specifying -DbinaryPath=build/classes/java/main as a JVM argument works and allows Ghidra to find all the classes. It then crashes/fails because various files like the UserAgreement or images like ./Ghidra/Framework/Generic/bin/main/images/core.png are also expected in this location. Adding more paths to the binaryPath seems to work, i.e. -DbinaryPath=build/classes/java/main:build/resources/main/ allows the images to be found, but the tips are now missing. So I think if all the paths are added this would be enough and would in total just be one more VM argument in a launch configuration. This also seems cleaner then symlinking (which isn’t really supported on windows I think?)