Bug #3242
closeddlls should not go in c:/Windows/System32
0%
Description
In bug# 3233, I noticed that dlls were showing up in c:/Windows/System32.
Chad wrote:
cplibs.bat/sh is run by the installer. If it doesn't run, the libraries for
the gdal stuff don't work. I'm open to suggestions for making it work without
copying files to system32.
The bug or rfe here is that we should
It is not clear to me how ptmatlab.dll got over to c:/Windows/System32.
kepler/lib/cplib.sh contains:
--start--
#!/bin/sh
mkdir ~/lib
cp "$INSTALL_PATH"/lib/libproj.0.dylib ~/lib/
cp "$INSTALL_PATH"/lib/libgeos_c.1.dylib ~/lib/
cp "$INSTALL_PATH"/lib/libgeos.2.dylib ~/lib/
cp "$INSTALL_PATH"/lib/libgdal.1.dylib ~/lib/
cp "$INSTALL_PATH"/lib/libexpat.1.dylib ~/lib/
chmod +x "$INSTALL_PATH"/kepler.sh
chmod +x "$INSTALL_PATH"/kepler.app/Contents/MacOS/JavaApplicationStub
--end--
The ChangeLog says:
2008-01-26 10:34 higgins
- installer/build/install.xml: Updated the Izpack configuration
file to parse a Windows batch file to move dlls to a location where
they can be found by the OS (batch file name is 'cplibs.bat' - file
is set to be executed during installation)
2008-01-26 10:32 higgins
- lib/cplibs.bat: batch file to copy windows dlls to location where
they will be located
There is some email about c:/Windows/System32 from Dan Higgins at
http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/2007-November/005146.html
Related issues
Updated by Christopher Brooks about 16 years ago
The ant build failed for me under Windows:
BUILD FAILED
c:\tmp\cxh\src\kepler\build.xml:210: Failed to copy c:\tmp\cxh\src\kepler\lib\jri.dll to c:\WINDOWS\system32\jri.dll due to java.io.FileNotFoundException c:\WINDOWS\system32\jri.dll (Access is denied)
The problem is that I'm not administrator on this machine in part because Eclipse is poorly behaved if multiple users are administrator
and accessing a shared Eclipse installation.
A larger problem is that I consider it to be a bug to copy dlls to
c:\Windows\system32. Usually this results in instability because
multiple apps try to update files in this directory. A better
and safer installation is to put the dll in a directory and tweak the
user's path.
I'm changing this to a p2/major bug because the bug prevents new users
who are not administrator from compiling from sources. Feel free to downgrade
it.
Updated by Matt Jones about 16 years ago
I agree that its a problem putting dll's in system32, but we've had extremely poor success trying to keep them contained in a directory. Each version of Windows and MacOS seems to change just how shared libs are loaded, so we have yet to find an effective strategy. Eventually we just gave up and put them in system32. Thanks for the bug report -- it's a good one to fix. If you know of specific ways of fixing it that works across modern windows versions and MacOS X versions please let us know. Thanks.
Updated by Christopher Brooks about 16 years ago
I think the right solution is to add the proper directory to the user's path
upon startup. Ptolemy does this in $PTII/bin/vergil (which is a link
to ptinvoke, which is derived by configure from ptinvoke.in).
Using a launcher program is another approach, though setting the path in
an already executing program might not work.
At install time, another approach is to add a directory to the user's path.
Under Windows, this requires writing a little code to munge the registry.
iZpack might have this code in it somewhere.
OSGi and Webstart both have ways to manage native libraries.
I think the tricky part is getting ant to use the right path.
http://www.jguru.com/faq/view.jsp?EID=970296
suggests using <env>?
Use a nested <env> element to your <java fork="true" >
Note that it only works with fork="true" for obvious reasons.
The env elements are described in the documentation of the exec task.
Then env sub element is available in the java task since ant 1.5.
I don't do ant, so maybe an ant guru could take a look?
Updated by Chad Berkley over 15 years ago
Possibly look into this with the new installer.
Updated by Christopher Brooks over 15 years ago
I'm the reporter on this bug, I noticed it was assigned to Dan Higgins
so I'm reassigning it to Chad as he is working on the installer.
The acceptance test for this bug is to install under Windows with a
non-Administrator account.
Updated by Chad Berkley over 15 years ago
On windows XP, if the dlls are not in the System32 directory, I get the following error:
ptolemy.kernel.util.IllegalActionException: in .GARP_MultipleSpecies-V.manager
Because:
C:\project\kepler\common\lib\garp.dll: Can't find dependent libraries
at ptolemy.actor.Manager.execute(Manager.java:465)
at ptolemy.actor.Manager.run(Manager.java:1109)
at ptolemy.actor.Manager$3.run(Manager.java:1150)
Caused by: java.lang.UnsatisfiedLinkError: C:\project\kepler\common\lib\garp.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at org.ecoinformatics.seek.garp.GarpJniGlue.<clinit>(GarpJniGlue.java:72)
at org.ecoinformatics.seek.garp.GarpPresampleLayers.fire(GarpPresampleLayers.java:210)
at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:434)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:426)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:851)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:426)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:851)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.lib.hoc.LifeCycleManager._fireInsideModel(LifeCycleManager.java:334)
at ptolemy.actor.lib.hoc.LifeCycleManager._executeInsideModel(LifeCycleManager.java:289)
at ptolemy.actor.lib.hoc.RunCompositeActor.fire(RunCompositeActor.java:204)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:851)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:426)
at ptolemy.actor.Manager.iterate(Manager.java:707)
at ptolemy.actor.Manager.execute(Manager.java:349)
... 2 more
Caused by: java.lang.UnsatisfiedLinkError: C:\project\kepler\common\lib\garp.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:993)
at org.ecoinformatics.seek.garp.GarpJniGlue.<clinit>(GarpJniGlue.java:72)
at org.ecoinformatics.seek.garp.GarpPresampleLayers.fire(GarpPresampleLayers.java:210)
at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:434)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:426)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:851)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:426)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:851)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.lib.hoc.LifeCycleManager._fireInsideModel(LifeCycleManager.java:334)
at ptolemy.actor.lib.hoc.LifeCycleManager._executeInsideModel(LifeCycleManager.java:289)
at ptolemy.actor.lib.hoc.RunCompositeActor.fire(RunCompositeActor.java:204)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:851)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:188)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:426)
at ptolemy.actor.Manager.iterate(Manager.java:707)
at ptolemy.actor.Manager.execute(Manager.java:349)
at ptolemy.actor.Manager.run(Manager.java:1109)
at ptolemy.actor.Manager$3.run(Manager.java:1150)
Currently testing on Vista to see if I get the same error. If I don't, I'll change the installer to copy the dlls to system32 for XP, but not for vista.
The error appears to be coming from a secondary resolution of dependent dlls. The original dll (garp.dll) is found on the java.library.path, but when it references other dlls, they are not found, even though they are in the same location.
Updated by Chad Berkley over 15 years ago
After re-reading the jguru thread that christopher posted, I added common/lib to the PATH in windows and now there is no need to copy the dlls to system32. now need to figure out how to make kepler do that automatically.
Updated by Chad Berkley over 15 years ago
Fixed this by allowing the bootstrapper to modify the PATH env variable at runtime. While the java.library.path variable allows the JVM to find the initial dll provided by the JNI wrapper, it does not allow dependent libraries to be found. For this, the directory needs to be in the PATH. The bootstrapper now addes all of the directories in java.library.path to the PATH at runtime so that all libraries will be found.