Stop linking gccpp outside Windows (fixes silent Vulkan render failure with lavapipe)

[charlesstaats]

Title: Stop linking gccpp outside Windows (fixes silent Vulkan render failure with lavapipe)

On Linux, the CMake build linked bdwgc's gccpp, which replaces the global operator new/delete for the whole process, including libraries loaded with dlopen. With Mesa's lavapipe (CPU Vulkan), LLVM allocates on lavapipe's own threads, which the GC doesn't know about. When one of those allocations triggers a collection, bdwgc aborts with "Collecting from unknown thread". The crash happens in the forked render child, so asy still exits 0 and simply writes no image.

• CMake: link gccpp only on Windows, where replacing operator new doesn't reach other DLLs. This matches the autotools build, which stopped linking the bundled libgccpp.a in 2007; asy keeps its GC pointers in gc-allocated memory (mem:: containers, gc_allocator).
• Autotools: remove the two AC_CHECK_LIB([gccpp],[GC_throw_bad_alloc]) probes. They look for a C-linkage symbol, but bdwgc declares GC_throw_bad_alloc with C++ linkage, so the library exports only the mangled name and the probes cannot succeed (confirmed against Debian's libgccpp). Also remove GCPPLIB, which was never assigned.

Testing (Debian trixie, lavapipe, no GC_DONT_GC):

• CMake (linux/release): ctest 7/7 passed. Teapot and cube render at -render=4. 35 of 40 3D examples render; four stop on missing LaTeX packages, and BezierSurface writes label.png because of its embed("label", …).
• Autotools: ./autogen.sh && ./configure takes the Vulkan branch, and make asy and make check pass. The teapot renders through libasyvulkan.so, lavapipe and LLVM.
• Not tested on macOS or Windows.

🤖 Generated with Claude Code