Suggested by Emilian, I assumed packagers tend to replace these files
or make their own decision anyway but for a non-terminal startup,
requesting the launcher seems a clear benefit to me.
The mirror protocol now sends the position for internal as well as
leaf nodes, and the group uses this data to sort when no explicit
Z-indices exist. This gets the extra-500 much closer to working!
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
1. The variables SIMGEAR_CORE_LIBRARIES and
SIMGEAR_CORE_LIBRARY_DEPENDENCIES are
no longer set... hence the need to hard-code 'SimGearCore'
in the target_link_libraries()
2. And -lfreetype means the linker must know the specific
link path to it, while the variable FREETYPE_LIBRARIES
contains the fully qualified path to the library.
3. Improved the 'found glut' message to show exactly what
was found, and being used... This is due to the user possibly
also have the near binary compatible glut32.lib found, which
will fail in the link due to some freeglut extensions have been
used.
4. Adding the define -DFREEGLUT_LIB_PRAGMAS=0 is
necessary to stop the freeglut headers from using a MSVC pragma
to declare the library, which will /not/ not be found...
5. In Windows the glew library is not -lGLEW, and even if it
was, it would not be found, without adding a link_directories(
path/to/library ),
while the GLEW_LIBRARIES variable has the fully qualified path.
Fix the sqlite3_value_text() interface so that it correctly translates content generated by zeroblob() into a string of all 0x00 characters. This is a long-standing issue discovered after the 3.16.1 release by OSS-Fuzz
Fix the bytecode generator to deal with a subquery in the FROM clause that is itself a UNION ALL where one side of the UNION ALL is a view that contains an ORDER BY. This is a long-standing issue that was discovered after the release of 3.16.1. See ticket 190c2507.
Adjust the sqlite3_column_count() API so it more often returns the same values for PRAGMA statements as it did in prior releases, to minimize disruption to applications that might be using that interface in unexpected ways.
As discussed on the devel list, only require the major+minor versions
of FG+SG+data to match by default. If we encounter a situation on
a release branch where stronger checks are needed, it’s easy to
restore.
