Description

When pkg-config sqlite3 fails (e.g. libsqlite3-dev is not installed), the SQLite module falls back to #flag -lsqlite3, which also requires a system development package. This means users who have run vlib/db/sqlite/install_thirdparty_sqlite.vsh to download the bundled amalgamation still cannot compile db.sqlite without a system package.

Relationship to #26724

PR #26724 (merged) made a partial fix to this area:

• Moved -I@VEXEROOT/thirdparty/sqlite outside the $if windows block so all platforms can find sqlite3.h from the thirdparty directory
• Added a $pkgconfig('sqlite3') check as the preferred path
• But deliberately kept -lsqlite3 as the non-Windows fallback

This means after #26724, the header is found correctly — but linking still fails on systems where only libsqlite3.so.0 is present (no dev package, no .so symlink for the linker).

This issue tracks the remaining linker half of the problem.

Steps to reproduce

1. On a Linux system without libsqlite3-dev installed (only the runtime .so.0 present, no .so symlink)
2. Run vlib/db/sqlite/install_thirdparty_sqlite.vsh to download the bundled amalgamation
3. Compile any program using db.sqlite

Result:

cc: tcc: error: library 'sqlite3' not found

Expected behavior

The bundled amalgamation (thirdparty/sqlite/sqlite3.c) downloaded by install_thirdparty_sqlite.vsh should be compiled directly when pkg-config is unavailable, as it already is on Windows. Both the header and link steps should work without any system package.

Fix

PR #26817 completes what #26724 started — it replaces #flag -lsqlite3 with #flag @VEXEROOT/thirdparty/sqlite/sqlite3.c in the non-Windows, no-pkg-config fallback branch, mirroring the Windows behaviour.

Verified on WSL2 (Ubuntu, no libsqlite3-dev): fails on master, passes with the fix applied.