Error loading shared libraries after image is built about goreleaser HOT 8 CLOSED

ahh I think that's from our regular docker build. we have been neglecting using goreleaser since last august I think.

but you might be right about issues with either zig or go.

I'll close this issue for now. thanks for your help!

from goreleaser.

yeah, I would try to find the last time it worked, and work up from there... I don't have too much experience with cgo, sorry if I can't offer better help

from goreleaser.

This is the latest CI run which successfully builds the images:
https://github.com/smartcontractkit/chainlink/actions/runs/7820985842

this ran on go 1.21, does the problematic builds use go 1.22? It's the one thing I can think of that changed recently.

GoReleaser does go build passing the args, GOOS, GOARCH, etc, and doesn't enforce any mod path or anything like that..

from goreleaser.

Thanks for the help @caarlos0!

The image builds fine through the CI but we have an extra file that was downloaded from a func in the prehook script here:

_get_wasmvm_lib_path() {
  local -r platform="$1"
  local -r arch="$2"
  wasmvm_dir=$(go list -json -m all | jq -r '. | select(.Path == "github.com/CosmWasm/wasmvm") | .Dir')
  shared_lib_dir="$wasmvm_dir/internal/api"
  lib_name="libwasmvm"
  if [ "$platform" == "darwin" ]; then
    lib_extension="dylib"
  elif [ "$platform" == "linux" ]; then
    case "${arch}" in
    x86_64 | amd64) lib_extension="x86_64.so" ;;
    aarch64 | arm64) lib_extension="aarch64.so" ;;
    *) echo "Unsupported arch $arch" && exit 1 ;;
    esac
  else
    echo "Unsupported platform $platform"
    exit 1
  fi
  echo "$shared_lib_dir/${lib_name}.$lib_extension"
}

which is suppose to download the wasmvm module get a get a specific file from it and store it as an artifact to be copied to the docker image.

The problem is when we run the binary of the image we had built it's using the gopath of the local machine that's downloading the go module to get that libwasmvm.aarch64.so file instead of getting it from the correct path where we specified to copy to: /usr/local/bin/libs/libwasmvm.aarch64.so.

Hence we get this error because the file exists in /usr/local/bin/libs/libwasmvm.aarch64.so.

root@fea6e4a489dc:/home/root# chainlink -version
chainlink: error while loading shared libraries: /home/runner/go/pkg/mod/github.com/!cosm!wasm/[email protected]/internal/api/libwasmvm.aarch64.so: cannot open shared object file: No such file or directory

Appreciate any insight that you may have.

from goreleaser.

yes, I noticed that too... this is extra weird, as trimpath should take care of that

although, maybe you need to pass it to gcflags and/or asmflags too?

from goreleaser.

hmm do you mean to set it like this?

    # asmflags:
    #   - "all=-trimpath={{ .Env.GOPATH }}"
    # gcflags:
    #   - "all=-trimpath={{ .Env.GOPATH }}"

and provide/set the GOPATH in the the goreleaser_wrapper script?

sorry I'm rather new to goreleaser so bear with me. it seems like the dynamic linking of shared library is not a unique problem:
https://stackoverflow.com/questions/14560857/error-while-loading-shared-libraries-libsandbox-so

in the function _get_wasmvm_lib_path() that's being used in prehook and posthook we are calling this:

  wasmvm_dir=$(go list -json -m all | jq -r '. | select(.Path == "github.com/CosmWasm/wasmvm") | .Dir')

which is what's setting that GOPATH but we copying it to a tmp lib folder but somehow the dynamic linking is still pointing to the local machine.

thanks for debugging this with me!

from goreleaser.

when I'm did this with ldd I get this which is the origin of the problem described above

root@c1656e97bf12:/home/root# ldd /usr/local/bin/chainlink
	linux-vdso.so.1 (0x0000ffff8e45b000)
	/Users/momentmaker/.asdf/installs/golang/1.21.5/packages/pkg/mod/github.com/!cosm!wasm/[email protected]/internal/api/libwasmvm.aarch64.so => not found
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff888e8000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff88775000)
	libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000ffff8874f000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff8e42b000)

from goreleaser.

what have changed since your last successful image build?

because this one seems to have it right:

maybe its something on a zig/go update?

goreleaser does nothing with ld path or any of that, and the build logic haven't changed since a couple of versions ago, so I doubt the problem is here.

from goreleaser.