The conda-forge C++ compiler was updated recently, and this got used when building the latest 2020.09.3 release yesterday: https://github.com/conda-forge/rdkit-feedstock/pull/62/files <https://github.com/conda-forge/rdkit-feedstock/pull/62/files>
It looks to me like the system libstdc++ is being loaded from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 instead of the one provided by conda at /usr/local/lib/libstdc++.so.6 (I think). I wonder if this has always been the case, but the versions were compatible so it went unnoticed until now? As you point out in the notebook, you can pin RDKit to the previous version as a quick fix, but obviously this isn’t a great solution long term. I don’t know if it might be possible to change LD_LIBRARY_PATH in an already running notebook? This is a bit of an unusual situation given the way miniconda is installed into an already running notebook process and just added to sys.path… It might not be possible to control how native libraries are loaded. Matt > On 14 Dec 2020, at 14:08, Jan Halborg Jensen <jhjen...@chem.ku.dk> wrote: > > My conda install script in Colab > https://colab.research.google.com/drive/1cAuW02_9r3wFylijGP8rvOUa1-omVwpP?usp=sharing > > <https://colab.research.google.com/drive/1cAuW02_9r3wFylijGP8rvOUa1-omVwpP?usp=sharing> > stopped working with the last 1-2 days. > > I now get the following error > > ImportError: > /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found > (required by > /usr/local/lib/python3.7/site-packages/rdkit/DataStructs/cDataStructs.so > > Any tips or suggestions are appreciated > > Best regards, Jan > > > > _______________________________________________ > Rdkit-discuss mailing list > Rdkit-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
_______________________________________________ Rdkit-discuss mailing list Rdkit-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
