Huh so only ubuntu-20.04 and clang fails using static? other ubuntus are fine? 🤔

Ah no also gcc, misread above

Can reproduce with ubuntu docker image:

$ docker run -ti -v $PWD:$PWD -w $PWD ubuntu:20.04
... <configure, build etc>...
root@83a347734b03:/Users/wader/src/jq# gdb --args ./jq
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
....
(gdb) r
Starting program: /Users/wader/src/jq/jq
warning: Error disabling address space randomization: Operation not permitted

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000000004ec78c in __register_frame_info_bases.part.0 ()
#2  0x0000000000401ec1 in frame_dummy ()
#3  0x0000000000000001 in ?? ()
#4  0x00000000004edd3c in __libc_csu_init ()
#5  0x00000000004ed48e in __libc_start_main ()
#6  0x0000000000401dde in _start ()
(gdb)

Dugg a bit, i suspect it might be something like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989 some version of glibc pthreads don't like static linking. Usually you can make it work by providing a lots of link flags to tell it to resolve weak symbols and whatnot, but it's a mess.

Also got me thinking: do the jq cli need threads? looking at the code it seems to be about making libjq possible to use concurrently? but it's probably no easy task to make it optional

I also see that jq do call some libc functions like getpwuid that i suspect might trigger NSS usage that i think might trigger dynamic loading and might crash hmm

In my experience if one really want static binaries linking with musl is the "safest"... but that might have some other issues.... but again in my experience with modern musl versions there are few issues

btw alpine, that uses musl, already package jq and i haven't had any issues with it and looking at their bug tracker for jq issues https://gitlab.alpinelinux.org/alpine/aports/-/issues/?search=jq&sort=created_date&state=closed&first_page_size=20 i don't see anything that looks like reported random strange crashes

Did a test using CC=musl-gcc (needs package musl musl-dev musl-tools) and it seems to work fine and make check passes

root@83a347734b03:/Users/wader/src/jq# file jq
jq: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
root@83a347734b03:/Users/wader/src/jq# ls -lh jq
-rwxr-xr-x 1 root root 1.8M Jul  2 14:04 jq
root@83a347734b03:/Users/wader/src/jq# strip jq
root@83a347734b03:/Users/wader/src/jq# file jq
jq: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
root@83a347734b03:/Users/wader/src/jq# ls -lh jq
-rwxr-xr-x 1 root root 1.1M Jul  2 14:04 jq
root@83a347734b03:/Users/wader/src/jq# ./jq --version
jq-1.6-215-gf88c4e5-dirty
root@83a347734b03:/Users/wader/src/jq# ./jq -n 1+2
3

Nice find! I'm going to merge this PR so that you have something to base off.

👍 sounds good

Yeap i think alpine for static binaries could be a good alternative, then i think we could truely have one binary that works on any linux kernel. @itchyny seemed a bit concerned about it but maybe can be convinced :) the alternative think is find a good distro and glibc version that produce known "good" static binaries, i guess that is was the previous releases did?

Out of curiosity had a look at the current jq 1.6 linux64 binary:

$ ldd jq-linux64
	not a dynamic executable
$ file jq-linux64
jq-linux64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=c159e8a134ee222019dfbac0a1af4bc94b302eb0, with debug_info, not stripped

but couldn't find what libc variant/version is it, glibc something?

also notice that jq 1.6 had 32bit builds

I noticed this on some CI builds but for some reason (randomly?) only on macOS 12

Yup, that's what I saw. Perhaps the GH Actions macos-12 image has some issue? The update-reset fallback helps with that, as you see.