User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 Build Identifier: Mozilla/5.0 (X11; U; AIX... rv: 1.7 The Java plugin in Java 1.3.1 has in AIX a dependency on the xpcom symbol __vft16nsQueryInterface15nsCOMPtr_helper. This symbol does not exist in Mozilla 1.7 anymore because class nsQueryInterface is no longer a nsCOMPtr_helper class (see bug 234725). Without the symbol, the Java plugin does not load. Reproducible: Always Steps to Reproduce:
this is all mine
Ok, so I tested around a bit why we havn't ran into this before, and why we're not running into this on a wider scale. It appears that the bug is actually not in the mozilla codebase. Apparently the Javaplugin should statically link against the xpcom-glue library, which will contain the implementation of that symbol. If that was done the binary should be able to run on both 1.4 and 1.7 mozillas. I've tested this with the sample application and it works fine. So I suspect that if you change the way the javaplugin is built so that it statically links against the gluecode it will work fine without any codechanges needed. Please let me know if this works, or if this is not an acceptable solution for one reason or the other.
Why is it necessary to link libxpcomglue.a statically with the Java plugin? Since Java is proprietary code it is not always acceptable to statically link with open source libraries.
bsmedberg, please see previous comment. If you can't link statically for legal reasons then maybe one solution could be to dynamically link to that library and ship with it. However if more people started doing that i suspect that we'd get problems with different versions... Of course a better solution would be to change the license of that library so that it can be linked to. Like some of the libraries from gcc (iirc) does.
I'm no lawyer, but as far as I know there are no legal issues for any code to link against MPL code. The MPL is a source-level license, and is not viral.
Jonas: Is there any possibility we could restore compatibility with the Java 1.3.1 plugin without bringing in a lot of overhead? If we need to #ifdef AIX the relevant sections, I'm ok with that. It seems like Bug 234725 promised no changes in binary compatibility (see comment 10), however this does look like exactly that. What other alternatives to changing the IBM build process for the Java plugin do we have?
Can the Java plugin be modified to not use do_QueryInterface? Can it just use QueryInterface directly? Or is it the case that rev'ing the Java plugin at all is not an option?
More to the point: A plugin or any extension that wants forward binary compatibility must either 1) link to the static glue library or 2) not use the glue library. The glue library is designed to make using xpcom easier, and it is also designed to be statically linked into plugins and extensions. If that is not an option, then it should not be used. Hence, my previous comment about using QueryInterface directly. Also, I'm sure that using do_QueryInterface pulls some inline code into the plugin, and while I'm not a lawyer by an means, it seems like inline code is not much different than statically linked code. Both cases result in the plugin carrying MPL code.
There are no legal issues with statically linking to MPLed code. The MPL is a file-level copyleft; so it would not affect any of the files which make up the source code of the Java plugin. Of course, the organisation shipping the Java plugin would need to follow the terms of the MPL with respect to the glue code. Gerv
> There are no legal issues with statically linking to MPLed code. I wrote that late at night; it's obviously a bit misleading. Rephrase: "There are no legal issues of the sort you are concerned about with statically linking to MPLed code." GErv
Sorry for jumping into this so late, but Ralf was asking about this. This might be totally irrelevant, but the OS/2 team added a "legacy" file to xpcom/build that "sort of" contains this function and the glueiness I think to make this work. Is that a better solution?
We have come up with a solution with the Java plugin team here at IBM which I think should work ok. We have removed all dependencies on the XPCOM glue library (with Darin's help), and we now have a plugin which does not require this symbol and just uses XPCOM frozen functions directly. The plugin has not been released yet, but it should be available soon. I will update this bug with the details on downloading the updated version of the plugin when it is available. For now, users can use the Java 1.4.1 or 1.4.2 plugins for AIX, which do not require this symbol from the XPCOM glue library, or they can continue to use the Java 1.3.1 plugin with earlier versions of Mozilla.
Darin, can you document in a public document for other implementors what kind of change is typically needed to remove the dependance on the XPCOM glue library ? Or just give a pointer if it's all already available publicly, I think it's all a matter of switching from the easy do_CreateInstance way to the hard QueryInterface method, but I'm still busy making sure what happens exactly in the various doc.
Yeah, I plan to write up such a document at some point. Basically, you need to not use nsCOMPtr, and that means that you need to not use do_QueryInterface, do_CreateInstance, etc. There are other things like the nsMemory:: methods that you would also need to avoid. There are alternatives for all of these things. A document would be good to show how to do it both ways (i.e., with and without the xpcom glue).
(In reply to comment #14) > Yeah, I plan to write up such a document at some point. Basically, you need to > not use nsCOMPtr, and that means that you need to not use do_QueryInterface, > do_CreateInstance, etc. what about CallQueryInterface, CallCreateInstance etc?
Those functions appear to be defined inline. I suspect they are ok to use, but in general you probably want to verify that your DLL only depends on frozen symbols from xpcom.