The VASSAL Team is happy to announce the release of VASSAL 3.3.0-beta1.
[size=150]IMPORTANT[/size]
This is a beta release. Things may be broken which worked in 3.2.17. If you find a bug introduced since 3.2.17, please report it.
If you save a module, game, or log in VASSAL 3.3, you will NOT be able to open it afterwards with VASSAL 3.2. We recommend keeping a backup copy of any pre-3.3 files you plan to modify in 3.3 until you’ve verified that everything works to your satisfaction.
Some modules containing custom drawing code may render incorrectly on HiDPI displays. If you are the maintainer of such a module, let us know and we can advise you about what needs updating for 3.3 in your code. (We are aware already that VASL has this problem and are working with its maintainers to update it.)
12557: Compatibility with Java 9+: VASSAL 3.2 would not run with anything newer than Java 8. VASSAL 3.3 now requires Java 9 or later.
12558: Bundle Java with VASSAL: The Linux, Mac, and Windows packages now include Java 13. It is no longer necessary to install Java separately when using one of these packages.
12559: HiDPI support: VASSAL now has support for displays with a high pixel density (e.g., Retina displays). On such displays, you should now see correctly sized interface elements and sharper image rendering.
Bug fixes:
12556: Mass Piece Definer does not sort image names
For changes prior to 3.3.0-beta1, see the change log.
Please report all bugs in 3.3.0-beta1 even if they are bugs which you’ve already reported against other versions. We take your bug reports seriously—they’re the reason we’ve been able to fix so many bugs.
[size=150]Minimum Requirements[/size]
VASSAL 3.3 requires Java 9 or later.
[size=159]Help us test[/size]
Should you find any problems/oddities/bugs, please tell us so that we can
fix them for a future release of VASSAL.
./VASSAL.sh
Error: dl failure on line 603
Error: failed /data/Personal/Games/VASSAL/VASSAL-3.3.0-beta1/jre/lib/server/libjvm.so, because /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /data/Personal/Games/VASSAL/VASSAL-3.3.0-beta1/jre/lib/server/libjvm.so)
Version of libc6
dpkg -l libc6:amd64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=============================-===================-===================-=========================
ii libc6:amd64 2.27-3ubuntu1 amd64 GNU C Library: Shared libraries
Will just wait for version 2.29 then. Thank you for the work done.
The problem here is that the bundled version of Java was linked against a newer glibc than Debian 10 has. That’s aggravating, as it means there’s probably no way we can bundle Java on Linux in a way which will work for everyone.
This is because the “other” package doesn’t bundle Java with it.
I am pretty sure this is overcomeable. That’s the whole point of dynamic libraries. And even if it worked one day it would be broken by any upgrade. For example: sourceware.org/legacy-ml/glibc- … 00012.html
Then surely this requirement should be made more specific.
The problem here is that the bundled version of Java was linked
against a newer glibc than Debian 10 has. That’s aggravating, as it
means there’s probably no way we can bundle Java on Linux in a way
which will work for everyone.
I am pretty sure this is overcomeable. That’s the whole point of dynamic
libraries. And even if it worked one day it would be broken by any
upgrade. For example: sourceware.org/legacy-ml/glibc- …
00012.html[1]
I’m not compiling Java, nor do I want to, so doing this isn’t on the table.
Joel,
Maptools at rptools have overcome this and bundled java with the program, perhaps you could have a look at their code and see what they did to get it running.
I have the same issue as posted above:
Error: dl failure on line 603
Error: failed /home/scott/Desktop/VASSAL-3.3.0-beta1/jre/lib/server/libjvm.so, because /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27’ not found (required by /home/scott/Desktop/VASSAL-3.3.0-beta1/jre/lib/server/libjvm.so)
Joel,
Maptools at rptools have overcome this and bundled java with the
program, perhaps you could have a look at their code and see what they
did to get it running.
I took a look through the git repo for MapTool and didn’t find where
the bundling happens.
Are you sure they’ve found a solution, rather than just bundling a
rather old version of Java?
Check out the “FAT” version. IE the .jar, that may have some clue as it does not require any java be installed.
of course you may be on the right track for the version bundled, but at least it works, at 52.7 mb size I just don’t believe it has a whole java bundled.
Check out the “FAT” version. IE the .jar, that may have some clue as it
does not require any java be installed.
of course you may be on the right track for the version bundled, but at
least it works, at 52.7 mb size I just don’t believe it has a whole java
bundled.
I checked the the symbols in libjvm.so contained in maptool-1.8.0-x86_64.rpm:
So, my guess was correct: They “solved” the problem by linking Java against
a glibc so ancient that no one could possibly still be using somehting
older. Glibc 2.7 was released in October 2007.
There’s no JVM in the big .jar.
So… yeah. We’re not bundling Java with the Linux builds and I’m going to
update VASSAL.sh to do a version check and print an error message if you’re
not running Java 9 or later.
