-
Notifications
You must be signed in to change notification settings - Fork 226
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
libstdc++.so.6: version `GLIBCXX_3.4.20' not found #483
Comments
So is this a mismatch between our package and the one that comes in Arch/Ubuntu? I'm sorry but I don't completely understand the problem :-) |
I meant our |
Probably so @ccordoba12. The user that reported astrojuanlu/fenics-recipes#36 is now unable to use the packages when having This problem appeared when I started using Anaconda
As you can see, libGL is failing to load because a graphic cards driver requires a newer version of On Arch Linux a similar problem appears, but it's mixed with the fact that it's loading boost from the system instead of the one available in Anaconda. It's an unrelated issue (?) but it eventually causes the discussed one:
|
The anaconda If one of your packages is trying to find symbols from Looking at the FEniCS recipes, I notice a few issues. You should update all of your recipes to follow the rules below, at least when building C++ packages
For CMake-based projects, you can set these at configure time:
Finally, regarding glibc compatibility (not C++ compatibility): It's worth noting that the Anaconda maintainers build everything on CentOS 5.11. That way, the resulting binaries always run on newer versions of Linux. I do the same for my own packages. |
You should fix this by helping the (That's a little weird to me.) In my own recipes, I usually pass some cache variables to the cmake step, which are recognized by cmake's |
Thanks a lot for your advice @stuarteberg, it's very much appreciated. This was my first real world experience with compilers so a little bit of help is very valuable :) I will try and implement these changes in the following days. |
Let's talk about these specific issues elsewhere though. |
As an experiment, I wonder what happens if you manually replace the |
@Juanlu001, I'm afraid that even after following @stuarteberg advice you're going to keep having the same problems. And that's because Fenics is trying to load |
I agree with Carlos. I think your best option is to try the experiment I mentioned above, unless anyone has other ideas. |
I see. Actually visualization support via VTK is a major blocking point for building the packages on anaconda.org, so it seems I will have to devise some hack as @stuarteberg suggested before, or state that it is not portable at all. Thanks again for your input! |
I made our latest VTK package (6.3.0) to depend on a new Maybe that fixes your problems :-) |
That is music for my ears :) Will keep you posted with my progress. |
@ccordoba12 I have found that trying to compile against VTK 6 complains about missing |
Added compilers and boost explicit paths, using new version of VTK which depends on mesa (see ContinuumIO/anaconda-issues#483 (comment))
Hi, not sure if relevant ... but i just built a debian package for a software library on debian jessie (it was a clean installation using gcc from the jessie repository). After installing the deb on an other debian jessie os but that uses anaconda as python distribution. Running the software everything works fine except for some part of its python c/wrapper library (it uses cython), the error is reported here:
this means that also if the deb was built on a clean machine, its python-cython code when invoced .. tries to use conda gcc? I've gcc installed in both apt-get and conda ... will an up-to-date installation of conda gcc fix this ? is there a recipe for a newer gcc ? |
I'm closing this issue since it is a mixture of portability problems and something that doesn't quite work with VTK/mesa. Since I think I solved the former, I'm closing this and will try to investigate further the latter. |
Thanks for letting us know about it. |
auditwheel thinks this is valid, but auditwheel is wrong:
Those GLIBC symbols > 2.5 mean that it's not compatible with centOS 5, and thus should not be a valid manylinux wheel under the
qualification (https://www.python.org/dev/peps/pep-0513/) I don't know why auditwheel permits those symbols. |
Further, compatibility with CentOS 5 is dubious for GPU support, as the past couple of versions of have dropped CentOS5 support. The oldest linux distro I know of that they still support is SLES 11 (glibc 2.11) |
Thanks for the info about |
Had the same problem today building tensorflow ubuntu16, got
resolved by
|
I needed to uninstall and install libgcc again.
|
conda uninstall gcc saved me |
I tried pitybea's solution and it worked. I'm on aws using the dlami image (ami-c27af5ba) For the 3 thumbsdowners maybe take a look at what I have installed maybe that helps:
|
Just a note - I received this error when using dlib. It was being thrown by the system's libstdc++.so.6 file, even though I had |
I have been testing the latest gcc package from Anaconda which should fix several portability issues (conda-archive/conda-recipes#279, thanks to @stuarteberg) for building my conda recipes for FEniCS. However, I am having some problems (at least on Arch Linux and Ubuntu 14.04) where some library calls fail with this error:
libstdc++.so.6: version
GLIBCXX_3.4.20' not found`Which happens because Anaconda libstdc++.so.6 is a bit too old:
(see for instance astrojuanlu/fenics-recipes#35 and astrojuanlu/fenics-recipes#36)
Is there a way to have a newer version of the library coming with conda? cc @ccordoba12
The text was updated successfully, but these errors were encountered: