GitHub Discussion: CGO_ENABLED=1 Support

Title: Discussion: Should goffi support CGO_ENABLED=1?

Body:

Following the feedback from @jiyeyuran on PR #12, we want to open a community discussion about whether goffi should support CGO_ENABLED=1.

Current Design

goffi is a pure Go FFI library specifically designed for GPU computing (WebGPU, Vulkan, Metal). It requires CGO_ENABLED=0 because it uses Go's cgo_import_dynamic mechanism for dynamic library loading.

Why Pure Go?

The gogpu ecosystem (wgpu, gg, ui, naga) is built entirely in pure Go. This enables:

• Zero C compiler dependency — users don't need gcc/clang installed
• Seamless cross-compilation — GOOS=linux GOARCH=arm64 go build just works
• Single static binary — simplified deployment
• Consistent behavior — no platform-specific CGO quirks

The Question

@jiyeyuran raised a valid concern: if goffi only works with CGO_ENABLED=0, it cannot coexist with CGO-dependent libraries like mattn/go-sqlite3.

Example scenario:

My App
├── gogpu/ui (graphics) → requires goffi → requires CGO_ENABLED=0
└── mattn/go-sqlite3 (database) → requires CGO_ENABLED=1
                                   ↓
                              CONFLICT!

Our Analysis

Pure Go Alternatives Exist

For most common needs, pure Go alternatives are available:

Performance Consideration

Benchmarks show modernc.org/sqlite is 2-3x slower for bulk INSERTs, but for typical GUI application workloads (small datasets, occasional queries), the difference is negligible.

Cross-Compilation Trade-off

If we add CGO_ENABLED=1 support, users who enable it would lose the cross-compilation benefits anyway. They'd need a C compiler for the target platform.

Options

Option A: Stay CGO_ENABLED=0 Only (Current)

Pros:

• Simple, focused library
• Easy cross-compilation
• No C compiler needed
• Single code path to maintain

Cons:

• Cannot coexist with CGO libraries
• Users must use pure Go alternatives

Option B: Add CGO_ENABLED=1 Support (like purego)

Pros:

• Can coexist with any CGO library
• Broader adoption potential

Cons:

• ~40-60 hours implementation effort
• 2x testing matrix (both modes × all platforms)
• More complex codebase
• purego (which does this) is still "beta software" with known issues

Option C: Recommend purego for CGO Users

Message: "goffi is optimized for pure Go GPU computing. For CGO coexistence, use purego."

Pros:

• Keep goffi simple
• purego already solves this

Cons:

• Fragments the ecosystem

We Want Your Input

1. Do you have a real use case that requires goffi + a CGO library with NO pure Go alternative?

2. Would you accept using modernc.org/sqlite instead of mattn/go-sqlite3 for GUI applications?

3. Is cross-compilation important to you? (CGO_ENABLED=1 makes this harder)

4. Which option do you prefer? A, B, or C?

Please share your thoughts! This will help us make an informed decision about goffi's future direction.

cc: @jiyeyuran