373047 - Can't embed XULRunner built with MSVC 2005 using JavaXPCOM

Status: RESOLVED WONTFIX

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[jhp (no longer active)]

I cannot run the JavaXPCOM unit tests on a XULRunner built using MSVC 2005.  I keep getting manifest related errors.  Bug 249782 made it possible to build with MSVC 2005, but that doesn't seem to be enough for JavaXPCOM.

The first error I get is when calling |Mozilla.getIntance().initialize(...)| tries to load 'javaxpcomglue.dll'.  This is error R6034, which means that a manifest hasn't been properly set for this DLL.

So I added "EMBED_MANIFEST_AT = 2" to the Makefile, so the manifest would be merged with the DLL.  This gets me past the error with 'javaxpcomglue.dll'.

Now I get R6034 errors for the loading of each of the dependent libs (nspr4.dll, plc4.dll, ..., xul.dll).

Do we need to embed the manifest for every DLL, or is there a simple way to fix this?

Comment 1

[Benjamin Smedberg]

Ted, yet another variation on a theme.

Comment 2

[(not currently active) Ted Mielczarek]

Ok, we need to have a chat about this and figure out what the right solution is.  How does DevDay in Boston sound?  :)

Comment 3

[Benjamin Smedberg]

It was on my agenda... :-)

Comment 4

[jhp (no longer active)]

Well, unfortunately, I won't be able to make either of the DevDays.  So, out of curiosity, why can't we just embed the manifest for all DLLs (in addition to the EXEs)? 

Comment 5

[jhp (no longer active)]

So was anything discussed or resolved last weekend?

Comment 6

[(not currently active) Ted Mielczarek]

Javier: we have a plan of action, I just need to try it out.  We're planning on embedding a manifest in every DLL, including components, and also placing a Microsoft.VC80.CRT.manifest in the components directory, with the references pointing up one directory.  We believe this will work for the app scenario + the embedding scenario.  One caveat is that we decided that embeddors and extension authors creating binary components should not be relying on our CRT, but should either provide their own or statically link.

Comment 7

[(not currently active) Ted Mielczarek]

Now that bug 350616 has landed, this should work again.  I was able to run the JavaXPCOM tests with that patch applied, so you should be able to re-enable them on Win32.

Comment 8

[Simon Kissane]

This is still happening with Mozilla XULRunner 1.9.0.7 - 2009031309 running on Windows XPSP3:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\xulrunner-sdk\bin\javaxpcomglue.dll: Can't find dependent libraries
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674)
	at java.lang.Runtime.load0(Runtime.java:770)
	at java.lang.System.load(System.java:1005)
	at org.mozilla.xpcom.internal.JavaXPCOMMethods.registerJavaXPCOMMethods(JavaXPCOMMethods.java:57)
	at org.mozilla.xpcom.internal.MozillaImpl.initialize(MozillaImpl.java:48)
	at org.mozilla.xpcom.Mozilla.initialize(Mozilla.java:668)

However, the following is a workaround: set the PATH environment variable to the xulrunner install directory (in this case, "C:\xulrunner-sdk\bin") before you start Java. Then it works, since Windows by default searches all the directories in PATH for DLLs.

Comment 9

[Simon Kissane]

Another solution: once I get the GRE path from Mozilla.getGREPathWithProperties(), then I can use Java Native Access [JNA] to call the Win32 GetEnvironmentVariableW/SetEnvironmentVariableW APIs, to add the GRE path to the PATH env var. (Another option which also works is the SetDllDirectoryW API, but I feel more comfortable with PATH). Either way, the dependent libraries are loaded successfully.

Comment 10

[Benjamin Smedberg]

The glue *should* have loaded all the necessary DLLs before loading javaxpcomglue.dll, and it is not recommended to modify the PATH.

Please use process explorer in profiling mode to see exactly which DLLs are not being loaded correctly. (And be aware the JavaXPCOM appears to be an unmaintained project; you'll probably have to write any patches yourself.)

Comment 11

[Mike Hommey [:glandium]]

JavaXPCOM was removed in bug 648593.