Hugo binary does not run in Alpine: Error loading shared library libresolv.so.2

[axilleas]

I'm using the amd64.tar.gz binary from the releases page, and starting from 0.111.0, hugo extended fails to run in Alpine. This is not the case for 0.110.0 . Seems something changed in the way the binaries are built in version 0.111.0. I found this commit that might be relevant 60e6fa7.

The full error:

$ hugo version

#5 3.268 Error loading shared library libresolv.so.2: No such file or directory (needed by /usr/bin/hugo)
#5 3.271 Error relocating /usr/bin/hugo: __res_search: symbol not found

# ldd /usr/bin/hugo

        /lib64/ld-linux-x86-64.so.2 (0x7fe181203000)
Error loading shared library libresolv.so.2: No such file or directory (needed by /usr/bin/hugo)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fe181203000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fe18102b000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe181203000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fe181203000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fe181012000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe181203000)
Error relocating /usr/bin/hugo: __res_search: symbol not found

What version of Hugo are you using (hugo version)?

I cannot answer this because hugo fails to run.

Does this issue reproduce with the latest release?

Yes.

[axilleas]

After further inspection and discussion, it seems this is due to #10691.

[axilleas]

Could hugo be built statically instead? In https://www.reddit.com/r/golang/comments/10te58n/comment/j7eq6yv/, someone posted this can be done with:

go build --ldflags '-linkmode external -extldflags "-static"'

[bep]

Could hugo be built statically instead?

I don't think that will solve this particular issue, but I'm not sure.

Technically yes. We do that for Windows (for practical reasons; it's not common to have libc installed for the average Windows user).

But I would be very hesitant to do so for *nix, as that would mean that Hugo would determine which libc version every person would use, which puts lots of responsibility in the security department in our lap.

[axilleas]

Understood. For the time being, I've changed my Dockerfile to build from source 🙂

[sdwolfz]

For reference, here is a Dockerfile I used to work around this:

# ------------------------------------------------------------------------------
# Base

FROM golang:1.20.2-alpine

SHELL ["/bin/ash", "-c"]

# ------------------------------------------------------------------------------
# Working directory

RUN set -exo pipefail                   && \
                                           \
    echo 'Create the working directory' && \
    mkdir /work

WORKDIR /work

# ------------------------------------------------------------------------------
# Packages

RUN set -exo pipefail                 && \
                                         \
    echo 'Installing common packages' && \
    apk add --update --no-cache \
      build-base                \
      ca-certificates           \
      curl                      \
      git                       \
      libc6-compat              \
      libstdc++                 \
      make                      \
      rsync

# ------------------------------------------------------------------------------
# Hugo

RUN set -exo pipefail                                                    && \
                                                                            \
    echo 'Seting up temporary environment variables'                     && \
    VERSION=0.111.3                                                      && \
    SHA=b6eeb13d9ed2e5d5c6895bae56480bf0fec24a564ad9d17c90ede14a7b240999 && \
    PACKAGE=hugo-"$VERSION".tar.gz                                       && \
    BASE=https://codeload.github.com/gohugoio/hugo/tar.gz/refs/tags      && \
    URL="$BASE/v$VERSION"                                                && \
                                                                            \
    echo 'Downloading Hugo'                                              && \
    curl -fsSLo "$PACKAGE" "$URL"                                        && \
                                                                            \
    echo 'Checking package signature'                                    && \
    sha256sum "$PACKAGE"                                                 && \
    echo "$SHA  $PACKAGE" | sha256sum -c -                               && \
                                                                            \
    echo 'Extracting package'                                            && \
    mkdir -p /var/hugo                                                   && \
    tar -xzf "$PACKAGE" -C /var/hugo --strip-components=1                && \
    rm -rf "$PACKAGE"                                                    && \
                                                                            \
    echo 'Compile Hugo'                                                  && \
    cd /var/hugo                                                         && \
    CGO_ENABLED=1                                                           \
    GOPATH=/var/hugo/gopath                                                 \
    go build -v -o bin/hugo --tags extended -gcflags="-e"                && \
    mv bin/hugo /usr/local/bin/                                          && \
    rm -rf /var/hugo ~/.cache ~/go

# ------------------------------------------------------------------------------
# Execution

CMD ["/usr/local/bin/hugo"]

NOTE: this significantly increase the build time and size of the resulting image compared to downloading the precompiled package on top of an alpine base. @bep It would be great if this bug was fixed.

[bep]

I assume it's the Go 1.20 changes mentioned here that breaks this:
https://tip.golang.org/doc/go1.20#cgo

I'm guessing that Go bundled these C libraries into Go in <= 1.19.

[harrtho]

I was able to solve the problem with libresolv.so.2 in an alpine image with the help of this post: Configuring adminer for Oracle Databases

...
apk add --no-cache \
    gcompat \
    libc6-compat \
    ... && \
    ln -s /lib/libc.so.6 /usr/lib/libresolv.so.2
...

[gymnae]

I was able to solve the problem with libresolv.so.2 in an alpine image with the help of this post: Configuring adminer for Oracle Databases

...
apk add --no-cache \
    gcompat \
    libc6-compat \
    ... && \
    ln -s /lib/libc.so.6 /usr/lib/libresolv.so.2
...

Perfect, that fixed it for me, thank you

[renehamburger]

I couldn't get this to work, even with @harrtho's helpful suggestion. I ended up installing the Alpine hugo package directly and replaced the binary:

RUN apk update && \
  apk add --no-cache hugo && \
  rm ./node_modules/hugo-bin/vendor/hugo && \
  ln -s /usr/bin/hugo ./node_modules/hugo-bin/vendor/hugo

[jfp42]

Also needed the libstdc++, so
...
apk add --no-cache
gcompat
libc6-compat
libstdc++
... &&
ln -s /lib/libc.so.6 /usr/lib/libresolv.so.2
...

[sdwolfz]

@bep This issue is still present in the 0.112.0 version of the build artefacts.

Have you not added -extldflags "-static" in the build? or are you not going to? From the golang/go#59304 (comment) response I understand that's the expected behaviour and what the golang developers expect you to do.

Up to you what approach you take, just note we would love to have a downloadable extended executable for alpine.

[cyw3]

Also needed the libstdc++, so ... apk add --no-cache gcompat libc6-compat libstdc++ ... && ln -s /lib/libc.so.6 /usr/lib/libresolv.so.2 ...

I also meet this problem. After following your repair steps, it was not successful and another error message appeared:

Segmentation fault (core dumped)

[zabatonni]

I'm using my own gitlab.ci script like this, with Hugo version 0.119.
I haven't tested latest version yet, as I didn't update any of my auto-deploying websites.

image: alpine:latest

before_script:
- apk add --update tzdata rsync openssh gcompat libc6-compat libstdc++
- wget -O /tmp/hugo.tar.gz https://github.com/gohugoio/hugo/releases/download/v0.119.0/hugo_extended_0.119.0_Linux-64bit.tar.gz
- tar -xf /tmp/hugo.tar.gz -C /tmp/
- mv /tmp/hugo /usr/bin/hugo
- hugo version

[jmooring]

The current title of this issue, "Hugo extended cannot run in Alpine", is not accurate.

See https://gohugo.io/installation/linux/#alpine-linux for installation instructions. The community package repo is updated regularly.