I want to reproduce the release build of Nim compiler+ accompanying tooling utilities to byte-by-byte match binary artifacts provided by choosenim. Can someone tell me how to do it?
Reason: nimsuggest provided by choosenim crashes under Intel Clear Linux. This distro is ultra-optimized (https://www.phoronix.com/review/zen4-clear-linux), but differs greatly from mainstream Linux flavours in terms of system files layout and dynamic linking. I want to track and fix the inconsistency.
Like this https://github.com/nim-lang/nightlies/blob/master/build-release.sh ?
But for debugging nimsuggest almost any build of nimsuggest should do.
Thank you for pointing to the proper build script.
Can you also provide not only the recipe, but also the environment used for building https://nim-lang.org/download/nim-1.6.12-linux_x64.tar.xz release artifact? OS/docker image, host Nim compiler, gcc version, OpenSSL version, libc version.
Reproduced.
Stack trace:
$ path/to/fresh/static-musl-linked/nimsuggest --log --epc --v2 any_src.nim
nimsuggest.nim(387) replEpc
nimsuggest.nim(313) connectToNextFreePort
nim-1.6.12/lib/pure/net.nim(1023) bindAddr
nim-1.6.12/lib/pure/nativesockets.nim(308) getAddrInfo
nim-1.6.12/lib/pure/includes/oserr.nim(95) raiseOSErrorI guess it's musl-libc's fault, not Nim one, because nimsuggest with regular gcc + glibc linkage works great under Clear Linux. Will try to dig deeper...
this would be really cool; i've always had the itch to switch to clear
Just tried it couple of days ago. Performance is awesome: Ryzen 9 laptop works like a jet engine under this distro. Also successfully resurrected old Chinese Atom netbook from Aliexpress just for fun. CL works better than modern Ubuntu, Fedora or Arch on this trashy piece of hardware :)
VSCode and CLion started successfully except for Nim plugin. That's how I found this nimsuggest bug.
I have an 3-yr old private Nim project that is still able to reproduce binary-equal build and run. Here is the dockerfile I use in CI.
FROM nimlang/nim:1.2.6 as build
# docker image prune --filter label=stage=builder
LABEL stage=build
WORKDIR /mnt
# copy sources for build
COPY res/dist/ res/dist
COPY src/ src
COPY nim.cfg nim.cfg
COPY some_nim_proj.nimble some_nim_proj.nimble
# for cloning private repo in nimble
RUN printf "\n[credential]\n helper = store" >> ~/.gitconfig
COPY .git-credentials /root/.git-credentials
# build
RUN nimble build -y -d:release
# ----
# runtime image
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y \
libpq5 \
libsodium-dev \
libmagic-dev \
&& rm -rf /var/lib/apt/lists/*
# copy files from build to runtime image
COPY --from=build /mnt/bin/some_nim_proj /usr/local/bin/some_nim_proj
#USER nobody
CMD ["some_nim_proj"]
In order to really reproduce the same result, it is required to have
Yep, it is a musl-libc bug. It makes too many rigid assumptions on Linux VFS layout.
For example it assumes hosts and services locations are hardcoded to /etc/hosts and /etc/services!
https://git.musl-libc.org/cgit/musl/tree/src/network/getaddrinfo.c https://git.musl-libc.org/cgit/musl/tree/src/network/lookup_name.c https://git.musl-libc.org/cgit/musl/tree/src/network/lookup_serv.c
But that's not true in distros with immutable system volume like Clear Linux.
That is the reason of getAddrInfo (nim-1.6.12/lib/pure/nativesockets.nim(308)) crash on Clear Linux when linked with musl-libc.
Quick and dirty fix: change "localhost" to "127.0.0.1": https://github.com/nim-lang/Nim/blob/26b7a74a45059453b42f8eee4ccf0586b9003087/nimsuggest/nimsuggest.nim#L389