Conversation
Cool, I had the same idea, but first the new arm64 builds have to be accepted ;)
Do you still have the binaries locally? They seem not to available anymore: |
The uploaded artifacts are on the "Summary" page, e.g. the one that failed the Windows build: https://github.com/owenthereal/jq/actions/runs/5302038760. But the Windows binary is not there because it didn't get to the end of a successful build. |
* Group CI builds for different OSes into `ci.yml`. * Add release job to release `jq` when tag is in the format of v*. * Use `clang` as the only compiler on CI. * Provide extensible matrix for future cross-compile builds, e.g. for jqlang#2618.
`brew update` can fail for "Error: Fetching /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask failed!" Ref: https://github.com/owenthereal/jq/actions/runs/5432314910/jobs/9879266028#step:3:19
2a5fd27 to
d45ae41
Compare
|
Thank you @wader for helping with debugging the I updated this PR to build for both To release binaries, This PR is ready to review again. |
d45ae41 to
9ca8227
Compare
9ca8227 to
6cce62d
Compare
|
Does anyone know how compatible the ubuntu binaries will be? will they run on most modern linux distributions? thinking glibc compatibility etc. If it's a compatibility mess would it make sense to build them static somehow? |
|
Is the plan to add arm64 in this PR or do that separately? |
I'm planning to do that separately. I haven't had a chance to verify an arm64 build on the amd64 CI will work on an arm64 machine. |
|
The example release link seems to return 404... also maybe i should invest in a windows VM so i can actually test things properly :) |
487a15a to
8dffb23
Compare
.github/workflows/ci.yml
Outdated
| runs-on: ${{ matrix.image }} | ||
| env: | ||
| CC: ${{ matrix.compiler }} | ||
| CC: ${{ matrix.compiler }} -static |
There was a problem hiding this comment.
I think you should be able to do this via configure somehow, there is --enable-all-static which seems to use ld flag -all-static which i don't think i've used myself before.
There was a problem hiding this comment.
glibc can be a pain to build static with but jq i hope can be fine as i think the most pain comes from programs that need NSS or DNS
There was a problem hiding this comment.
Updated to use the --enable-static & --enable-all-static flags for LInux & MacOS, Windows already does that: 2480dd2
There was a problem hiding this comment.
Hmm...tests failed for ubuntu 20.04 after static is enabled (22.04 was passing though) : https://github.com/jqlang/jq/actions/runs/5432682781. They failed for "Segmentation fault", e.g. https://github.com/jqlang/jq/suites/14001000347/artifacts/781225809
There was a problem hiding this comment.
That's not good :( maybe revert for now? i can digg into it later if you want
There was a problem hiding this comment.
Please help :). I disabled static build for ubuntu 20.04 for now: 6520242. Feel free to enable it once it's fixed.
I updated the example release link. Sorry for the inconvenience. |
8dffb23 to
2480dd2
Compare
.github/workflows/ci.yml
Outdated
| libtool \ | ||
| flex \ | ||
| bison | ||
| sed -i.bak '/^AM_INIT_AUTOMAKE(\[-Wno-portability 1\.14\])$/s/14/11/' modules/oniguruma/configure.ac |
There was a problem hiding this comment.
This line was inherited from the old CI setup. I believe it was to enforce onigurma's automake to be on the same version as jq. I confirmed this is not needed now. Removing.
| submodules: true | ||
| - name: Install packages | ||
| run: | | ||
| # brew update sometimes fails with "Fetching /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask failed!" |
There was a problem hiding this comment.
I noticed this on some CI builds but for some reason (randomly?) only on macOS 12
There was a problem hiding this comment.
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.
| configure_flag: --enable-static --enable-all-static | ||
| - compiler: clang | ||
| image: ubuntu-20.04 | ||
| configure_flag: '' |
There was a problem hiding this comment.
Huh so only ubuntu-20.04 and clang fails using static? other ubuntus are fine? 🤔
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
3There was a problem hiding this comment.
Nice find! I'm going to merge this PR so that you have something to base off.
There was a problem hiding this comment.
👍 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
wader
left a comment
There was a problem hiding this comment.
Should we merge this and iterate on it? i think this also fixes the macOS 12 CI errors we're seeing
|
Hmm any idea why "CI / release (pull_request)" was skipped and the release builds stuck at "Expected — Waiting for status to be reported" ... expected as in expected to be stuck waiting? :) |
I have modified the requried actions to match this PR's. Now everything should be green :) |
Add the release pipeline for
jq. For now, it uploads build artifacts to a draft GH release. In the future, it can trigger an update of the website when a release is cut, for example.This PR includes the following changes:
ci.yml.jqwhen a tag is created in the format ofv*.Try to useclangas the compiler on CI for Linux & MacOS. I couldn't getCC=clangto work for Windows, though (test failures)clangcompiler doesn't work for msys2: MSYS2 clang va_start is broken msys2/MSYS2-packages#2291. We have to fall back to gcc for Windows build.An example release can be checked out here.