Hello John. I've been experimenting with `libglvnd'. I've patched the calls to `dlopen` so they pick the `libGL.so.1` from the package `inputs`, which includes `libglvnd'.
That's all well and good but a new issue seems to arise. At runtime, the
application panics when asserting the creation a `FRAMEBUFFER`. This is
the error:
--8<---------------cut here---------------start------------->8---
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `0`,
right: `36053`',
/tmp/guix-build-mission-center-0.3.3.drv-0/pathfinder/gl/src/lib.rs:600:13
--8<---------------cut here---------------end--------------->8---
It originates on the following rust function:
--8<---------------cut here---------------start------------->8---
fn create_framebuffer(&self, texture: GLTexture) -> GLFramebuffer {
let mut gl_framebuffer = 0;
unsafe {
gl::GenFramebuffers(1, &mut gl_framebuffer); ck();
gl::BindFramebuffer(gl::FRAMEBUFFER, gl_framebuffer); ck();
self.bind_texture(&texture, 0);
gl::FramebufferTexture2D(gl::FRAMEBUFFER,
gl::COLOR_ATTACHMENT0,
gl::TEXTURE_2D,
texture.gl_texture,
0); ck();
assert_eq!(gl::CheckFramebufferStatus(gl::FRAMEBUFFER),
gl::FRAMEBUFFER_COMPLETE);
}
GLFramebuffer { gl_framebuffer, texture }
}
--8<---------------cut here---------------end--------------->8---
I've been trying to fix the issue for a few days already but this goes
out of my knowledge.
I'm witting this mail with the hope that someone could have an idea on
how to tackle this issue.
In will attach the package definition and the required dependencies to
build it. Any help would be appreciated. I believe this is an
interesting package for Guix since it would be the first example on how
to build a rust application that uses the `meson-build-system'. As an
addition, I've packaged many rust dependencies which, most of them,
build successfully.
The package requires dependencies only available on the `gnome-team`
branch. In order to build the application the following command can be
used:
--8<---------------cut here---------------start------------->8---
guix time-machine -q --commit=e38d6a9c2fba815ac34e74baa843f15e33846813 -- build
mission-center
--8<---------------cut here---------------end--------------->8---
Note that this package requires glib schemas to be installed. The only
solution I know for testing, is to install the package with:
--8<---------------cut here---------------start------------->8---
guix time-machine -q --commit=e38d6a9c2fba815ac34e74baa843f15e33846813 --
install mission-center
--8<---------------cut here---------------end--------------->8---
You can execute it with:
--8<---------------cut here---------------start------------->8---
$(guix time-machine -q --commit=e38d6a9c2fba815ac34e74baa843f15e33846813 --
build mission-center)/bin/missioncenter
--8<---------------cut here---------------end--------------->8---
Thanks everyone for your time.
Have a great day.
[ATTACHMENT]:
<<attachment: mission-center.zip>>
John Kehayias <john.kehay...@protonmail.com> writes: > Hi Sergio, > > On Fri, Nov 03, 2023 at 06:05 PM, Sergio Pastor Pérez wrote: > >> Hi. >> >> I've noticed that the `mesa' package we provide is missing some >> symbols that according to the OpenGL specification should be present on >> the `libGL.so.1` library. >> > > I'll put the punchline up top with a few more details below. But the > symbol you want is in the libglvnd package: > > --8<---------------cut here---------------start------------->8--- > ❯ nm -gD $(guix build libglvnd)/lib/libGL.so | grep glBindTextureUnit > 000000000004cb60 T glBindTextureUnit > 000000000004cb80 T glBindTextureUnitParameterEXT > --8<---------------cut here---------------end--------------->8--- > >> The following commands demonstrate the issue: >> >> $ guix build mesa >> /gnu/store/ds15k8bzqf1m861w17hshd8i54pffig9-mesa-23.1.4-bin >> /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4 >> >> $ nm -gD >> /gnu/store/hxvp1sp897rnnpbpb0xk887m4822gf77-mesa-23.1.4/lib/libGL.so.1 | >> grep glBindTextureUnit >> >> $ glxinfo | grep "OpenGL version" >> OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.4 >> >> > > Indeed, I found this very puzzling as you did. I looked for other > symbols defined in the same Mesa headers and it was hit or miss > (mostly miss). > >> As you can see the grep does not match any symbol. In contrast, if we do >> the same under an Ubuntu installation, we can see the following output: >> >> $ nm -gD /usr/lib/x86_64-linux-gnu/libGL.so.1 | grep glBindTextureUnit >> 0000000000046b60 T glBindTextureUnit >> 0000000000046b80 T glBindTextureUnitParameterEXT >> >> $ glxinfo | grep "OpenGL version" >> OpenGL version string: 4.6 (Compatibility Profile) Mesa >> 23.0.4-0ubuntu1~22.04.1 >> > > I have a laptop with Arch on it and I saw the same thing you did on > Unbuntu. However, I decided to double check where libGL comes from and > it is owned not by the mesa package there but libglvnd! And that's how > I found libGL also in our libglvnd package with the symbol you were > looking for. > > Unfortunately 'guix locate' didn't help me find other libGL in this > case (I tried that first) since I don't have libglvnd installed in any > profile. But a future upgrade or remote database of files in all our > packages will make this simpler. > >> >> This symbol is also present on the `libGL.so.1` provided by the >> proprietary Nvidia driver: >> >> $ guix build nvidia-driver >> /gnu/store/8xhdq3rf9k80n6vz5cwi7z1dg5wjq002-nvidia-driver-515.76 >> >> $ nm -gD >> /gnu/store/8xhdq3rf9k80n6vz5cwi7z1dg5wjq002-nvidia-driver-515.76/lib/libGL.so.1 >> | grep glBindTextureUnit >> 00000000000476c0 T glBindTextureUnit >> 0000000000047700 T glBindTextureUnitParameterEXT >> >> $ glxinfo | grep "OpenGL version" >> OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.1.4 >> > > Proprietary stuff aside, this comes back to a question raised before > for Guix that we haven't tackled, and that's libglvnd and loading > other gl drivers (yes, could be proprietary, but also more generally > on a foreign distro). Building mesa with libglvnd support is easy > enough, but the proper way to set this up to work well on Guix and > foreign systems I'm not so sure. It has been a while since I looked at > it but happy for someone to bring this up again or propose what we > should do to make it all work seamlessly. That's what libglvnd is for > after all, to dispatch gl calls to the right driver. (I think the idea > is that mesa is a provider of an implementation and the more general > top level for these symbols is elsewhere, libglvnd which could > dispatch it to mesa?) > >> I've noticed the problem because I'm packaging a rust up that I wanted to >> contribute as an example on how to build applications that use meson to >> build rust packages. This app uses `rust-minidl' to load `libGL.so.1` at >> runtime. The app tries to use the `glBindTextureUnit` symbol and panics. >> >> Does anyone know why this symbol could be missing? Could we fix the >> `mesa' package? I would like users of the open source drivers to be able >> to run the package. >> >> Thanks, >> Sergio. > > > So the first thing is to use libglvnd in your packaging, which will > get you the symbol you need. Whether more is needed for this to work > properly (mesa input also or something else) I don't know. And if > other packages in Guix actually need libglvnd (and mesa) to work I > also don't know but I would guess comes up in a bug report if it does > happen. > > Hope that helps! And I'm glad it wasn't some huge oversight in how we > build mesa (as far as I can tell) which left me scratching my head at > first. > > John
