Hi there:

I use musl-cross for cross compiling before, so far so good.

But 3.48.0 build failed, here's the output:

./jimsh /usr/src/sqlite-3.48.0/tool/mksqlite3c.tcl --linemacros=0 
cp tsrc/sqlite3ext.h .
cp /usr/src/sqlite-3.48.0/ext/session/sqlite3session.h .
aarch64-unknown-linux-musl-cc -fPIC -g -O2  -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_THREADSAFE=1   -DNDEBUG -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -I. -I/usr/src/sqlite-3.48.0/src -I/usr/src/sqlite-3.48.0/ext/rtree -I/usr/src/sqlite-3.48.0/ext/icu -I/usr/src/sqlite-3.48.0/ext/fts3 -I/usr/src/sqlite-3.48.0/ext/session -I/usr/src/sqlite-3.48.0/ext/misc -c sqlite3.c
aarch64-unknown-linux-musl-cc -fPIC -g -O2  -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_THREADSAFE=1   -DNDEBUG -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -I. -I/usr/src/sqlite-3.48.0/src -I/usr/src/sqlite-3.48.0/ext/rtree -I/usr/src/sqlite-3.48.0/ext/icu -I/usr/src/sqlite-3.48.0/ext/fts3 -I/usr/src/sqlite-3.48.0/ext/session -I/usr/src/sqlite-3.48.0/ext/misc  -o sqlite3 \
	shell.c sqlite3.c \
	 -DSQLITE_HAVE_ZLIB=1 -DSQLITE_DQS=0 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_EXPLAIN_COMMENTS -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION -DSQLITE_ENABLE_STMTVTAB -DSQLITE_ENABLE_DBPAGE_VTAB -DSQLITE_ENABLE_DBSTAT_VTAB -DSQLITE_ENABLE_BYTECODE_VTAB -DSQLITE_ENABLE_OFFSET_SQL_FUNC -DSQLITE_STRICT_SUBTYPE=1  \
	-Wl,-rpath,/cross_root/aarch64-unknown-linux-musl/lib    -lz  -L/cross_root/aarch64-unknown-linux-musl/lib64 -L/cross_root/aarch64-unknown-linux-musl/lib -I/cross_root/aarch64-unknown-linux-musl/include -s -static --static 
aarch64-unknown-linux-musl-ar cr  libsqlite3.a sqlite3.o
/usr/bin/install -m 0644 sqlite3.pc "/cross_root/aarch64-unknown-linux-musl/lib/pkgconfig"
/usr/bin/install -m 0644 libsqlite3.a "/cross_root/aarch64-unknown-linux-musl/lib"
/usr/bin/install -m 0644 sqlite3.h "/usr/src/sqlite-3.48.0/src/sqlite3ext.h" "/cross_root/aarch64-unknown-linux-musl/include"
TCL support disabled, so not installing libtclsqlite3.so
/usr/bin/install -s sqlite3 "/cross_root/aarch64-unknown-linux-musl/bin"
strip: Unable to recognise the format of the input file `/cross_root/aarch64-unknown-linux-musl/bin/sqlite3'
/usr/bin/install: strip process terminated abnormally
make: *** [/usr/src/sqlite-3.48.0/main.mk:2020: install-shell-0] Error 1
Error: Process completed with exit code 2.

Full build log can be found here: https://github.com/abcfy2/aria2-static-build/actions/runs/12839488982/job/35806827761

/usr/bin/install -s sqlite3 "/cross_root/aarch64-unknown-linux-musl/bin"

This is now fixed in the trunk and the 3.48 branch. The quick workaround is to remove the -s flag from $(INSTALL) -s in the two places where it appears in main.mk.

Thank you for the report.

Background:

"install -s" is expecting to strip a binary of the platform it's running on, not the target platform. For example, if we copy a binary from a Raspberry Pi (ARM) to this x64 system:

$ scp pi4b8:bin/fossil.bin .
...
$ strip fossil.bin 
strip: Unable to recognise the format of the input file `fossil.bin'

For comparison, I tried digging into the build log of 3.47.2, I find 3.47.2 will not use strip for sqlite3 binary cli, full build log: https://github.com/abcfy2/aria2-static-build/actions/runs/12606220379/job/35136039880

./libtool --mode=link aarch64-unknown-linux-musl-gcc -g -O2 -DSQLITE_OS_UNIX=1 -I. -I/usr/src/sqlite-3.47.2/src -I/usr/src/sqlite-3.47.2/ext/rtree -I/usr/src/sqlite-3.47.2/ext/icu -I/usr/src/sqlite-3.47.2/ext/fts3 -I/usr/src/sqlite-3.47.2/ext/async -I/usr/src/sqlite-3.47.2/ext/session -I/usr/src/sqlite-3.47.2/ext/userauth -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_MATH_FUNCTIONS    -DSQLITE_HAVE_ZLIB=1  -L/cross_root/aarch64-unknown-linux-musl/lib64 -L/cross_root/aarch64-unknown-linux-musl/lib -I/cross_root/aarch64-unknown-linux-musl/include -s -static --static  -no-undefined -o libsqlite3.la sqlite3.lo -lz   \
	 -rpath "/cross_root/aarch64-unknown-linux-musl/lib" -version-info "8:6:8"
libtool: link: aarch64-unknown-linux-musl-ar cru .libs/libsqlite3.a  sqlite3.o
aarch64-unknown-linux-musl-ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: aarch64-unknown-linux-musl-ranlib .libs/libsqlite3.a
libtool: link: ( cd ".libs" && rm -f "libsqlite3.la" && ln -s "../libsqlite3.la" "libsqlite3.la" )
/usr/bin/install -c -d /cross_root/aarch64-unknown-linux-musl/lib
./libtool --mode=install /usr/bin/install -c libsqlite3.la /cross_root/aarch64-unknown-linux-musl/lib
libtool: install: /usr/bin/install -c .libs/libsqlite3.lai /cross_root/aarch64-unknown-linux-musl/lib/libsqlite3.la
libtool: install: /usr/bin/install -c .libs/libsqlite3.a /cross_root/aarch64-unknown-linux-musl/lib/libsqlite3.a
libtool: install: chmod 644 /cross_root/aarch64-unknown-linux-musl/lib/libsqlite3.a
libtool: install: aarch64-unknown-linux-musl-ranlib /cross_root/aarch64-unknown-linux-musl/lib/libsqlite3.a
libtool: finish: PATH="/cross_root/bin:/cross_root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /cross_root/aarch64-unknown-linux-musl/lib
----------------------------------------------------------------------
Libraries have been installed in:
   /cross_root/aarch64-unknown-linux-musl/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
/usr/bin/install -c -d /cross_root/aarch64-unknown-linux-musl/bin
./libtool --mode=install /usr/bin/install -c sqlite3 /cross_root/aarch64-unknown-linux-musl/bin
libtool: install: /usr/bin/install -c sqlite3 /cross_root/aarch64-unknown-linux-musl/bin/sqlite3
/usr/bin/install -c -d /cross_root/aarch64-unknown-linux-musl/include
/usr/bin/install -c -m 0644 sqlite3.h /cross_root/aarch64-unknown-linux-musl/include
/usr/bin/install -c -m 0644 /usr/src/sqlite-3.47.2/src/sqlite3ext.h /cross_root/aarch64-unknown-linux-musl/include
/usr/bin/install -c -d /cross_root/aarch64-unknown-linux-musl/lib/pkgconfig
/usr/bin/install -c -m 0644 sqlite3.pc /cross_root/aarch64-unknown-linux-musl/lib/pkgconfig

For comparison, I tried digging into the build log of 3.47.2,

Versions prior to 3.48 use a completely different build system, so are guaranteed to behave differently in some places. In the case of binaries and libraries, the installation was formerly managed by libtool, but libtool is no longer part of the build, so we went with the conventional "install -s" approach for binaries. In the case of the sqlite3 CLI tool, the unstripped binary is 4.5x larger than the stripped one:

# From a fresh branch-3.47 build
$ l sqlite3 
-rwxr-xr-x 1 stephan stephan 7385184 Jan 18 15:20 sqlite3
$ strip sqlite3 
$ l sqlite3 
-rwxr-xr-x 1 stephan stephan 1639032 Jan 18 15:20 sqlite3

We may re-consider this decision at some point, but it currently seems like the right thing to do.

Please re-consider.

Most linux distributors need the unstripped file to be installed. The reason is that we will strip the file ourselves as part of the package manager, but first we extract the debug information from the binary and copy it to a separately available package named "sqlite3-debug" or "sqlite3-dbg" or "sqlite3-dbgsym" or "sqlite3-debuginfo" (depending on the distro). Source-based distributions such as Gentoo instead make this a tuneable option in the package manager to either strip and discard, strip and save, or don't strip. The distro may also use https://sourceware.org/elfutils/Debuginfod.html to process the resulting debug packages and host them on a public debuginfo server so that users with the appropriate download urls set, can simply run their debugger and have it download debug segments for the precise binary (or library) opened by the debugger.

Regardless of which option gets selected, the result is that for users who ask the package manager to install debug symbols, they get a /usr/lib/debug/usr/bin/sqlite3.debug file which the debugger can find and load. They still get a stripped binary by default:

$ gdb --args sqlite3

Reading symbols from sqlite3...
Reading symbols from /usr/lib/debug//usr/bin/sqlite3.debug...

To be clear, it's acceptable if sqlite3 strips the binary by default for the sake of people casually downloading and compiling sqlite for personal reasons, as long as there's a configure option for advanced users (such as distribution packagers) to disable this. Only being able to disable strip for cross builds isn't great.