Closed xiangpeng2008 closed 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.
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' ?
BTW, I just tried installing glibc-2.27 , but I got segmentation fault, so I should still build myself
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.
Sorry no I have no interest in maintaining builds for ancient distros. Centos 7 was released 8 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.
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.
No clue, sorry. Compatibility with Centos 7 was never a goal for kitty.
And note that if you simply uninstall wayland, kitty will build without wayland support.
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.
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
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 ?
you are linking against a static lib python instead of a dynamic one.
thanks for your info do you have an idea how to solve this ? This goes far beyond my knowledge.
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
but also
Only works if the remote server has an architecture for which pre-compiled kitty binaries are available
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.
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 ?
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.
Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior:
Screenshots If applicable, add screenshots to help explain your problem.
Environment details
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