libstdc++.so.6: version `GLIBCXX_3.4.20' not found

[astrojuanlu]

Originally reported by @CFBaptista, see output here.

Apparently the program is trying to use system boost, which makes no sense. Could you try instant clean inside the environment an try again the example, just in case?

Also, please try this command, the important one:

$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

[astrojuanlu]

For reference: reported at #24 (comment)

[ghost]

I tried running the demo again after trying instant-clean inside the environment as you proposed: no joy. In this gist you can find the output of

$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

[astrojuanlu]

I get the same error on my system (I also use Arch Linux). I am a bit lost now, since according to that output the stated version of GLIBCXX is indeed available. Investigating...

[astrojuanlu]

I don't understand why it is considering system boost first, and that might actually be the source of the problem:

$ strings ~/.miniconda3/envs/fenics_test/lib/libstdc++.so.6 | grep GLIBCXX
LIBCXX
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_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

FEniCS is trying to use conda libstdc++, but system boost. I don't know why yet.

[astrojuanlu]

This problem has deeper implications, see also #36 reported by @e-aranda. While it would be important to know why the program is choosing the wrong boost lib, the libstdc++ provided by conda is too old and will probably lead to further problems. I might have to revert the changes - they were made to increase portability, but had the opposite effect.

[ghost]

Hi @Juanlu001 what is the current status of this issue?

[astrojuanlu]

Hi @CFBaptista, I have some half-backed recipes on the portability branch but I'm still seeing compilation errors at the end of the process (see ContinuumIO/anaconda-issues#483 (comment) and ping @ccordoba12). I cannot push proper packages until I solve that, or find it's not solvable and roll back.

[astrojuanlu]

@CFBaptista I just uploaded new packages to my Anaconda channel, would you please try those and tell me if they work? They don't have VTK support though, which is what complicates portability. I'm closing this issue, feel free to reopen if something goes wrong or open a new one.

[ghost]

Hi @Juanlu001, it is still not working for me :( I removed the fenics27 environment and reinstalled. After running the same demo as before I get this error.

[astrojuanlu]

Could you try instant clean again? I will try to reproduce in my system.

[ghost]

The output for running the demo after issuing instant-clean can be found in the file named fenics_demo_after_instant_clean here. It is still picking up boost from /usr/lib instead of from ~/.anaconda3/envs/fenics27/lib. I tried everything a new after adding ~/.anaconda3/envs/fenics27/lib to LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=/home/user/.anaconda3/envs/fenics27/lib:$LD_LIBRARY_PATH

but that also doesn't work. The corresponding output can be found in the file named fenics_demo_after_adding_env_to_LD_LIBRARY_PATH

[astrojuanlu]

I instructed DOLFIN to pick up the right libboost_filesystem library in the build script (see https://github.com/Juanlu001/fenics-recipes/blob/d81196de91b7f7fe3cb9825d1ef5e6b727063a8b/dolfin/build.sh#L26). I have a hint of what might be happening though.

$  ldd ~/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/_common.so  | grep boost
ldd: warning: you do not have execution permission for `/home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/_common.so'
    libboost_filesystem.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../../libboost_filesystem.so.1.57.0 (0x00007f3998095000)
    libboost_program_options.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../../libboost_program_options.so.1.57.0 (0x00007f3997e30000)
    libboost_system.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../../libboost_system.so.1.57.0 (0x00007f3997c2c000)
    libboost_thread.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../../libboost_thread.so.1.57.0 (0x00007f3997a08000)
    libboost_iostreams.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../../libboost_iostreams.so.1.57.0 (0x00007f39977df000)
    libboost_timer.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../../libboost_timer.so.1.57.0 (0x00007f39975db000)
    libboost_chrono.so.1.57.0 => /home/juanlu/.miniconda3/envs/fenics_test/lib/python2.7/site-packages/dolfin/cpp/../../../.././libboost_chrono.so.1.57.0 (0x00007f39922bc000)

whereas:

$ ldd ~/.instant/cache/dolfin_compile_code_c8b988ab6016262c9eebd6dc8482b98c0cf05c33/_dolfin_compile_code_c8b988ab6016262c9eebd6dc8482b98c0cf05c33.so  | grep boost
    libboost_filesystem.so.1.58.0 => /usr/lib/libboost_filesystem.so.1.58.0 (0x00007f2dc0b44000)
    libboost_program_options.so.1.58.0 => /usr/lib/libboost_program_options.so.1.58.0 (0x00007f2dc08c6000)
    libboost_system.so.1.58.0 => /usr/lib/libboost_system.so.1.58.0 (0x00007f2dc06c2000)
    libboost_thread.so.1.58.0 => /usr/lib/libboost_thread.so.1.58.0 (0x00007f2dc049a000)
    libboost_iostreams.so.1.58.0 => /usr/lib/libboost_iostreams.so.1.58.0 (0x00007f2dc0282000)
    libboost_timer.so.1.58.0 => /usr/lib/libboost_timer.so.1.58.0 (0x00007f2dc007d000)
    libboost_chrono.so.1.58.0 => /usr/lib/libboost_chrono.so.1.58.0 (0x00007f2dbce55000)

This means that the error is probably in instant, since it's generating extension modules which are linked to the wrong libraries. This is still a bug, I'll have to investigate.

[astrojuanlu]

I suspect it's either a) my fault when building instant, since I don't see how to specify which library directories to use by default or b) FEniCS devs fault if there's no way to do it. I need to ask in the mailing list. I can imagine ugly ways of fixing this but haven't tested them yet, expect a nasty patch tomorrow but probably I will need some time to implement a proper solution.

[ghost]

Thanks @Juanlu001 for all your efforts!

[ghost]

Hi @Juanlu001 has there been any progress on this issue? Is a newly installed FEniCS platform via your conda channel usable at the moment?

[dajuno]

Doesn't look like it, I just tried it and get the same error.

[mthewissen]

Having the same problem with boost. Since my error message looks more similar to issue #24, I added the comment there. Any progress on this issue?

[mthewissen]

Not sure how much it is related to this problem, but I also had a wrong version for boost (and some other perhaps-related perhaps-not problems) on an older system, and after some trial-and-error the following seems to work for me (version 1.4):

conda install dolfin=1.4.0 boost=1.55 eigen3 ffc petsc petsc4py instant swig=3.0.2 ufl fiat vtk=5.10 fenics=1.4.0 mkl scientificpython --channel https://conda.binstar.org/juanlu001/channel/fenics:1.4.0:centos

It seems it helped to install everything together with one command, specifying the correct versions.

[astrojuanlu]

Just to provide some information of the status of this issue: FEniCS devs gave me some hints on how to fix it, but ultimately I'm expected to send a patch.

https://www.mail-archive.com/fenics-support%40fenicsproject.org/msg01797.html

Debugging CMake logs and 1-hour-long compilations are probably the most frustrating and painful things I've ever done and I have other deadlines now, so I cannot promise I will deliver a fix in the near future (1-2 months).

Regarding FEniCS 1.4, I'm glad it worked but it's cumbersome to have two separate channels (and according to @mthewissen input, it often fails), so I'll try my best to make

$ conda install fenics --channel juanlu001

and

$ conda install fenics=1.4.0 --channel juanlu001

just work.

[astrojuanlu]

Regarding the instant/DOLFIN mismatch, I'll try to see if modifying LDFLAGS somewhere helps, as seen in http://stackoverflow.com/a/7619133/554319.

[mikaem]

Hi

I just ran into the same error message. Seems to be because my conda gcc is version 4.8.5, whereas my ubuntu gcc is 4.9.2. The unit test is picking up the ubuntu libcppunit.so library and conflicts arise. A solution is simply to disable the unit tests. That is, put

-DDOLFIN_ENABLE_UNIT_TESTS:BOOL=FALSE

in dolfins build.sh.

[astrojuanlu]

Thanks a lot for your comment @mikaem. It's sad to see that using conda gcc fixed some problems but brought many others.

[mikaem]

Yes. One needs to be extra careful not to pick up the wrong libraries and to make sure the correct (conda) versions are used. I also had an issue with Petsc using mpif90 that picked up f95, which is not defined in conda and as such the ubuntu version was picked up instead and I got an error trying to compile Slepc (error in trying to link to petscksp.mod). In Slepc yaml you had a fix though (ln -s $PREFIX/bin/gfortran $PREFIX/bin/f95), and I recompiled Petsc using that link and it picked up the right version. So now I simply have this soft link permanently installed.