Yggdrasil
Yggdrasil copied to clipboard
JuliaPackaging
add recipe for EGL
It's unfortunate that Libglvnd provides a library with the same name. This will likely cause a warning if a user loads both packages
Will it just cause a warning or could it also lead to the wrong library being used?
Any idea what this means?
[08:56:32] /opt/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/8.1.0/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible /opt/x86_64-linux-musl/lib/libLLVM-11.so when searching for -lLLVM-11
[08:56:32] /opt/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/8.1.0/../../../../aarch64-linux-gnu/bin/ld: cannot find -lLLVM-11
``
Will it just cause a warning or could it also lead to the wrong library being used?
Whatever happens when two packages export the same variable. Warning + you must qualify the variable with its module?
Ah, I thought it was something specific to BB. I don't think it should matter too much then, since I think this warning is only shown in interactive usage, not when it's done in a package. Packages only need to remember to qualify the module.
Now that I think of it, you can't dlopen two libraries with the same soname, the first one will win
Would you be okay with merging a fixed-up version of this with a more obscure name for now? I think we can probably separate out some of the components into separate jlls, but I looked into it a bit and the interdependencies and dealing with the right driver components didn't seem very straightforward.
For the name, yes, I don't think calling this Mesa is an option at all at this point, so we have to stick to something like this. I'm a bit worried about the clash with libglvnd, that's a real concern at runtime. Have you seen how Linux distributions go about this? Maybe the mark the two packages as conflicting?
Have you seen how Linux distributions go about this? Maybe the mark the two packages as conflicting?
It looks like Debian declares libegl as a dependency for libglvnd, so I assume that libglvnd can probably be made to use the libegl provided here. Of course that would also mean that libglvnd always depends on wayland. Arch actually seems to have a circular dependency between the two, so not sure what's going on there. I can try to make this recipe more minimal and split the components up a bit more, so we can maybe have them as separate jlls.
Oh, no wait! I think libegl actually comes from libglvnd in Debian? https://tracker.debian.org/pkg/libglvnd
Yes, that's what I was looking at now: they just split the libglvnd source into multiple binary packages. But as far as I can see the package you're building here isn't involved
It appears that the package they build out of this source has libEGL_mesa.so, not libEGL.so: https://packages.debian.org/sid/amd64/libegl-mesa0/filelist
Also, in Debian they build with glvnd=true (option in meson_options.txt), I don't know if that's useful for us
So the way that things work between Mesa and Libglvnd is the following:
- If building Mesa without
-Dglvnd,libEGL.sois produced and will be directly opened by the client - If building Mesa with
-Dglvnd,libEGL_mesa.sois produced. The client will open Libglvnd'slibEGL.so, which will forward calls tolibEGL_mesa.so
Basically, if you're going to link Libglvnd into a process, then Mesa better have been built with -Dglvnd. Otherwise you'll end up with two libEGL.so libraries, which will just not work correctly.
I think we should probably name this Mesa_EGL_jll, and (if possible) patch GLFW_jll to use an environment variable (or similar) to select between loading Libglvnd_jll and Mesa_EGL_jll. This is one of those cases where, without us building all of the graphics libs, we need to support differences in OS configurations manually.
It's been a while since I last messed up a git history this badly... ;)
Do we need to install wayland-dev? I figured that we could just use Wayland_jll to provide headers.
Looks like this is now having troubles with the LLVM dependencies. I'm not sure how to work around that. I also don't want to lick any cookies here, so if you want to take this over that's perfectly fine by me.
Is there a reason why you don't apk add meson and mkdir build; cd build anymore?
That was a workaround to get a newer meson version, but I can still try adding that back
I get different errors locally, relating to using an old version of Wayland_protocols_jll. I'll work on this locally and see how far I can get.
Just a quick update: I've got a local build that works great with GLFW! I've been able to run a CImGui demo as well, proving that it actually works. I'm in the process of working out the last bug before pushing changes (which are somewhat extensive, but we also now enable a lot more mesa functionality).
Not sure what's up with the static_assert failure.
Aside: Do we need/want this built on glibc?
Alternatively: this is now building the full set of userspace graphics drivers. Do we instead want to move this to Mesa_jll? That would imply that we would be shipping the entire userspace graphics stack (minus the compositor), and would be able to do away with Libglvnd.
Aside: Do we need/want this built on glibc?
Would be nice at least. Not everyone's using Alpine you know... :sweat_smile:
Do we instead want to move this to
Mesa_jll?
I don't really care either way. Perhaps @giordano has some thoughts?
Not everyone's using Alpine you know...
Oops, sorry, I had assumed this was to fix issues on musl-based distros!
My initial motivation for this was actually because I had the silly idea to build a window manager entirely using BinaryBuilder...
Awesome!
@giordano I'm :+1: to merging this. I can send another PR for the augmented platform support for supporting multiple LLVM versions.
@jpsamaroo bump :slightly_smiling_face: There are a couple of questions above