mesa@23.1.4: missing symbols

mesa@23.1.4: missing symbols

[Sergio Pastor Pérez]

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.

The following commands demonstrate the issue:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

This symbol is also present on the `libGL.so.1` provided by the
proprietary Nvidia driver:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---

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.

Re: mesa@23.1.4: missing symbols

[John Kehayias]

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

Re: mesa@23.1.4: missing symbols

[Sergio Pastor Pérez]

[-- Attachment #1: Type: text/plain, Size: 3033 bytes --]

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 #2: mission-center.zip --]
[-- Type: application/zip, Size: 15312 bytes --]

[-- Attachment #3: Type: text/plain, Size: 4783 bytes --]


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

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