The VASSAL Team is happy to announce the release of VASSAL 3.3.0-beta1.
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.
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.
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.
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
|/ 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.
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- …
I’m not compiling Java, nor do I want to, so doing this isn’t on the table.
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)
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
I checked the the symbols in libjvm.so contained in maptool-1.8.0-x86_64.rpm: