Common errors and fixes

Six of the seven failures below were hit while building TerraGear and running it end to end on 23 August 2026: TerraGear next at commit eba49f2, SimGear release/2024.1, Debian 12, gcc 12.2: across two separate one-degree squares. The output is quoted as it appeared. The remaining one is marked as reported rather than observed, because it did not happen here.

They are in the order you would meet them, and the common thread is that most of them do not look like errors.

SimGear will not configure: c-ares not found

Symptom. CMake stops before anything compiles:

CMake Error at FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find c-ares (missing: c-ares_INCLUDE_DIR c-ares_LIBRARY)
  (Required is at least version "1.17")
Call Stack (most recent call first):
  CMakeModules/Findc-ares.cmake:37 (find_package_handle_standard_args)
  CMakeLists.txt:485 (find_package)

Cause. SimGear needs c-ares for DNS, and the find module needs pkg-config to locate it. Neither is pulled in by a build-essential installation, and neither is mentioned where you would look for it.

Fix. On Debian or Ubuntu:

apt-get install pkg-config libc-ares-dev

If you see six consecutive Could NOT find PkgConfig lines earlier in the output, that is the same problem showing itself before it becomes fatal.

SimGear next will not build headless

Symptom. The build starts, then stops on a canvas file you did not ask for:

FAILED: simgear/canvas/elements/CMakeFiles/canvas_element.dir/canvas_element_test.cpp.o
CanvasElement.hxx:12:10: fatal error: simgear/canvas/canvas_fwd.hxx: No such file or directory
   12 | #include <simgear/canvas/canvas_fwd.hxx>

Cause. -DENABLE_TESTS=OFF does not reach this target. add_simgear_scene_autotest() in CMakeModules/AddSimGearTest.cmake calls add_executable unconditionally, it never checks ENABLE_TESTS, and in simgear/canvas/elements/CMakeLists.txt the call sits outside the if() that guards the canvas sources. So the test is built while the headers it needs are not.

Fix. Build SimGear release/2024.1 instead of next. It routes the same test through a function that does respect ENABLE_TESTS, and it treats c-ares as optional. That combination, SimGear release/2024.1 under TerraGear next, is what produced the scenery described on this site.

TerraGear will not compile: std::chrono has not been declared

Symptom. One file out of ninety-nine fails:

hgtchop.cxx: In function 'int main(int, char**)':
hgtchop.cxx:28:28: error: 'std::chrono' has not been declared
   28 |     auto start_time = std::chrono::high_resolution_clock::now();
      |                            ^~~~~~
hgtchop.cxx:80:10: error: 'std::chrono' has not been declared
   80 |     std::chrono::duration<double> elapsed = finish_time - start_time;

Cause. Commit bf79e24, “clean up includes”, 18 June 2026, removed #include <chrono> from src/Prep/DemChop/hgtchop.cxx and left four uses of std::chrono behind. Seven other files in the tree use std::chrono; all seven still include it. This one does not, so next has not compiled since that date.

Fix. Put the include back:

sed -i '6i #include <chrono>' src/Prep/DemChop/hgtchop.cxx

genapts runs forever and produces nothing

Symptom. It starts, prints its settings, and then does nothing you can see; one core pinned, memory flat, the output directory empty, and no error to search for. Killed at 25 minutes.

Cause. A gzipped apt.dat. The version check reads gzip, so the file passes; the scan that follows does not, so it never matches an airport and never stops. --help says gzip is supported. For this path it is not.

Fix.

gunzip -k apt.dat.gz
genapts --input=apt.dat ...

The two readers, with the source lines, are on the genapts page.

genapts exits 139 with only some of the airports built

Symptom. Segmentation fault, exit status 139, and an output directory that is not empty:

[ALRT]:general  Error reading Index file .../AirportArea/w130n30/w123n37/chop.idx abort
corrupted size vs. prev_size while consolidating
Segmentation fault

Cause. Several threads writing one shared index at once. Small regions suffer most, since fewer buckets means more airports contending for the same file.

Fix. --threads=4. Bare --threads takes your core count and failed every attempt here.

And check the exit status, which is the part that catches people. What this leaves behind is not wreckage: it is a directory of valid airports, just an incomplete one; between none and 24 of the expected 31 across the crashed runs here. Every later stage accepts that silently. It is the only failure on this page whose result you can fly around in without noticing.

Forty-four runs at seven thread counts, and why it is a probability rather than a threshold: the genapts page.

The README’s build instructions do not exist

Symptom. The README tells you to run autogen.sh and then configure. Neither file is in the repository.

Cause. The README describes the autotools build the project used before it moved to CMake. The same checkout contains CMakeLists.txt, which requires CMake 3.20 or newer.

Fix. Use the CMake build on Installing TerraGear. Note also that README.SimGear is dated 21 February 2001 and points at simgear.org; SimGear now lives on GitLab alongside TerraGear.

The scenery builds, and FlightGear shows open ocean

The last step, and the one with nothing to search for, because there is no error message; just water where your terrain should be. The log has the answer but it does not look like a failure:

[ALRT]:terrain  Found scenery file Path ".../e000n40/e007n49/3072754.stg" in scenery path /w/output-rlp.
Scenery paths without type subdirectories are no longer supported, please move thse files

Every file is found, and every file is declined. tg-construct writes a flat bucket tree and current FlightGear will not read one: it wants Terrain/ and Objects/ directories above the buckets.

mkdir -p scenery/Terrain scenery/Objects
cp -r output/* scenery/Terrain/
fgfs --fg-scenery=$PWD/scenery ...

Do not try to be tidy by putting the airports in Objects/ and the tiles in Terrain/. Each tile’s .stg refers to its airports by bare filename and expects them beside it, so that split produces a different failure that is no more self-explanatory:

[WARN]:OSG      Error reading file .../Terrain/e000n40/e007n49/ETAR.btg: read error
[ALRT]:terrain  Path ".../3072730.stg": Failed to load OBJECT '.../ETAR.btg'

The Objects/ directory has to exist, but it can stay empty.

Two harmless messages you will see either way, and can ignore: Failed to load OBJECT_SHARED 'Models/Airport/windsock_lit.xml' and the same for beacon.xml. Those models live in the full FlightGear base package; missing them costs you a windsock, not the scenery.

tg-construct terminates without an obvious error

Reported, not observed. A silent death with no diagnostic, on a large build. Neither build behind this site reproduced it: one degree square is far smaller than the conditions the warning describes, so it is here only so that you know where to start looking, and the wiki’s suggested remedy is summarised on the tg-construct page rather than repeated as though it had been tested.