Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hugo binary no longer statically linked on Linux (starting 0.20.3) #3382

Closed
munnerz opened this issue Apr 24, 2017 · 11 comments · Fixed by #3384
Closed

Hugo binary no longer statically linked on Linux (starting 0.20.3) #3382

munnerz opened this issue Apr 24, 2017 · 11 comments · Fixed by #3384

Comments

@munnerz
Copy link
Contributor

munnerz commented Apr 24, 2017

Hi there

Since version 0.20.3, it appears the Hugo binary is no longer being statically linked.

This means when running Hugo within an alpine container, 'no such file or directory' is output (because the linked libraries are not present). I'm assuming this is to do with the transition to using goreleaser, as part of this issue: #3358

From a quick glance, it looks like goreleaser allows us to specify ld flags. etc for use when building, so this should be possible!

Thanks

@bep bep added the Bug label Apr 24, 2017
@bep
Copy link
Member

bep commented Apr 24, 2017

From a quick glance, it looks like goreleaser allows us to specify ld flags. etc for use when building, so this should be possible!

It would be even better if you could provide me with the correct ld flags/or a reference.

@munnerz
Copy link
Contributor Author

munnerz commented Apr 24, 2017

@bep I've put in a pull request with #3384!

@bep
Copy link
Member

bep commented Apr 24, 2017

Thanks; I will check to see how Goxc handle this (which is what we replaced), to make sure I don't introduce even more mess.

@bep
Copy link
Member

bep commented Apr 24, 2017

Note to self:

New vs old Linux:

ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped
ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically linked, not stripped

@bep bep closed this as completed in #3384 Apr 24, 2017
bep pushed a commit that referenced this issue Apr 24, 2017
In Hugo 0.20.3, the released binaries for Linux was no longer statically linked. This commit fixes that.

Fixes #3382
@bep bep reopened this Apr 24, 2017
@bep
Copy link
Member

bep commented Apr 24, 2017

I have released a new version, but I had to reopen this issue. A build on Linux still shows up as dynamically linked, so I built it on macOS, where everything is fine. We have to check into this some more.

@bep
Copy link
Member

bep commented Apr 25, 2017

So this works by doing it directly:

go build -ldflags '-s -w -linkmode external -extldflags "-static"'
 file ./hugo
./hugo: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=38440bf812b499ce299409c4bb9c2042ff24f20c, stripped

I assume Goreleaser is doing some funky stuff ...

@caarlos0
Copy link
Contributor

I assume Goreleaser is doing some funky stuff ...

my bad, docs were inducing to error. Sorry. Thanks @bep for for the PR :)

@dettmering
Copy link

@bep this now appears to happen with the extended version of hugo that includes SASS processing.

I can't run hugo extended on alpine anymore. The non-extended version works perfectly, though.

@SR-G
Copy link

SR-G commented Aug 5, 2018

Same for me - this seems to be "by design choice" (as per said in other issues), but i would then need the list of expected dependencies (was not able to find that anywhere, neigher here or on the forum, if someone has the detailled informations related to this topic, thanks for providing them).

@dettmering
Copy link

I found a workaround by installing glibc: https://github.com/dettmering/hugo-build/blob/master/Dockerfile

Maybe this helps.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants