Hello,
it is not possible to use the hugo binary file in the current release on CentOS due to missing support.
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
....
GLIBCXX_3.4.19
Hugo seems to be needing GLIBCXX >= 3.4.20
I'm not especially familiar with CentOS, but can you not update the version of libstdc++?
Wanted to chime in as well. I'm running the latest version of CentOS 7 and am hitting this issue.
Based on the reading I've done, while it is technically possible to update the version of libstdc++, there isn't an official way to do so. It requires manually pulling down the files and swapping them in.
Additionally, the CentOS devs have no intention of ever updating the included version of libstdc++ for this version of CentOS.
CentOS offers stability and it does not support newer libraries officially for this reason.
This issue is CentOS specific. I honestly don't see what can be done here from the Hugo side.
This issue is CentOS specific. I honestly don't see what can be done here from the Hugo side.
We certainly control the versions which we compile Hugo with, but it's a slippery slope. One motivation behind the dynamic linking of glibc is security (allow people to patch their system with one lib instead of ... thousands) -- and being too far behind the "current" does not sound optimal.
Also note that CentOS people can compile it from source if they really want this.
@bep I agree with you. The only real goal i want to achieve with this request, would be a little side note for CentOS users to compile the newest version of Hugo themselves.
Ok. Sure they can compile it but not officially and they better know what they're doing because otherwise their installation will break. (But since this is CentOS we're talking about I suppose that this is a non issue since it is an OS for people who know what they're doing.)
Anyway since @kaushalmodi has been assigned to add a note in the Docs about the glibc version, maybe it should also be mentioned that this applies only to the Hugo Extended version since that is the version with the glibc dynamically linked for the SCSS/SASS ToCSS transformation.
I suppose that the Basic version of Hugo continues to run just fine on CentOS 7.
P.S. On a slightly unrelated note modern browsers support pure CSS variables (there is no support for mixins yet, but these will be supported at some point natively)
@bep This is correct. The extended version from the release will not run on OS with glibc older than 2.14.
I am on RHEL 6.8 (which I believe is close to CentOS 7) and get this error when I download hugo_extended 0.48, extract it to current dir, and run ./hugo version:
./hugo: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./hugo)
The glibc version on RHEL 6.8 is 2.12. You can find that version by running ldd --version. I get:
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
@RealOrangeOne
I'm not especially familiar with CentOS, but can you not update the version of libstdc++?
It's not that easy (I have spent many hours doing that). There are a lot of dependencies that need to be installed to upgrade glibc, and you cannot do that on work machines where you don't have sudo rights. Usually work machines use such old and stable GNU/Linux OSes.
@onedrawingperday
I honestly don't see what can be done here from the Hugo side.
Yes, it's not Hugo's responsibility. But a note should be put that the extended version will only run on GNU/Linux OSes with glibc >= 2.14.
Or.. If that binary is built on a RHEL 6.8/CentOS 7 system that has glibc 2.12. That will reduce the min required glibc version to 2.14.
@tosoikea @colincwilliams If you still need a hugo extended binary (it's really easy to build it locally though), I can provide you an unofficial build built on my system.
Anyway since @kaushalmodi has been assigned to add a note in the Docs about the glibc version
I don't think that note should go in Docs; no one will find them there.
The right place would be to update the script that @bep uses to create the Releases ..
Put a Note: section at the end that says that the hugo_extended_*_Linux_* binaries will only run on GNU/Linux OSes with glibc >= 2.14. To find the current glibc version, do ldd --version.
It can be added that the user is suggested to build hugo extended themselves on such OSes.
@kaushalmodi Thanks for the offer. I've just opted to use the standard version for now, particularly since it has the additional benefit of being in a maintained EPEL repository. The desire to use Hugo extended was purely lazy convenience, not necessity.
I did try to build the extended version myself on CentOS, though, and ran into some problems, but I won't get into those here since that's quite off topic. :)
I did try to build the extended version myself on CentOS, though, and ran into some problems
I am curious to know the problem. I you like, let's continue the discussion on https://discourse.gohugo.io/.
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
Most helpful comment
We certainly control the versions which we compile Hugo with, but it's a slippery slope. One motivation behind the dynamic linking of
glibcis security (allow people to patch their system with one lib instead of ... thousands) -- and being too far behind the "current" does not sound optimal.Also note that
CentOSpeople can compile it from source if they really want this.