Created attachment 152117 [details] Patch that fixes minecraft-runtime errors. This is almost an exact duplicate of #189316, only I've included a patch that actually fixes this. "jre" should not be in the path (it isn't in the minecraft-client path, either, which /does/ work). I also fixed it so that it can use a different JAVA_HOME, if necessary, just as minecraft-client will. I additionally don't know why this port has 1.8+ for JAVA_VERSION, as 1.7 works quite well on my laptop, but this patch doesn't change it back as I'm sure there was some reason for that bump.
There was a reason for the bump to 1.8. I don't recall offhand what it was, I think it was some runtime issue, but the requirement for 1.8 was challenged and passed. Let's assume it's correct. There's no maintainer for the port. I'm going to promote the PR to patch-ready status.
> export JAVA_HOME=JAVA_HOME Are you sure it is correct?
(In reply to Dmitry Marakasov from comment #2) Yes, I am sure. See the additional sed call in the Makefile that I added. This is how minecraft-client is set up so I just did the same thing for minecraft-runtime. There may be a cleaner way set up both scripts, but I was just following the convention of the port.
Common way is to use JAVA_HOME=%%JAVA_HOME%%, and just replace what's between %% %%. That way it's apparent that the thing is replaced.
I have just realised an impossibility while testing a new patch using the %%VAR%% syntax... The port specifies JAVA_VERSION=1.8+, but it depends on games/lwjgl. lwjgl has a JAVA_VERSION=1.7, and when I tried to make it 1.7+, it failed building with openjdk8. That means it only works with 1.7. How can this port possibly run on 1.8 when its dependency won't even build with it? I can't find any reason that the version was bumped, either, as Minecraft runs perfectly fine on my older machine using openjdk6... so 7 should be quite fine and in fact works properly here for all MC versions tested - I tested launchng 1.6.4 single player, 1.7.10 single and multiplayer, 1.8.1 single and multiplayer, and 1.8.2-pre4 single and multiplayer. Output for each: System.getProperty('os.name') == 'FreeBSD' System.getProperty('os.version') == '11.0-CURRENT' System.getProperty('os.arch') == 'amd64' System.getProperty('java.version') == '1.7.0_71' System.getProperty('java.vendor') == 'Oracle Corporation' System.getProperty('sun.arch.data.model') == '64' Note Java version 1.7.0_71. If you really think it necessary, I will try and patch lwjgl to build on openjdk8, but this minecraft-client 1.8 requirement seems arbitrary to me.
> I can't find any reason that the version was bumped, either, as Minecraft runs perfectly fine on my older machine using openjdk6... See the port history and PR 189028. Some patch was added later, so maybe it's no longer an issue, should be checked. Sean, could you please recheck that this still needs openjdk8? Regardless, games/lwjgl should definitely be fixed with openjdk8.
Created attachment 152401 [details] New patch to fix port Indeed, it should no longer be an issue and I have tested on three computers. This port works quite fine with openjdk7. I'll file a separate PR on the lwjgl issue once I have more details about it. I haven't thoroughly looked at it yet. Enclosed is a patch containing what I hope to be the final update. It bumps PORTREVISION and uses %%FOO%% syntax. I have tested this on all three of my computers as well, and found no issues with it.
Looks good to me. Let's wait a bit for sbruno@ feedback.
(In reply to Andrew Wilcox from comment #7) The bulk of the work for the last update actually derived itself from PC-BSD. I believe the 1.8 requirement came from the add on component that is run the first time the code is executed that "fixes" things for FreeBSD. The patch/update will modify your .minecraft directory (if you haven't already discovered that). If you didn't move your .minecraft directory or remove it during your tests of older java run times, then you were still using an older version lwlgl ... I think. If you did wipe out your .minecraft directory and everything was fine, then I have no objections. :-)
If I understand bruno correctly, then this line "JAVA_VERSION= 1.7+" is wrong, and thus we need the patch to be updated to not change that line. Right?
Unless somebody states otherwise, I'm assuming this is still in work and the "patch-ready" status should be revoked. There's an open question on the USE_JAVA line that has not been answered.
Revoked "patch ready" status.
Is this still an issue for you Andrew?