kovidgoyal / kitty

Cross-platform, fast, feature-rich, GPU based terminal
https://sw.kovidgoyal.net/kitty/
GNU General Public License v3.0
24.15k stars 972 forks source link

version `GLIBC_2.2?` not found #5094

Closed xiangpeng2008 closed 2 years ago

xiangpeng2008 commented 2 years ago

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin
/lxhome/zhangxia/.local/kitty.app/bin/kitty: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /lxhome/zhangxia/.local/kitty.app/bin/../lib/libpython3.9.so.1.0)
/lxhome/zhangxia/.local/kitty.app/bin/kitty: /lib64/libc.so.6: version `GLIBC_2.26' not found (required by /lxhome/zhangxia/.local/kitty.app/bin/../lib/libpython3.9.so.1.0)
/lxhome/zhangxia/.local/kitty.app/bin/kitty: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /lxhome/zhangxia/.local/kitty.app/bin/../lib/libpython3.9.so.1.0)

Screenshots If applicable, add screenshots to help explain your problem. image

Environment details

Press Ctrl+Shift+F6 (cmd+option+comma on macOS) in kitty, to copy debug output about kitty and its
configuration to the clipboard and paste it here. 

On older versions of kitty, run kitty --debug-config instead

Additional context Try to reproduce the problem with kitty --config NONE if you cannot then post a minimal kitty.conf that reproduces the problem. If the problem involves interaction with some other terminal program post a minimal config for that program to reproduce the problem as well.

linux version is Centos 7.9

kovidgoyal commented 2 years ago

the version of glibc on your system is too old to run the kitty binaries. Build it from source or update the system.

xiangpeng2008 commented 2 years ago

It's said that it's not recommended to update the system. But when I build from source, it's super strange to see

python3 setup.py 
CC: ['gcc'] (4, 8)
Package harfbuzz was not found in the pkg-config search path.
Perhaps you should add the directory containing `harfbuzz.pc'
to the PKG_CONFIG_PATH environment variable
No package 'harfbuzz' found
harfbuzz >= 1.5 is required, found version: not found
make: *** [all] Error 1

but I really installed it sudo yum -y install harfbuzz do you happen to have an idea where is this `harfbuzz.pc' ?

xiangpeng2008 commented 2 years ago

BTW, I just tried installing glibc-2.27 , but I got segmentation fault, so I should still build myself

Screenshot 2022-05-14 at 3 36 29 PM
xiangpeng2008 commented 2 years ago

hi @kovidgoyal Is it possible to provide a centos 7 build ? It's super hard to build myself, after installing many dependency

sudo yum install lcms2-devel
sudo yum install libxkbcommon-devel
sudo yum install xrandr-dev
sudo yum install libXrandr-devel
sudo yum install libXinerama-devel
sudo yum install libXcursor-devel
sudo yum install libxkbcommon-x11-devel
sudo yum install libdbus-1-tqt-devel
sudo yum install dbus-devel

I'm again block by below error because sudo yum install wayland-protocols-devel only provides 1.14 version.

Screenshot 2022-05-15 at 2 49 13 PM
kovidgoyal commented 2 years ago

Sorry no I have no interest in maintaining builds for ancient distros. Centos 7 was released 8 years ago.

xiangpeng2008 commented 2 years ago

okay I try to figure out myself then Actually Centos 7 is currently the only Centos with maintenance updates, as centos 8 dies already. So many firms should still stick to it for a while.

xiangpeng2008 commented 2 years ago

Well, I can't build wayland-protocols, because it depends on some other package with a version not available on centos 7. I will build a whole centos 8 on top of centos 7 if I continue like this.

Could you help to indicate the last build of kitty supporting GNU C Library (GNU libc) stable release version 2.17 ? I remember it worked last year on centos 7.

kovidgoyal commented 2 years ago

No clue, sorry. Compatibility with Centos 7 was never a goal for kitty.

kovidgoyal commented 2 years ago

And note that if you simply uninstall wayland, kitty will build without wayland support.

xiangpeng2008 commented 2 years ago

Ah, it's true, the building is blocked by some other error

gcc -MMD -DNDEBUG -D_GLFW_X11 -D_GLFW_BUILD_DLL -Wextra -Wfloat-conversion -Wno-missing-field-initializers -Wall -Wstrict-prototypes -std=c11 -pedantic-errors -Werror -O3 -fwrapv -fstack-protector-strong -pipe -march=native -fvisibility=hidden -D_FORTIFY_SOURCE=2 -fPIC -flto -DKITTY_HAS_RS_SIG_ARGS -fPIC -pthread -DXKB_HAS_NO_UTF32 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -c glfw/x11_window.c -o build/glfw-x11-x11_window.c.o
In file included from glfw/internal.h:192,
                 from glfw/x11_window.c:31:
glfw/x11_platform.h:52:10: fatal error: X11/extensions/XInput2.h: No such file or directory
   52 | #include <X11/extensions/XInput2.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [all] Error 1

I need to dig a bit more.

xiangpeng2008 commented 2 years ago

Is there requirement for version of gcc ?

python3 setup.py 
CC: ['gcc'] (11, 3)
Package wayland-protocols was not found in the pkg-config search path.
Perhaps you should add the directory containing `wayland-protocols.pc'
to the PKG_CONFIG_PATH environment variable
No package 'wayland-protocols' found
wayland-protocols >= 1.17 is required, found version: not found
Disabling building of wayland backend
[2/50] Compiling [x11] glfw/glx_context.c ... done
Compiling kitty/freetype_render_ui_text.c ...
gcc -MMD -DNDEBUG -DPRIMARY_VERSION=4000 -DSECONDARY_VERSION=25 -DXT_VERSION="0.25.0" -Wextra -Wfloat-conversion -Wno-missing-field-initializers -Wall -Wstrict-prototypes -std=c11 -pedantic-errors -Werror -O3 -fwrapv -fstack-protector-strong -pipe -march=native -fvisibility=hidden -D_FORTIFY_SOURCE=2 -fPIC -flto -DKITTY_HAS_RS_SIG_ARGS -pthread -I/usr/include/libpng15 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/local/include/python3.9 -c kitty/freetype_render_ui_text.c -o build/fast_data_types-freetype_render_ui_text.c.o
In file included from /usr/include/harfbuzz/hb-blob.h:34,
                 from /usr/include/harfbuzz/hb.h:35,
                 from /usr/include/harfbuzz/hb-ft.h:32,
                 from kitty/freetype_render_ui_text.h:10,
                 from kitty/freetype_render_ui_text.c:8:
/usr/include/harfbuzz/hb-common.h:79:29: error: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]
   79 | #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint8_t)(c1))<<24)|(((uint8_t)(c2))<<16)|(((uint8_t)(c3))<<8)|((uint8_t)(c4))))
      |                             ^
/usr/include/harfbuzz/hb-common.h:83:20: note: in expansion of macro ‘HB_TAG’
   83 | #define HB_TAG_MAX HB_TAG(0xff,0xff,0xff,0xff)
      |                    ^~~~~~
/usr/include/harfbuzz/hb-common.h:328:51: note: in expansion of macro ‘HB_TAG_MAX’
  328 |   _HB_SCRIPT_MAX_VALUE                          = HB_TAG_MAX, /*< skip >*/
      |                                                   ^~~~~~~~~~
kitty/freetype_render_ui_text.c: In function ‘render_single_char_bitmap’:
kitty/freetype_render_ui_text.c:484:26: error: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Werror=sign-compare]
  484 |     for (size_t r = 0; r < bm->rows; r++) {
      |                          ^
cc1: all warnings being treated as errors
make: *** [all] Error 1
xiangpeng2008 commented 2 years ago

After changing

--- a/kitty/freetype_render_ui_text.c
+++ b/kitty/freetype_render_ui_text.c
@@ -481,7 +481,7 @@ render_single_char_bitmap(const FT_Bitmap *bm, size_t *result_width, size_t *res
     *result_width = bm->width; *result_height = bm->rows;
     uint8_t *rendered = malloc(*result_width * *result_height);
     if (!rendered) { PyErr_NoMemory(); return NULL; }
-    for (size_t r = 0; r < bm->rows; r++) {
+    for (int8_t r = 0; r < bm->rows; r++) {
         uint8_t *src_row = bm->buffer + bm->pitch * r;
         uint8_t *dest_row = rendered + *result_width * r;
         memcpy(dest_row, src_row, *result_width);

I got some progress, but it failed in

[2/5] Linking kittens/unicode_input/unicode_names ... done
Linking kittens/unicode_input/unicode_names ...
gcc -Wextra -Wfloat-conversion -Wno-missing-field-initializers -Wall -Wstrict-prototypes -std=c11 -O3 -fwrapv -fstack-protector-strong -pipe -march=native -fvisibility=hidden -D_FORTIFY_SOURCE=2 -fPIC -flto -DKITTY_HAS_RS_SIG_ARGS -Ikitty -I/usr/local/include/python3.9 -Wall -O3 -shared -flto build/unicode_names-unicode_names.c.o -lcrypt -lpthread -ldl -lutil -lm -lm -L/usr/local/lib -lpython3.9 -Xlinker -export-dynamic -o build/kittens/unicode_input/unicode_names.so
/usr/bin/ld: /usr/local/lib/libpython3.9.a(longobject.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(moduleobject.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(object.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(obmalloc.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC

... a lot of lines ...
/usr/bin/ld: /usr/local/lib/libpython3.9.a(structmember.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(pystrhex.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(parser.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(pegen.o): relocation R_X86_64_32 against symbol `_Py_NoneStruct' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(parse.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(parse_string.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(myreadline.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libpython3.9.a(getcompiler.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

@kovidgoyal do you by chance have an idea what's this ?

kovidgoyal commented 2 years ago

you are linking against a static lib python instead of a dynamic one.

xiangpeng2008 commented 2 years ago

thanks for your info do you have an idea how to solve this ? This goes far beyond my knowledge.

xiangpeng2008 commented 2 years ago

actually the reason I build it on centos 7 is because centos 7 is my remote server, I have kitty running on WSL ubuntu locally, but I still need a kitty running on remote server, right ? Or I don't need it now ? I see this image but also Only works if the remote server has an architecture for which pre-compiled kitty binaries are available

kovidgoyal commented 2 years ago

yes, if your remote server isnt compatible with the kitty binaries, you need to build it yourself. Though you dont strictly need kitty on your remote server, its just nice to have to be able to use some kittens like icat and file transfer. But there exist alternatives you can use for that.

xiangpeng2008 commented 2 years ago

yes, if your remote server isnt compatible with the kitty binaries, you need to build it yourself. Though you dont strictly need kitty on your remote server, its just nice to have to be able to use some kittens like icat and file transfer. But there exist alternatives you can use for that.

I really need icat, what kind of alternatives could I use ?

kovidgoyal commented 2 years ago

There are lots of scripts and statically compiled binaries and various programs that can display images using the kitty graphics protocol. A bit of googling will find them, the latest that came to my attention is tpix.