Good evening. Diving on the issues of the official `mission-center' repository I've noticed this issue: https://gitlab.com/mission-center-devs/mission-center/-/issues/87
Which has been recently merged into main as per the following merge request [1]: 1: https://gitlab.com/mission-center-devs/mission-center/-/merge_requests/76/diffs?commit_id=89fcd7f3d294fef833ba4c3369778d85a13b501b Using the latest commit [2], authored 2 days ago, the issue ceases to exist and the app starts successfully. 2: 4fc7268f5dd314580e721825a63d3e34421e8317; Thanks every one that got involved from the IRC and mailing list. Greetings, Sergio. Sergio Pastor Pérez <sergio.pastorpe...@outlook.es> writes: > 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]: > > 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
