Using the precompiled crystal-0.23.0-1-linux-x86_64.tar.gz, I've the following error:
usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
Indeed my GLIBCXX is older:
$ strings /lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH
What OS are you on? You might have to try and find a backports package or build a newer version yourself.
I should mention that this ticket was created because of @mverzilli's comment on:
0.23 changelog. I worked around this by compiling from source.
@need47 What's your OS?
@straight-shoota @ysbaddaden reported Ubuntu 14.04 (trusty) in https://github.com/crystal-lang/crystal/commit/3c3d3e2b830e81de0aa39b7af0cd6f82f759c410#commitcomment-22855250
in my case: CentOS 7.3.1611 (64 bit)
This error also seems to happen inside the heroku buildpack when used with dokku.
The package was built using Debian 8 (see crystal-lang/omnibus-crystal#17 for more info), so Ubuntu 14.04 was dropped too - but Crystal works both on Ubuntu 16.04 and Debian 8.
Feel free to jump into omnibus-crystal to help sort this issues out, but all of this is (as far as I know) a side-effect of dropping LLVM 3.5 in favor of 3.8
I don't doubt the need for updating LLVM, I'm just caught between dokku being behind herouku - https://github.com/gliderlabs/herokuish/issues/256 and crystal needing at least ubuntu16 on this release.
Ubuntu 14.04 doesn't have the "LLVM requires a newer libstdc++ than distributed". It's now even distributing LLVM 3.9.1, along with LLVM 3.8 (official packages).
This is my own fault for sticking to 14.04 —I refuse to upgrade to a systemd-based distribution — but dropping a working distribution along with older releases (that break because libstdc++
) feels a little harsh.
Changing the stdc++
definition in LibLLVM to the following suffices to link it statically (which could be automated with a static
named argument, for example Link("stdc++", static: true)
). That being said, it may not be sufficient —maybe we'll have issues with tinfo
or libc
since they could be older than what Debian 8 ships.
@[Link(ldflags: "-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic")]
lib libLLVM
end
I'm hitting this issue on my Travis builds. Example Travis failure in https://travis-ci.org/Fryguy/cargo_shorts/builds/250606812 . This was already opened in the Travis repo as https://github.com/travis-ci/travis-ci/issues/8005 .
Hi @Fryguy, thanks for reporting. We're working on Crystal 0.23 packages for Ubuntu 12 and Ubuntu 14, which should resolve this.
Would you mind trying this .deb's?
crystal_0.23.1-1_amd64.deb
crystal_0.23.1-1_i386.deb
crystal-0.23.1-1.el6.x86_64.rpm
crystal-0.23.1-1.el6.i386.rpm
crystal-0.23.1-1.pkg
I think they'll fix things in older Debian/Ubuntu's, and Centos. ~Centos links on the way.~
(The debs are not signed, I know)
Update: all links published now
FYI, all packages published here. Please test & inform, and we'll release during the week 👍
I tested the x86_64 .deb one using Docker, is it enough to crystal --version
to reproduce the bug ?
If yes, it seems to be fixed.
$ cat Dockerfile
# requires docker >= 17.05
ARG VERSION=12.04
FROM ubuntu:${VERSION}
RUN apt-get update && apt-get install -y apt-transport-https tzdata curl build-essential pkg-config libssl-dev llvm libedit-dev libgmp-dev libxml2-dev libyaml-dev libreadline-dev git-core
RUN curl -Ls https://www.dropbox.com/s/5p0zogk8basxcs8/crystal_0.23.1-1_amd64.deb?dl=0 > /tmp/crystal.deb && dpkg -i /tmp/crystal.deb
CMD grep DESCRIPTION /etc/lsb-release && crystal --version
$ docker run --rm $(docker build -q --build-arg VERSION=12.04 .)
DISTRIB_DESCRIPTION="Ubuntu 12.04.5 LTS"
Crystal 0.23.0+8 [e2a1389] (2017-07-08) LLVM 3.8.1
$ docker run --rm $(docker build -q --build-arg VERSION=14.04 .)
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
Crystal 0.23.0+8 [e2a1389] (2017-07-08) LLVM 3.8.1
$ docker run --rm $(docker build -q --build-arg VERSION=16.04 .)
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
Crystal 0.23.0+8 [e2a1389] (2017-07-08) LLVM 3.8.1
That's the first test to do.
If you want to test it further (like, running the specs of any project
you're working on), that helps too.
We definitely want to create a testing/beta distribution channel.
I've built my app using the above package (crystal_0.23.1-1_amd64.deb) inside an herkou buildpack. I get this error
remote: crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
The buildpack normally pulls the binaries from github. I disabled that, and added the deb via the dokku plugin - https://github.com/F4-Group/dokku-apt
@crisward looks like a very different issue at first glance, possibly reproducible with the same compiler and llvm version regardless of omnibus or not.
just done it again, but removed the --release flag and it worked.
We definitely want to create a testing/beta distribution channel.
Would it be possible to set up a test travis repo with a dummy app that can just verify that everything works end-to-end on Travis (perhaps all flavors of OS on Travis)? Something like that would have caught both the GPG key problem and this problem. I'm not exactly how it should work, just throwing the idea out there.
Perhaps a well used app that has tests eg.kemal.
Pretty sure node does this with express
I get the exact same error as @crisward when compiling even a hello world from crystal_0.23.1-1_amd64.deb
with --release
flag. I'm on Ubuntu in Windows (Ubuntu 14.0.4.5 LTS).
With Crystal 0.23.0 on Ubuntu 16.04.1 LTS it compiles. So it is likely an issue with the release or statically linked glibc++.
This is an assertion error from inside LLVM, likely to be well away from any library boundary. I think this needs more investigation.
Also seeing the same error as @crisward (LLVM LexicalScope error) trying to build with --release
flag in phusion/baseimage
docker container.
Also ubuntu:16.04
container
This should be fixed with release 0.23.1
. Try to update the package with sudo apt-get update && sudo apt-get install crystal
.
If it still fails, please report the output of crystal --version
and aptitude show crystal
.
Update: It is actually not fixed 👎:/ I ran into the error again with package release 0.23.1-3
in Ubuntu on Windows (Ubuntu 14.0.4.5 LTS) as before. It just failed much later in the build process, that's why assumed it was fixed.
Also the heroku buildpack needs a -1
in the version number not -3
. So that is also broke with the most recent version.
https://github.com/crystal-lang/heroku-buildpack-crystal/blob/master/bin/compile#L50
I can also confirm, I'm still getting the error when pushing with --release.
remote: crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
So the package is still broken, but its a different issue now? I find this error weird, it seems to point to an error in llvm itself...
I am also getting the same LLVM assertion error that crisward is getting, but when building my project using the --release
flag. When building without the release flag things seem to work. Maybe it has to do with the release flag actually, and not that crystal is attempting to build crystal?
file.hak8or.comcrystal:master λ crystal build --release src/browser.cr
crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/home/hak8or/development/crystal/toolchain/crystal-0.23.1-3/bin/crystal: line 102: 25326 Aborted (core dumped) "$INSTALL_DIR/embedded/bin/crystal" "$@"
file.hak8or.comcrystal:master λ crystal --version
Crystal 0.23.1 [e2a1389e8] (2017-07-13) LLVM 3.8.1
This is using the crystal from the most recent release here.
Hi all! Thanks for the follow ups.
It's really weird to see that /var/cache/omnibus/...
there, given that the Crystal package doesn't install that.
I _could_ repro the issue @hak8or describes, and could also workaround it by adding --no-debug
to the build command.
It's not a fix, though - so we should take a look at this. If someone wants to create an issue for that, it would be awesome 👍
Anyway, this issue was about the GLIBCXX version, and (I think) that is not happening anymore, right?
I can confirm that I no longer see the issue on Travis: https://travis-ci.org/Fryguy/cargo_shorts/builds/253385175
yep, me neither, travis's good.
I think this specific issue can now be closed in favour of #4719.
My travis tests are also passing. This is now a release flag only issue.
Most helpful comment
Would it be possible to set up a test travis repo with a dummy app that can just verify that everything works end-to-end on Travis (perhaps all flavors of OS on Travis)? Something like that would have caught both the GPG key problem and this problem. I'm not exactly how it should work, just throwing the idea out there.