Re: mesa@23.1.4: missing symbols

[Sergio Pastor Pérez]

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.pastorperez@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.kehayias@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