Custom self-extracting installer doesn't find the JRE on Windows [message #1745970] |
Thu, 20 October 2016 03:29 |
|
I have a JDK 1.7, a JRE 1.7 (different micro versions), and a couple of different JDK 1.8 installations on a Windows 10 64-bit VM in Parallels on Mac (hopefully that isn't a factor, ugh).
I am attempting to assemble a working self-extracting installer for Papyrus-RT, following the instructions for extracting the installer bits on the wiki and using the extractor binary at
/opt/public/tools/oomph/extractor-64.exe
on the Eclipse.org build server.
I am using this method, as it seems the Oomph releng itself does it, because attempting to extract the relevant bits from a previously built eclipse-inst-win64.exe results in a binary that isn't recognized by Windows as a valid executable.
But, my installer EXE doesn't launch properly when I try to test it. I get a sequence of error dialogs in which the first is:
Quote:Java Virtual Machine Launcher
Error: Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.7' is required.
I would have thought that 1.8 meets the requirement.
When I dismiss this dialog, I get another:
Quote:Java Virtual Machine Launcher
Error: could not find java.dll.
And then a third dialog after this one:
Quote:Java Virtual Machine Launcher
Error: Could not find Java SE Runtime Environment.
And then Edge browser opens up to the handy JRE/JDK download page hosted by Oomph with the VM argument "vm=1_1_7_0_64_0" which looks right to me, according to my installer descriptor file:
1
1
7
0
64
0
papyrus-rt-inst.exe
papyrus-rt-inst.ini
Papyrus-RT Installer
http://www.eclipse.org/papyrus-rt
https://wiki.eclipse.org/images/e/e3/PapyrusRT_Logo.jpg
Curiously, if I use the registry editor to hack my configuration to set a 1.7 JDK as the current version, then launching the installer gives me first a dialog saying that the current version is 1.7 but 1.8 is needed, and then the same dialog again claiming that the current version is 1.8 but 1.7 is needed. Odd, that.
Any ideas what the problem could be and how I might go about determining the cause and how to fix it? The latest eclipse-inst-win64.exe from the Eclipse download server works just fine on my system. And keep in mind that I know very little about the Windows environment.
Thanks,
Christian
|
|
|
|
Re: Custom self-extracting installer doesn't find the JRE on Windows [message #1746020 is a reply to message #1745980] |
Thu, 20 October 2016 14:38 |
|
Thanks, Ed!
With your tip (which I totally should have thought of myself, duh) I was able to determine that the problem was in my cat command, as you suspected. A path needed quoting. I was able to build a working installer on my Mac, and the Eclipse signing service no longer rejects the file as not a valid Windows executable, but I still have problems with that step:
Corrupt PE file - current signature not at end of file: /home/data/users/genie/signing/httpd/upload/phpv4RIrx
Failed
Error 500: Codesign tool(running on: build,459) exit status: 255.
Not your problem.
Thanks again for all of this amazing framework. I may have some more requests for customizability of branding coming, soon.
|
|
|
Re: Custom self-extracting installer doesn't find the JRE on Windows [message #1746043 is a reply to message #1746020] |
Thu, 20 October 2016 18:50 |
|
Ah! And my last problem with signing seems to have been caused by using the extractor.exe extracted from an Eclipse Installer build. I think that extracted extractor binary was already signed, so when I built my own installer binary by appending all of the other bits to it, that invalidated the existing signature.
Using the extractor binary from the /opt tree, together with my fixed concatenation script, works. I now have a self-extracting Papyrus-RT Installer for Windows.
Ed, maybe you'd like to update your wiki blurb about the extraction process with a note to the reader about not using the extractor.exe extracted from a signed installer binary?
|
|
|
Powered by
FUDForum. Page generated in 0.03588 seconds