Taichi: [PyPI] install with pip, libtinfo.so.5 not found
Describe the bug
I installed taichi using pip install --user taichi.
Log/Screenshots
[bate@archit gpu]$ pydoc taichi.GUI.is_pressed
[Taichi] mode=release
Share object taichi_core import failed. If you are on Windows, please consider installing "Microsoft Visual C++ Redistributable" (https://aka.ms/vs/16/release/vc_redist.x64.exe)
problem in taichi - ImportError: libtinfo.so.5: cannot open shared object file: No such file or directory
To Reproduce
A linux environment without libtinfo5, then python -c 'import taichi'.
If you have local commits (e.g. compile fixes before you reproduce the bug), please make sure you first make a PR to fix the build errors and then report the bug.
See #790, I updated doc to tell them how to install, and ultimately we should remove this hard dep (#782)
archibate
All 25 comments
What does libtinfo5 does? Why we can remove libcuda's dep, and this can't?
archibate
on 15 Apr 2020
I have no idea on this. It seems to me that libtinfo5 is related to the GUI system (X11).
yuanming-hu
on 15 Apr 2020
I have no idea on this. It seems to me that libtinfo5 is related to the GUI system (X11).
It's a package related to ncurses, 是不是帮spdlog修改终端颜色的库？我们可以不要它。我们可以自己ANSI控制码。
archibate
on 15 Apr 2020
I'm not sure, but I believe you can figure out a solution on your own :-)
yuanming-hu
on 15 Apr 2020
I already figure out how to install this dep, but some users may not, I hope they could run taichi codes as soon as they run pip install taichi, rather than an ImportError.
archibate
on 15 Apr 2020
(master) [bate@archit taichi]$ readelf -s /usr/lib/libtinfo.so.5 | awk '{print $8}' | grep term
termname
_nc_init_termtype
_nc_copy_termtype
_nc_align_termtype
setupterm
_nc_setupterm
_nc_home_terminfo
termattrs
_nc_read_termtype
restartterm
_nc_check_termtype2
term_attrs
del_curterm
resize_term
set_curterm
_nc_free_termtype
resizeterm
is_term_resized
set_term
cur_term
_nc_read_termcap
newterm
(master) [bate@archit taichi]$ readelf -s build/libtaichi_core.so | awk '{print $8}' | grep -v _Z | grep -v LLVM | grep -v gl | grep term
set_curterm
del_curterm
setupterm
terminator.9283
terminate
__clang_call_terminate
set_curterm
del_curterm
setupterm
(master) [bate@archit taichi]$
It's alias of libcurses, I confirmed.
archibate
on 15 Apr 2020
Interesting. Does that mean there's an easy way to remove his dependency? If so that would be great!
yuanming-hu
on 15 Apr 2020
Even you don't know it's source? Well...I guess it's related to spdlog, it would be great if we could tweak this statically-linked.
archibate
on 15 Apr 2020
Clearly, now you know this dependency better than I do, so I'll trust your decision.
yuanming-hu
on 15 Apr 2020
话说readelf怎么用的来着，我们想知道一个符号在何处被调用。
archibate
on 15 Apr 2020
Even you don't know it's source? Well...I guess it's related to spdlog, it would be great if we could tweak this statically-linked.
spdlog seems to be header-only so I guess it should not introduce any dependency...
话说readelf怎么用的来着，我们想知道一个符号在何处被调用。
I'm not an expert on that...
yuanming-hu
on 15 Apr 2020
spdlog seems to be header-only so I guess it should not introduce any dependency...
But how could spdlog print colorful log like colorama does? Also catch.hpp can.
Have to sleep now, go back to solve this tmr.
See catch.hpp:6022, they use ANSI, no libtinfo.
archibate
on 15 Apr 2020
Thanks for the hard work - to be honest, I have no idea on that, but I believe you can figure out a nice solution in the end. Take care and don't sleep too late! :-)
yuanming-hu
on 15 Apr 2020
I found where it is!!!!!! We should use objdump, not readelf:
(804) [bate@archit taichi]$ objdump -D build/libtaichi_core.so | grep set_curterm
0000000000568620 <set_curterm@plt>:
568620: ff 25 ea 5c 9c 02 jmpq *0x29c5cea(%rip) # 2f2e310 <set_curterm>
e50a48: e8 d3 7b 71 ff callq 568620 <set_curterm@plt>
5685b6: 77 72 ja 56862a <set_curterm@plt+0xa>
5685e5: 74 3a je 568621 <set_curterm@plt+0x1>
5685bc: 36 64 65 74 61 ss fs gs je 568622 <set_curterm@plt+0x2>
5685b0: 73 74 jae 568626 <set_curterm@plt+0x6>
5685b8: 73 68 jae 568622 <set_curterm@plt+0x2>
5685ca: 70 61 jo 56862d <set_curterm@plt+0xd>
Cool - any clue which component of Taichi depends on this?
yuanming-hu
on 17 Apr 2020
which component of Taichi
Guess what? I goto that line, and found it is introduced by the LLVM function llvm::sys::Process::FileDescriptorHasColors:
0000000000e509a0 <_ZN4llvm3sys7Process23FileDescriptorHasColorsEi>:
...
e50a2b: e8 00 da 72 ff callq 57e430 <_ZN4llvm3sys9MutexImpl7releaseEv@plt>
e50a30: eb 95 jmp e509c7 <_ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x27>
e50a32: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
e50a38: 48 8d 3d d3 a8 4c 01 lea 0x14ca8d3(%rip),%rdi # 231b312 <_ZN4llvm3sys2fs12kInvalidFileE+0x26a>
e50a3f: e8 9c f5 71 ff callq 56ffe0 <tigetnum@plt>
e50a44: 31 ff xor %edi,%edi
e50a46: 89 c5 mov %eax,%ebp
e50a48: e8 d3 7b 71 ff callq 568620 <set_curterm@plt>
e50a4d: 48 89 c7 mov %rax,%rdi
e50a50: e8 2b 9a 71 ff callq 56a480 <del_curterm@plt>
e50a55: 4c 89 ef mov %r13,%rdi
e50a58: 85 ed test %ebp,%ebp
e50a5a: 7f 34 jg e50a90 <_ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0xf0>
e50a5c: e8 cf d9 72 ff callq 57e430 <_ZN4llvm3sys9MutexImpl7releaseEv@plt>
e50a61: 45 31 e4 xor %r12d,%r12d
e50a64: e9 5e ff ff ff jmpq e509c7 <_ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x27>
It detects FileColors...what on earth does a file has color...
archibate
on 17 Apr 2020
Thanks for the analysis!!
A few related discussions:
https://github.com/microsoft/vscode-cpptools/issues/3174#issuecomment-463692329
yuanming-hu
on 17 Apr 2020
A potentially very hacky fix: if on Linux, make a local symbolic link named libtinfo.6.so to /usr/lib/libtinfo5.so, in the same folder as libtaichi_core.so.
yuanming-hu
on 17 Apr 2020
A potentially very hacky fix: if on Linux, make a local symbolic link named
libtinfo.6.soto/usr/lib/libtinfo5.so, in the same folder aslibtaichi_core.so.
Sounds cool! I believe all users have libtinfo.6.so since it's part of ncurses :)
But ultimately can we specify some cmake arguments to make llvm not detecting-file-color? It's really ridiculous and taichi don't need that after all...
archibate
on 17 Apr 2020
But ultimately can we specify some cmake arguments to make llvm not detecting-file-color? It's really ridiculous and taichi don't need that after all...
Right, not sure how easy that is though... LLVM does seem to have a related cmake option.
We can do it while upgrading to LLVM 10 #655
yuanming-hu
on 17 Apr 2020
Ok, so we have to abandon LLVM 8 and 9 support now? Fine, just tell 8&9 users to manually do that symlink, not a big deal after all.
archibate
on 17 Apr 2020
I mean, when releasing the prebuilt LLVM 10 we simply disable LLVM_ENABLE_TERM_INFO. It's gonna take a while for us to migrate, so we have to do the symlink for now...
I have to run for a meeting - good night!
yuanming-hu
on 17 Apr 2020
You mean, we no longer build LLVM from scratch for 10? Good meeting!
archibate
on 17 Apr 2020
The best solution is to let LLVM go for libtinfo6, which is mostly installed by users.
archibate
on 18 Apr 2020
Why is the released version linking libtinfo5 while the dev version is libtinfo6 correctly?
(791) [bate@archit taichi]$ ldd build/libtaichi_core.so
linux-vdso.so.1 (0x00007fff76596000)
libGLEW.so.2.1 => /usr/lib/libGLEW.so.2.1 (0x00007f25ccc4d000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f25ccc2b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f25cca42000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f25cc902000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f25cc8f7000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f25cc7b1000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f25cc795000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f25cc790000)
libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f25cc71f000) # look here
libc.so.6 => /usr/lib/libc.so.6 (0x00007f25cc559000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f25cff49000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f25cc4d3000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f25cc4b9000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f25cc48d000)
libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f25cc3d6000)
libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f25cc3a3000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f25cc39e000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f25cc396000)
(791) [bate@archit taichi]$ ldd ~/.local/lib/python3.8/site-packages/taichi/lib/libtaichi_core.so
linux-vdso.so.1 (0x00007fffc63f9000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa36f78e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa36f5a5000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fa36f465000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007fa36f44b000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fa36f440000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa36f43b000)
libtinfo.so.5 => not found # look here
libm.so.6 => /usr/lib/libm.so.6 (0x00007fa36f2f3000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fa36f12d000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007fa372ab4000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa36f113000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa36f0e9000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fa36f0e2000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa36f0da000)
(791) [bate@archit taichi]$
Related issues
archibate
·
4Comments
archibate
·
3Comments
quadpixels
·
3Comments
zdxpan
·
3Comments
yuanming-hu
·
4Comments
Most helpful comment
I found where it is!!!!!! We should use objdump, not readelf: