Kitty: Error on build, OpenBSD current: Unable to find library -lrt & -ldl

[anoduck]

Describe the bug
Wanted to run kitty on my desktop for well over a year or two. It compiles beautifully, the error arises when it attempts to link files for fast_data_types. At the very end of the process it outputs that it cannot find library -lrt & -ldl. Not even sure what this is referring to.

To Reproduce
Steps to reproduce the behavior:

1. Run OpenBSD Current
2. export CC=cc CXX=c++
3. gmake
4. See error

Expected behavior
I expected it to fail earlier in the compilation, and it didn't so I am surprised and have hope.

Screenshots

cc -Wextra -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 -I/usr/local/include/libpng16 -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/python3.7m -Wall -O3 -shared -flto build/fast_data_types-charsets.c.o build/fast_data_types-child-monitor.c.o build/fast_data_types-child.c.o build/fast_data_types-colors.c.o build/fast_data_types-cursor.c.o build/fast_data_types-data-types.c.o build/fast_data_types-desktop.c.o build/fast_data_types-fontconfig.c.o build/fast_data_types-fonts.c.o build/fast_data_types-freetype.c.o build/fast_data_types-gl-wrapper.c.o build/fast_data_types-gl.c.o build/fast_data_types-glfw-wrapper.c.o build/fast_data_types-glfw.c.o build/fast_data_types-graphics.c.o build/fast_data_types-history.c.o build/fast_data_types-keys.c.o build/fast_data_types-kittens.c.o build/fast_data_types-line-buf.c.o build/fast_data_types-line.c.o build/fast_data_types-logging.c.o build/fast_data_types-loop-utils.c.o build/fast_data_types-monotonic.c.o build/fast_data_types-mouse.c.o build/fast_data_types-parser.c.o build/fast_data_types-png-reader.c.o build/fast_data_types-screen.c.o build/fast_data_types-shaders.c.o build/fast_data_types-state.c.o build/fast_data_typescc -Wextra -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 -I/usr/local/include/libpng16 -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/python3.7m -Wall -O3 -shared -flto build/fast_data_types-charsets.c.o build/fast_data_types-child-monitor.c.o build/fast_data_types-child.c.o build/fast_data_types-colors.c.o build/fast_data_types-cursor.c.o build/fast_data_types-data-types.c.o build/fast_data_types-desktop.c.o build/fast_data_types-fontconfig.c.o build/fast_data_types-fonts.c.o build/fast_data_types-freetype.c.o build/fast_data_types-gl-wrapper.c.o build/fast_data_types-gl.c.o build/fast_data_types-glfw-wrapper.c.o build/fast_data_types-glfw.c.o build/fast_data_types-graphics.c.o build/fast_data_types-history.c.o build/fast_data_types-keys.c.o build/fast_data_types-kittens.c.o build/fast_data_types-line-buf.c.o build/fast_data_types-line.c.o build/fast_data_types-logging.c.o build/fast_data_types-loop-utils.c.o build/fast_data_types-monotonic.c.o build/fast_data_types-mouse.c.o build/fast_data_types-parser.c.o build/fast_data_types-png-reader.c.o build/fast_data_types-screen.c.o build/fast_data_types-shaders.c.o build/fast_data_types-state.c.o build/fast_data_types-unicode-data.c.o build/fast_data_types-parser_dump.c.o -lintl -lpthread -lutil -lm -L/usr/local/lib -lpython3.7m -Wl,--export-dynamic -L/usr/X11R6/lib -lfontconfig -lfreetype -lz -L/usr/local/lib -lharfbuzz -L/usr/X11R6/lib -lGL -L/usr/local/lib -lpng -lz -lrt -ldl -o build/kitty/fast_data_types.so
ld: error: unable to find library -lrt
ld: error: unable to find library -ldl
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Reaping losing child 0x13a12b66a00 PID 64574 
gmake: *** [Makefile:9: all] Error 1
-unicode-data.c.o build/fast_data_types-parser_dump.c.o -lintl -lpthread -lutil -lm -L/usr/local/lib -lpython3.7m -Wl,--export-dynamic -L/usr/X11R6/lib -lfontconfig -lfreetype -lz -L/usr/local/lib -lharfbuzz -L/usr/X11R6/lib -lGL -L/usr/local/lib -lpng -lz -lrt -ldl -o build/kitty/fast_data_types.so
ld: error: unable to find library -lrt
ld: error: unable to find library -ldl
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Reaping losing child 0x13a12b66a00 PID 64574 
gmake: *** [Makefile:9: all] Error 1

Enviroment details
OS: OpenBSD Current
SHELL: zsh

Output of kitty --debug-confg

Additional context
N/A

[Luflosi]

I'm not using OpenBSD, so I can't really help you besides pointing you at the patch I wrote in the older issue you created (#1987), in case you didn't see the patch yet.

[kovidgoyal]

You need to detect openbsd in setup.py and remove lrt and ldl from the
ldflags, as they are part of libc there. https://www.openbsd.org/faq/ports/guide.html

[ctrlcctrlv]

Fancy seeing you here @anoduck. Are you writing a kitty port?

[anoduck]

COOL! That is exactly what I was wondering about. Thanks!

[anoduck]

@ctrlcctrlv Naw, kitty is just one of those things I wish OpenBSD supported. There are so many. You should join the riot chatroom blackhats.

[anoduck]

The OpenBSD group is a little too big for my trousers at the moment.

[spurgelaurels]

I wholeheartedly support writing a kitty port for OpenBSD. Did you get any further with this?

[spurgelaurels]

You need to detect openbsd in setup.py and remove lrt and ldl from the
ldflags, as they are part of libc there. https://www.openbsd.org/faq/ports/guide.html

I made this change, and a few others in setup.py
These flags also needed to be removed from glfw/glfw.py

Diff is here: https://github.com/spurgelaurels/kitty/commit/619f6878ec156cf094e1ab154203a6529426fded

After that, it compiled with python3.7 setup.py, and there's a new binary: kitty/launcher/kitty

However, running that gives "Failed to read /proc/self/exe"
Unfortunately, OpenBSD dropped procfs support in 5.7, and there's apparently not a good method for discovering the full path of the bin file.

[kovidgoyal]

Yes kitty needs a way to get the path to the exe. You could of course hardcode that path in launcher.c, and then install kitty into that path and runit only from there.

[Luflosi]

Also take a look at #1987 (in case you didn't see it yet), where I posted a patch that does basically what you did but without the detection of OpenBSD.

[spurgelaurels]

Thanks @Luflosi I had not seen this. I prefer the detection method as it would translate well into the main branch.
I also set the compiler with export CC=cc CXX=c++ instead.

[spurgelaurels]

@kovidgoyal I may do exactly that. Luckily OpenBSD ports (which is ultimately where I intend on going with this) will have a determinable path.

[Luflosi]

You could add a new command-line parameter to setup.py to specify the path. I can help you with that if you like.
@kovidgoyal is that the best way to do this or do you see a better way?

[kovidgoyal]

Yes, add a command line parameter to setup.py that defines a macro when
building launcher.c which creates a reade_exe() function that simply
returns the hardcoded path.

On Fri, Aug 21, 2020 at 11:01:47AM -0700, Luflosi wrote:

You could add a new command-line parameter to setup.py to specify the path. I can help you with that if you like.
@kovidgoyal is that the best way to do this or do you see a better way?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/kovidgoyal/kitty/issues/2675#issuecomment-678417425

--

---

Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com

---

[kovidgoyal]

Actually I came up with a better solution, see my last commit. I have not tested the function, I leave that to someone on OpenBSD to do.

[spurgelaurels]

Tested, and with the changes I made in setup.py and glfw.py, it works splendidly!

[spurgelaurels]

May have spoken too soon...
Running kitty as a symlink (~/bin/kitty points to ~/src/kitty/kitty/launcher/kitty) from a running terminal runs perfectly well. However, it does not work from rofi, i3 keyboard shortcuts, etc.

I tried copying the binary right into my ~/bin directory, however it also didn't work, for probably pretty obvious reasons to any of the kitty expert devs.

I tried creating a ~/bin/kitty.sh to start kitty with an exec or 2>&1 &, but that fails from the rofi / i3 keyboard shortcuts too.

At least 2>&1 & will allow me to kill the shell for now, so I am at a point with kitty running openbsd. I will likely get annoyed by this startup method and come back to hacking at this within a week or so!

Thanks for the help everyone. I'll submit my changes as a PR