Bug #3074
closedCode library installation issues
0%
Description
There are several issues with compiled code libraries (*.dll, *.so, *.dylib files) and where they must be located. This is particularly true with 'secondary' libraries i.e. compiled code called by other compiled code (e.g. the GARP and gdal code calls other C libraries). Such libraries need to be installed in specific locations or environment variables need to be set so that they can be located at run time. These locations are also platform specific.
Preferably, such code libraries should be included in kar files with the actors that use them and copied to a place where they are usable when the kar is installed at startup. Note that installation in some locations may require special access privileges that not all users may have. e.g. adding dlls to the windows32 directory is reportedly not allowed under Windows Vista
Related issues
Updated by Chad Berkley over 16 years ago
postponing this development until after 1.0. We just don't have the time to get this done. This will be something kepler/core can look at as well.
Updated by Chad Berkley over 15 years ago
Not sure if this is something we want to get done for 2.0, but I'm targeting it there for further discussion.
Updated by Chad Berkley over 15 years ago
Kepler no longer relies upon installation of dlls into system32. the path variable is changed at runtime and the dlls are included in the path.
Updated by Chad Berkley over 15 years ago
libraries can now be stored in the lib directory of any module. This should allow individual modules to be able to load the libs they need. Any dll, so, dylib, etc will be placed on the java.library.path as well as in the path (on windows) at runtime.
The feature mentioned before about putting libs in kar files is still not supported. I am going to open a new bug for that and target it to post-2.0.