On Tue, 23 Mar 2010, Bill Janssen wrote:
Andi Vajda <va...@apache.org> wrote:- the --find-jvm-dll trick is in jcc/windows.py and is not a JCC build option but a JCC run option. In other words, if you want the feature for your extension, when it starts, invoke jcc with, among many other things, --find-jvm-dll when you build your extension. This feature only works with shared mode, currently.Off the top of my head, I don't see this. --find-jvm-dll with shared mode is a JCC thing, not a per-extension thing. You don't want different extensions trying to use different JVMs -- they're all trying to use the same JCC DLL.
And they will, that's what the jcc.dll Path hack in __init__.py for windows is for. The path to jcc.dll has to be set this way since no one is going to be adding the guts of their jcc egg installation to their path (and understandably so).
On the other hand, the path to jvm.dll hack is an attempt at working around windows DLL hell and is never going to work reliably. For example, on my system, for whatever reason, the registry reports jvm.dll to be on the C: drive but in fact it's not. It's on the O: drive. Go figure.
That's why I made it a JCC option, which could be enabled/disabled via the config.py file. (That is, you could build it shared with or without auto-find, but if you decided you wanted it the other way, you could simply edit config.py to change it.)
If you build your extension with --find-jvm-dll, code to hack the Path on windows is inserted into your extension's __init__.py file. Otherwise, the code doesn't exist in your extension. That code is run when your extension is first imported.
That code can only be effective if it is run before the very first time the _jcc extension is loaded (which loads jcc.dll and jvm.dll into your process). All other extensions will be run with the jcc.dll/jvm.dll pair that the first extension caused to be loaded into the process. In other words, no matter what, all extensions loaded into a given process run with the same jcc.dll and jvm.dll allways, regardless of Path hacks.
The way extensions are distributed on Windows makes it even worse. Building an extension with --wininst (or any other way) does not package it with the JCC it was compiled with. And nothing in the package name tells you whether it was shared or non-shared.
If you run an extension in shared mode with a different version of jcc than it was compiled against, you'll have crashes and other troubles. You must distribute jcc along with your extension in shared mode. It should be made a dependency, especially on Windows where 'jcc' is explicitely imported to effect the Path hack for finding jcc.dll. On non-windows, only the jcc.so/dylib is needed and is found via -rpath or LD_LIBRARYPATH so no egg dependency is required.
In non-shared mode, the jcc runtime necessary to run your extension is included in the extension distribution.
Andi..
