containers / toolbox

Tool for interactive command line environments on Linux
https://containertoolbx.org/
Apache License 2.0
2.53k stars 217 forks source link

Unable to launch Go applications using go-gl/glfw #1023

Closed Jacalz closed 2 years ago

Jacalz commented 2 years ago

Describe the bug A clear and concise description of what the bug is. If possible, re-run the command(s) with --log-level debug and put the output here. I can't seem to be run any Go that have been built using the go-gl/glfw package. This was tested on a Fedora Kinoite 35 install and it seems to have some trouble finding a driver of some sort. I opened https://github.com/go-gl/glfw/issues/349 but I am not entirely sure if it is an issue here or there.

Steps how to reproduce the behaviour

  1. Create a toolbox. I used one with Fedora 35 in it.
  2. Run any app built using go-gl/glfw. If you don't want to build one yourself, grabbing a binary from https://github.com/Jacalz/rymdport/releases/tag/v3.0.0 should be fine.
  3. See error

Expected behaviour I expected the application to run just as it does outside of the toolbox.

Actual behaviour I get the following error:

libGL error: MESA-LOADER: failed to open iris: /usr/lib64/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: swrast
panic: VersionUnavailable: GLX: Failed to create context: BadValue (integer parameter out of range for operation)

goroutine 1 [running, locked to thread]:
main.main()
        /var/home/jacob/glfw/main.go:23 +0x118

I suspect that there is some sort of driver that isn't passed through the container correctly.

Output of toolbox --version (v0.0.90+) toolbox version 0.0.99.3

Toolbox package info (rpm -q toolbox) toolbox-0.0.99.3-2.fc35.x86_64

Output of podman version

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.16.8
Built:        Wed Dec  8 22:45:07 2021
OS/Arch:      linux/amd64

Podman package info (rpm -q podman) podman-3.4.4-1.fc35.x86_64

Info about your OS Fedora Kinoite 35

Additional context Add any other context about the problem here. When did the issue start occurring? After an update (what packages were updated)? If the issue is about operating with containers/images (creating, using, deleting,..), share here what image you used. If you're unsure, share here the output of toolbox list -i (shows all toolbox images on your system).

IMAGE ID      IMAGE NAME                                    CREATED
09cc3fe0e1d0  registry.fedoraproject.org/fedora-toolbox:35  9 days ago

If you see an error message saying: Error: invalid entry point PID of container <name-of-container>, add to the ticket output of command podman start --attach <name-of-container>.

HarryMichal commented 2 years ago

Hi @Jacalz! I may be wrong but this seems like you're missing the appropriate drivers. I'm no expert on Mesa but a quick grep through dnf search mesa could help with what to install.

Jacalz commented 2 years ago

Hi @Jacalz! I may be wrong but this seems like you're missing the appropriate drivers. I'm no expert on Mesa but a quick grep through dnf search mesa could help with what to install.

That seems to do the trick! Thanks. I installed mesa-dri-drivers and mesa-vulkan-drivers and it now works as expected.

On another note however, wouldn't it make sense to have graphics drivers be passed into the toolbox automatically? For something with less os-integration, it seems like it makes sense to not do so, but I am kind of confused that it isn't done with toolbox.

HarryMichal commented 2 years ago

Would it? I'm not so certain myself. My personal opinion is that toolboxes tend to be more used headless and for purposes not requiring drivers. There is in play an image size concern which though has not been addressed in some time to be perfectly honest. Certainly open to discussion but I would require some concrete examples of when the presence of the packages would be critical.

In any case, that is a conversation for a different ticket as this one has been solved. Feel free to open it to start the discussion. Closing.

Jacalz commented 2 years ago

Understandable.Thanks a lot for the help.

I just want to clarify that I wasn’t technically meaning to have the packages installed by default, but simply that they could be passed through from the host (if possible). I’ll open a different issue for the discussion.

debarshiray commented 2 years ago

My personal opinion is that toolboxes tend to be more used headless and for purposes not requiring drivers. There is in play an image size concern which though has not been addressed in some time to be perfectly honest.

People certainly do run desktop graphical applications from a Toolbx. Imagine that you are a GTK developer. :)

These days with GTK4 using OpenGL and Vulkan, having them enabled out of the box is important.

debarshiray commented 2 years ago

Duplicate of https://github.com/containers/toolbox/issues/1110