@FourthWorld is correct - it is in the release notes. These are built from markdown files in the github repository. Specifically:<rant1>
Where is the list of supported linux distros? I can't find it on the web site any more nor on github.
LiveCode supports the following Linux distributions, on 32-bit or 64-bit Intel/AMD or compatible processors:
Ubuntu 14.04 and 16.04
Fedora 23 & 24
Debian 7 (Wheezy) and 8 (Jessie) [server] CentOS 7 [server]
LiveCode may also run on Linux installations which meet the following requirements: Required dependencies for core functionality: glibc 2.13 or later glib 2.0 or later
Optional requirements for GUI functionality:
GTK/GDK 2.24 or later
Pango with Xft support
esd (optional, needed for audio output)
mplayer (optional, needed for media player functionality) lcms (optional, required for color profile support in images) gksu (optional, required for privilege elevation support)
Note: If the optional requirements are not present then LiveCode will still run but the specified features will be disabled.
Note: The requirements for GUI functionality are also required by Firefox and Chrome, so if your Linux distribution runs one of those, it will run LiveCode.
Note: It may be possible to compile and run LiveCode Community for Linux on other architectures but this is not officially supported.
No we won't be moving to 'Buster' in June - indeed, it is unlikely we will change anything in June.So in June are we going to switch to a more recent version of the base distro with an updated gcc and incorporate either my pull request or Ian's version that accomplishes something similar so I can stop having to patch the build system locally? Note that the current stable and recommended version of Debian is 10 ("buster").
Our build system is containerized so that we can continue to use older OSes (without any security issues) to build LiveCode to ensure that it continues to run as widely as possible.
If we move up one version of Debian, chances are the built executables will no longer run on other distributions of a similar age to Debian 8 which are still supported (and will continue to be for several years to come).
The problem is that the Linux community as a whole 'does not do binary compatibility' - but we have to, which means we have to build on what some might call 'legacy distributions'... I say some, because things like CentOS/RHEL have a support window spanning 10 years - precisely because upgrading Linux is a great deal of work when it isn't just your personal machine!
In regards to the issue with dbsqlite which this thread started with - unfortunately your current patch isn't correct (so wouldn't be merged in any event). The issue isn't to do with a setting in revdb - its because (by default) the engine builds using prebuilt libraries from our build server whose build settings aren't compatible with your setup (we do this as things like Skia take a very long time to compile). I'll see if I can find out how to disable this, so they all build locally (which is more appropriate as binary incompatibility could creep in anywhere - revdb suffers because libsqlite uses std::string and C++ exceptions which is where the API changes are toggled by the flag).