Connor Jakubik

Got it; I'll see if I can replicate this in a WSL build.

The program segfaulted on startup in the same line as `J2000_utc` in `WSL-GCC-Debug`. Well, that's a lot better than failing silently... Here's the GDB stack trace:  PreciseClock.h:113: `static sc_utc_time...

The white text looks *somewhat* similar to what happens when there is a stack overflow.

All of that sounds pretty plausible. My program is multithreaded but its tests aren't. I'll look into this.

From my initial probing, `leaps.size()` = 12 right before the segfault on WSL Debug.

I have `USE_OS_TZDB=0` `DATE_USE_DLL=1` on my Windows / MSVC build. Not sure how to check that for my WSL / GCC build though. I'll try setting that to 1.

Here's another gdb backtrace with `-DUSE_OS_TZDB=1`:  At least I'm pretty sure that's with that option entered. I specified it on the `cmake ..` command I use for makefile generation.

I do ```CMake if (MSVC) else() target_link_libraries(run_Server PRIVATE -lpthread) endif() ``` run_Server is my main executable though; I don't directly `-lpthread` on my testing executable. Here's a list of libraries...

I actually use std::thread instead of pthread now; I can remove that link.

Attempting to breakpoint in Windows now to examine the behavior around the first `utc_clock::from_local()`.