These scripts are based on InstallApp-NT.bat.in and UninstallApp-NT.bat.in from
WRAPPERSRC/src/bin of version 3.5.9 of the wrapper.
Tested in XP and Win7.
This is based on WRAPPERSRC/src/bin/StartApp-NT.bat.in from 3.5.9 of the
wrapper. The i2prouter.bat that we ship doesn't work; this one does. Tested in
XP and Win7.
The default service path in Windows is fugly and not very convenient. I2P uses
the correct path, but if you want to access snark or eepsite data, one must go to
%SYSTEMROOT%\config\systemprofile\AppData\Roaming\I2P\ (Vista/7) or
%SYSTEMROOT%\system32\config\systemprofile\Application Data\I2P (XP/2003). If
this wasn't bad enough, in some cases one must take ownership of this path and
grant permission to him- or herself to access the folder.
With this changeset, I'm setting the path to %ALLUSERSPROFILE%\Application
Data\I2P as well as adding a shortcut to the I2P folder in the Start menu.
on localized versions of Windows.
----
Non-English versions of Windows do not have a Users group; instead they use a
localized group name. As a result, when installing I2P on a non-English Windows
box, the installer will show an error when trying to run the fixperms.bat
script.
Using the SID will work with any localized Windows. SID list @
http://support.microsoft.com/kb/243330/en-us
Add an icon (in OSX parlance, a 'bundle') to the installation folder to start
I2P.
While there might be a better way to handle this (admittedly, I don't know OSX
that well), it is my belief that this way is less 'hackish' than the various
OSX 'installers' that I've seen floating around.
My rationale for this:
1) in case someone is installing I2P on top of an already existing installation
this will cause I2P to be shutdown
2) no hangs during the installation if i2p is already installed as a service
3) in case the NT service settings are changed in wrapper.config by us, this
will force the service settings to be updated.
4) versions of I2P < 0.8.7 did not remove the service when uninstalling. If someone
removed I2P in the past and reinstalls I2P--opting to run as a service--the
installation process will hang.
jbigi and wrapper files for arm.
Compiled on trimslice with gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
Log postinstall errors to postinstall.log.
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-0ubuntu2.1)
OpenJDK Zero VM (build 14.0-b16, mixed mode)
GMP 4.3.2 (half the size of 5.0.2, and no speed difference) LGPLv3
Wrapper 3.5.9 GPLv2
All binaries stripped.
As on the Android emulator, the stock BigInteger.modPow()
has some serious bug on arm.
Without the libjbigi checked in here, the JVM crashes almost immediately.
working directory set to $INSTALL_DIR, C:\Program Files\I2P is not removed in
XP.
...but even with the working directory removed, the the Uninstaller folder is left
within $INSTALL_DIR in Windows 7.
for use with a 32 bit JRE.
Rationale:
On an x64 system using a 32 bit jvm Without the 32 bit libwrapper, messages
like this will be shown in wrapper.log with the wrapper in MTN & I2P >= 0.8.7:
-----------------------
Launching a JVM...
WrapperManager: Initializing...
WrapperManager:
WrapperManager: WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
WrapperManager: The file is located on the path at the following location but
WrapperManager: could not be loaded:
WrapperManager: $I2P/lib/libwrapper.so
WrapperManager: Please verify that the file is both readable and executable by the
WrapperManager: current user and that the file has not been corrupted in any way.
WrapperManager: One common cause of this problem is running a 32-bit version
WrapperManager: of the Wrapper with a 64-bit version of Java, or vica versa.
WrapperManager: This is a 32-bit JVM.
WrapperManager: Reported cause:
WrapperManager: $I2P/lib/libwrapper.so: $I2P/lib/libwrapper.so:
wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
WrapperManager: System signals will not be handled correctly.
-----------------------
With libwrapper.so removed, one sees the following:
WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the
WrapperManager: following files:
WrapperManager: libwrapper-linux-x86-32.so
WrapperManager: libwrapper.so
WrapperManager: could be located on the following java.library.path:
WrapperManager: $I2P
WrapperManager: $I2P/lib
WrapperManager: Please see the documentation for the wrapper.java.library.path
WrapperManager: configuration property.
WrapperManager: System signals will not be handled correctly.
-----------------------
The 32 bit lib names, when installed on an x64 system, will match the alternate
names that the wrapper looks for.
- removing from /build.xml
- moving recent changes from installer/resources/postinstall.bat to installer/install.xml
- dropping installer/resources/postinstall.bat
The aging v3.1.x of the java wrapper is being replaced in this
checkin with the latest (current) stable release, 3.5.9.
There is now only one copy of wrapper.jar, located in wrapper/all.
The build.xml scripts have been changed to reflect this new path.
All binaries--with the exception of solaris (I don't have
SPARC hardware)--have been stripped.
FreeBSD x64 is being included in this release.
I have only included the x86 macosx wrapper due to not having a
system to test the x64 code on. On the plus side, the wrapper is
universal (a FAT powerpc & Intel Mac) binary. No more prompting
to install Rosetta!
In some distributions (such as Debian, for example) net.ipv6.bindv6only=1 is
set by default. In some configurations, networking in java applications will be
broken. Someone recently came into #i2p experiencing this very problem.
This change closes#464.
Braces were put around variable names so that router will run in kFreeBSD.
runplain.sh should now be shell agnostic (it runs in dash. it even runs in
*posh*, a ridiculously picky shell).
