When attempting to run a new hugo build, it seems we are missing some dependencies:
6:20:18 PM: Executing user command: ./hugo --config paceup.com.toml,config.toml
6:20:18 PM: ./hugo: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./hugo)
6:20:18 PM: ./hugo: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./hugo)
We need to install whatever is needed here :)
Should notify these customers in our helpdesk:
Untill then it’s hard to mention Netlify (let alone use it) alongside Hugo Pipes... too bad because speeding up deployement is among the big pros 😔
@regisphilibert for now you have to commit generated resourcesas @bep shows on https://hugoscss.netlify.com/ 😲
@DirtyF this repo commits its resources directory. For me tt’s really not ideal if the assets can be edited by an editor.
@regisphilibert my understanding is commiting the resources folder is only a workaround solution whilst this PR has not landed. Once it is the case, I think Hugo resources.ToCSS will work as expected.
Is that correct?
Hi @oncletom, let's take this here: https://discourse.gohugo.io/t/netlify-and-hugo-pipes/13145
Appears it was intended to be a dynamically linked binary: https://github.com/gohugoio/hugo/issues/4985
this doesn't work still for hugo 0.46
what is the best thread for tracking this issue and netlify using the extended version?
@jensamunch This issue is tracking it.
hugo 0.46 works well for me - just can't use the extended version, right @jensamunch ?
I did not fully grasp _why_ installing this specific version of libstdc++ solves the problem but this message on Hugo forums explains how to install a version of libstdc++ which is picked up by Hugo and works with the extended build: https://discourse.gohugo.io/t/solved-hugo-v44-extended-and-relocation-errors-on-travis/13029/5
Ping for visibility. As of Hugo 0.47.1, extended still won't work on Netlify due to two reasons:
To those looking for a workaround until this is fixed:
Run hugo locally with the extended version, then check in your resources/_gen/assets directory to the repository so that Hugo skips trying to generate the assets.
I installed hugo through snap and a recent version (0.47.1) works well for me.
$ snap list
Name Version Rev Tracking Publisher Notes
core 16-2.35 5328 stable canonical* core
hugo 0.47.1 2590 stable hugo-authors -
Fast workaround for Hugo extended version.
package.json
{
// ...
"scripts": {
"build": "NF_IMAGE_VERSION=1 bash ./netlify-build-fix.sh && LD_LIBRARY_PATH=$(pwd)/tmp/usr/lib/x86_64-linux-gnu $(pwd)/tmp/usr/local/bin/hugo",
// ...
},
// ...
}
netlify-build-fix.sh
#!/bin/bash
HUGO_FLAVOUR="hugo_extended"
HUGO_VERSION="0.48"
[ -z "${NF_IMAGE_VERSION}" ] && exit 0
rm -fr *.deb
wget --no-clobber http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.10_amd64.deb || exit 1
wget --no-clobber https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/${HUGO_FLAVOUR}_${HUGO_VERSION}_Linux-64bit.deb || exit 1
grep "hugo=" ~/.bashrc || echo "alias hugo='LD_LIBRARY_PATH=$(pwd)/tmp/usr/lib/x86_64-linux-gnu $(pwd)/tmp/usr/local/bin/hugo'" >> ~/.bashrc
find -name '*.deb' -exec dpkg -x {} $(pwd)/tmp \;
rm -fr *.deb
exit 0
Doing ldd --version in a Netlify script gets this:
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.13) 2.19
12:28:30 AM: Copyright (C) 2014 Free Software Foundation, Inc.
12:28:30 AM: This is free software; see the source for copying conditions. There is NO
12:28:30 AM: warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
12:28:30 AM: Written by Roland McGrath and Ulrich Drepper.
This is a Ubuntu from 4 years+ ago. Debian and Ubuntu have since moved from EGLIBC to GLIBC -- which should work fine with the extended Hugo version. If not, let me know and I will look into it quickly from the Hugo side of it.
/cc @biilmann
Yup, we're still running Ubuntu 14.04 LTS in the build environment. in 8
months or so it will end of life, and we'll move before then. We don't
expect you to tailor things for it in the meantime, @bep! It's just a
challenge to move our hundreds of thousands of customers without breaking
many builds so we're working on a smoother way to do that and that's taking
awhile.
On Fri, Sep 14, 2018 at 3:51 PM Bjørn Erik Pedersen <
[email protected]> wrote:
Doing ldd --version in a Netlify script gets this:
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.13) 2.19
12:28:30 AM: Copyright (C) 2014 Free Software Foundation, Inc.
12:28:30 AM: This is free software; see the source for copying conditions. There is NO
12:28:30 AM: warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
12:28:30 AM: Written by Roland McGrath and Ulrich Drepper.This is a Ubuntu from 4 years+ ago. Debian and Ubuntu have since moved
from EGLIBC to GLIBC -- which should work fine with the extended Hugo
version. If not, let me know and I will look into it quickly from the Hugo
side of it./cc @biilmann https://github.com/biilmann
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/netlify/build-image/issues/183#issuecomment-421504191,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN-oIGS-7-Ca88mdpy7wLS1Uotw-HuYks5ubDLZgaJpZM4VJ7mF
.
To summarize the currently available workarounds:
Since this is solved in the xenial image and isn't easily solvable in the trusty image, I'm going to close this issue. We should have that image out to everyone soonish.
@bcomnes surely that means this issue is still valid? It's not actually solved until the xenial-based image has shipped
@baublet you have writtern
To those looking for a workaround until this is fixed:
Run
hugolocally with the extended version, then check in yourresources/_gen/assetsdirectory to the repository so that Hugo skips trying to generate the assets.
I'm a newbie: what's the menaning of "check in your resources/_gen/assets directory to the repository so that Hugo skips trying to generate the assets". What I must set in my repo and in netlify?
Thank you
I'm a newbie: what's the menaning of "check in your
resources/_gen/assets
Hugo will not "generate" resources if they are found in resources/_gen/assets. So make sure the resources/_gen/assets is indexed by git. Then build your sass resources locally (running hugo), commit resources change and push.
This does mean you need to run hugo locally when changing your scss file.
There's nothing to do on Netlify's hand.
@RealOrangeOne the issue, from the perspective of this issue tracker, is closed, in that the work needed to get the code working in this repo on master is completed, and all available workarounds we can add to a 14.04 image thats currently deployed publicly.
Again, apologies for this taking so long to get out, we are currently working on infrastructure that will dramatically increase the update cadence for build-images.
When it is shipped, we will be publicly announcing it on our blog and twitter. If you want super duper early access, I can arrange that as well.
This also seems to be happening for anyone who tries to use the nodegit package as part of their build command:
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /opt/build/repo/node_modules/nodegit/build/Release/nodegit. node)
I just checked in on this again, and found that the Xenial image is available for use. I didn't see any mention of it here so I figured I'd leave a comment.
Sass compilation worked fine for me after changing the build image!
I can confirm. I switched to the build image to Ubuntu Xenial 16.04 (default) and was able to successfully build and hugo with sass/scss on netlify…

Updated the build image selection like @beausmith and netlify.toml with the content from hugo website and now it's back online :)
Most helpful comment
Fast workaround for Hugo extended version.
package.json
netlify-build-fix.sh