Bug 205211

Description Jason M. Fox 2007-10-02 13:13:00 EDT

Build ID: I20070621-1340

Steps To Reproduce:
1. Create a simple IApplication that attempts to load a shared library that exists in the jre:

public class LoadSharedLibrary implements IApplication {
	public Object start(IApplicationContext context) throws Exception {
		try {
			System.loadLibrary("awt");
		} catch (Throwable t) {
			System.err.println("Error loading library 'awt': " + t);
		}
		return null;
	}
	public void stop() { }
}

2. Use the 'org.eclipse.core.runtime.applications' extension point to register the IApplication.

3. Use the 'org.eclipse.core.runtime.products' extension point to register it as a product.

4. Create a Product Configuration for the product.

5. Use the 'Eclipse Product export wizard' to package and export the product to the Linux (gtk/x86) platform.

6. Add the directory with your deployed executable to your PATH.

7. Ensure that the java's 'lib/i386' directory is _not_ on the LD_LIBRARY_PATH.

8. Goto a directory that does not contain the deployed executable (e.g. your home directory).

9. Execute the deployed product using the fully qualified path to the executable (e.g., /home/foo/path/to/executable/runme).  Running in this manner should not produce an error message.
 
10. Execute the deployed product using just the executable name (e.g., runme).  Running in this manner producing an error message about not being able to load the shared library.

More information:
While the above steps do include a "workaround" (step 9, running using the fully qualified path), this is not entirely desirable for all environments.

Another workaround is to have the LD_LIBRARY_PATH include the jre's 'lib/i386' directory.  But this is also not desirable for all environments.

Why is there a difference in loading shared libraries depending upon the execution method?