add recipe for EGL #3192

simeonschaub · 2021-06-20T08:38:58Z

No description provided.

giordano

It's unfortunate that Libglvnd provides a library with the same name. This will likely cause a warning if a user loads both packages

giordano · 2021-06-20T08:48:13Z

E/EGL/build_tarballs.jl

+cd build
+apk add py3-mako meson wayland-dev
+
+# pkgconfig returns the wrong path here. It's an ugly hack, but it works


I'll have a look about what is going on there, but in any case you must delete this link at the end, otherwise it'll end up inside the tarball

Ah, right! I forgot.

giordano · 2021-06-20T08:50:48Z

E/EGL/build_tarballs.jl

+
+# Bash recipe for building across all platforms
+script = raw"""
+mkdir build


The automatic installation of the license looks for files with reasonable names in the only directory inside /workspace/srcdir. If there are more than one directory here, this will fail. So it's better to enter the mesa directory and create the build folder inside it

OK, will change that

simeonschaub · 2021-06-20T09:03:08Z

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
``

giordano · 2021-06-20T09:33:01Z

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?

simeonschaub · 2021-06-20T09:43:23Z

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.

giordano · 2021-06-20T10:19:02Z

Now that I think of it, you can't dlopen two libraries with the same soname, the first one will win

giordano · 2021-06-20T10:22:03Z

E/EGL/build_tarballs.jl

+# `julia build_tarballs.jl --help` to see a usage message.
+using BinaryBuilder, Pkg
+
+name = "EGL"


Why is this called EGL and not Mesa, which we have already, but only for Windows?

I was a bit confused about this as well TBH. I think the current MESA jll should definitely have a different name. I named this EGL, because that is what my goal of building was initially, but I will need GBM and GLESv2 as well, so I wasn't unhappy that they were built alongside as well. MESA does have additional components like OpenCL and some stuff relating to Xorg as well, which I don't build here, but naming this jll MESA probably makes a lot more sense than the package we currently call MESA.

Is there any reason we can't fold this into the existing Mesa_jll? You should be able to enable multiple APIs in one build, and make the Unix-only options conditional on the OS.

Yes that sounds like a good plan. I plan to pick this up eventually, but I am just a bit busy ATM. Feel free to take this over if you are interested in this though.

simeonschaub · 2021-06-21T12:12:59Z

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.

giordano · 2021-06-21T22:35:11Z

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?

E/EGL/build_tarballs.jl

simeonschaub · 2021-06-21T22:46:09Z

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.

simeonschaub · 2021-06-21T22:52:41Z

Oh, no wait! I think libegl actually comes from libglvnd in Debian? https://tracker.debian.org/pkg/libglvnd

giordano · 2021-06-21T22:54:23Z

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

giordano · 2021-06-21T23:03:52Z

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

giordano · 2021-06-21T23:26:17Z

egl-lib-suffix sounds relevant

giordano · 2021-06-21T23:28:45Z

Also, in Debian they build with glvnd=true (option in meson_options.txt), I don't know if that's useful for us

jpsamaroo · 2021-07-10T17:07:56Z

So the way that things work between Mesa and Libglvnd is the following:

If building Mesa without -Dglvnd, libEGL.so is produced and will be directly opened by the client
If building Mesa with -Dglvnd, libEGL_mesa.so is produced. The client will open Libglvnd's libEGL.so, which will forward calls to libEGL_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.

giordano · 2021-07-16T23:50:39Z

Pinging @Wimmerer who's also interested in Mesa

jpsamaroo · 2021-12-14T01:47:44Z

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.

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>

simeonschaub · 2022-02-23T17:34:52Z

Yeah, I double-checked locally that this doesn't make a difference

Needed for JuliaPackaging#3192

Needed for #3192

jpsamaroo · 2022-02-23T18:18:19Z

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.

jpsamaroo · 2022-02-25T17:46:45Z

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).

Patch meson's finding of wayland-scanner Patch mesa's loader to attempt relpath dlopen first Enable X11 support Build libGL.so

jpsamaroo · 2022-02-25T20:47:03Z

Not sure what's up with the static_assert failure.

Aside: Do we need/want this built on glibc?

jpsamaroo · 2022-02-25T21:13:03Z

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.

simeonschaub · 2022-02-25T22:00:56Z

Aside: Do we need/want this built on glibc?

Would be nice at least. Not everyone's using Alpine you know... 😅

Do we instead want to move this to Mesa_jll?

I don't really care either way. Perhaps @giordano has some thoughts?

jpsamaroo · 2022-02-25T22:02:11Z

Not everyone's using Alpine you know...

Oops, sorry, I had assumed this was to fix issues on musl-based distros!

simeonschaub · 2022-02-25T22:04:42Z

My initial motivation for this was actually because I had the silly idea to build a window manager entirely using BinaryBuilder...

jpsamaroo · 2022-02-25T23:11:14Z

Awesome!

@giordano I'm 👍 to merging this. I can send another PR for the augmented platform support for supporting multiple LLVM versions.

M/Mesa_EGL/build_tarballs.jl

giordano · 2022-02-26T17:07:26Z

M/Mesa_EGL/build_tarballs.jl

+
+# Dependencies that must be installed before this package can be built
+dependencies = [
+    BuildDependency("Wayland_jll"), # FIXME: HostBuildDependency


What does the FIXME refer to?

M/Mesa_EGL/build_tarballs.jl

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>

giordano · 2022-02-26T17:24:38Z

M/Mesa_EGL/bundled/patches/wl_scanner-no-native.patch

+ # TODO: symbol mangling
+
+ if with_platform_wayland
+-  dep_wl_scanner = dependency('wayland-scanner', native: true)


Uhm, why is this patch necessary? If they need a native wayland-scanner isn't the solution to add HostBuildDependency("Wayland_jll")? We do that already in

Yggdrasil/G/GTK3/build_tarballs.jl

Lines 76 to 77 in 061fca6

# Need a host Wayland for wayland-scanner

HostBuildDependency("Wayland_jll"; platforms=linux),

Yggdrasil/G/GTK4/build_tarballs.jl

Lines 94 to 95 in 7b2b452

# Need a host Wayland for wayland-scanner

HostBuildDependency("Wayland_jll"; platforms=x11_platforms),

Yggdrasil/W/Wayland_protocols/build_tarballs.jl

Line 34 in fcf41ad

HostBuildDependency("Wayland_jll"),

This and the FIXME were there because meson had problems with choosing to use the provided wayland-scanner from HostBuildDependency("Wayland_jll"); I don't remember the error, but it was cryptic and unhelpful 😄 I've reverted that change, and am trying to figure out the build failure.

giordano · 2022-03-01T01:09:52Z

@jpsamaroo bump 🙂 There are a couple of questions above

jpsamaroo · 2022-03-01T03:31:05Z

sandbox:${WORKSPACE}/srcdir/mesa/build # cat ${host_prefix}/lib/pkgconfig/wayland-scanner.pc
prefix=/workspace/destdir
exec_prefix=${prefix}
datarootdir=${prefix}/share
pkgdatadir=${datarootdir}/wayland
wayland_scanner=${exec_prefix}/bin/wayland-scanner

Name: Wayland Scanner
Description: Wayland scanner
Version: 1.19.0

How do we deal with pkg-config files for HostBuildDependency?

giordano · 2022-03-02T00:59:45Z

How do we deal with pkg-config files for HostBuildDependency?

If the problem is that prefix is inaccurate you can perhaps fix it in-place? Something like

sed -i "s?prefix=.*?prefix=${host_prefix}?" "${host_prefix}/lib/pkgconfig/wayland-scanner.pc"

jpsamaroo · 2022-03-03T16:28:34Z

@giordano would appreciate any advice on the current failure.

giordano · 2022-03-03T23:14:07Z

You have Wayland_jll only as a host dependency, not a target one

M/Mesa_EGL/build_tarballs.jl

giordano · 2022-03-03T23:18:49Z

M/Mesa_EGL/build_tarballs.jl

+# Dependencies that must be installed before this package can be built
+dependencies = [
+    HostBuildDependency("Wayland_jll"),
+    Dependency("libLLVM_jll"; compat="11.0.0"),


So this will work only in julia v1.6?

It requires LLVM >= 11 (and I tested successfully on LLVM 12). What's the compat notation for that?

@vchuravy what's the kosher way of dealing with this? Use libLLVM_jll as dependency but not specify a compat? Use libLLVM_jll as a BuildDependency (libllvm will be anyway available at runtime)? Or perhaps follow LLVMExtra now that we have that mechanism in place?

Ok, seeing that this links directly to libLLVM-11jl.so I think the the LLVMExtra's approach is the way to go. I'm actually surprised it worked for you with other Julia versions with different LLVM 🤔

Oh, no, it didn't 😄 I had to switch which libLLVM I imported.

M/Mesa_EGL/build_tarballs.jl

simeonschaub added 3 commits June 20, 2021 10:38

add recipe for EGL

1886057

try to fix arm builds

8c20534

remove experimental platforms for now

3dbc914

giordano reviewed Jun 20, 2021

View reviewed changes

address review comments

f9d29f1

simeonschaub added 2 commits June 20, 2021 11:21

expand cxxstring ABIs, only build amd64 for now

fa44db1

bundle license

1ea3398

fix syntax

7e9a48a

giordano reviewed Jun 20, 2021

View reviewed changes

only use cxx11 string abi

ec7d651

giordano reviewed Jun 21, 2021

View reviewed changes

E/EGL/build_tarballs.jl Outdated Show resolved Hide resolved

giordano mentioned this pull request Jul 10, 2021

No GLXFBConfigs returned JuliaGL/GLFW.jl#194

Open

simeonschaub and others added 3 commits February 22, 2022 23:18

Merge remote-tracking branch 'upstream/master' into sds/EGL

20f8129

rename to Mesa_EGL

75f15ba

Update E/EGL/build_tarballs.jl

20eea78

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>

jpsamaroo added a commit to jpsamaroo/Yggdrasil that referenced this pull request Feb 23, 2022

[Wayland_protocols] Update to 1.24

ad3dd1e

Needed for JuliaPackaging#3192

jpsamaroo mentioned this pull request Feb 23, 2022

[Wayland_protocols] Update to 1.24 #4493

Merged

giordano pushed a commit that referenced this pull request Feb 23, 2022

[Wayland_protocols] Update to 1.24 (#4493)

b2ba30d

Needed for #3192

jpsamaroo added 2 commits February 25, 2022 12:09

Fix library search

40f2f7d

Patch meson's finding of wayland-scanner Patch mesa's loader to attempt relpath dlopen first Enable X11 support Build libGL.so

Fix llvm-config with cross-file

af25704

fix build on glibc by disabling static_assert

229d0f2

giordano reviewed Feb 26, 2022

View reviewed changes

Apply suggestions from code review

8b57cc7

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>

giordano reviewed Feb 26, 2022

View reviewed changes

Remove wayland-scanner no-native patching

19aa3bf

Fixup pkg-config paths to Wayland_jll

39c08e9

giordano reviewed Mar 3, 2022

View reviewed changes

M/Mesa_EGL/build_tarballs.jl Show resolved Hide resolved

Update M/Mesa_EGL/build_tarballs.jl

ce6ee08

giordano reviewed Mar 3, 2022

View reviewed changes

M/Mesa_EGL/build_tarballs.jl Outdated Show resolved Hide resolved

Update M/Mesa_EGL/build_tarballs.jl

6027ae4

	# Need a host Wayland for wayland-scanner
	HostBuildDependency("Wayland_jll"; platforms=linux),

add recipe for EGL #3192

Are you sure you want to change the base?

add recipe for EGL #3192

Conversation

simeonschaub commented Jun 20, 2021

giordano left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simeonschaub commented Jun 20, 2021

giordano commented Jun 20, 2021

simeonschaub commented Jun 20, 2021

giordano commented Jun 20, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simeonschaub commented Jun 21, 2021

giordano commented Jun 21, 2021

simeonschaub commented Jun 21, 2021

simeonschaub commented Jun 21, 2021

giordano commented Jun 21, 2021

giordano commented Jun 21, 2021

giordano commented Jun 21, 2021

giordano commented Jun 21, 2021

jpsamaroo commented Jul 10, 2021

giordano commented Jul 16, 2021

jpsamaroo commented Dec 14, 2021

simeonschaub commented Feb 23, 2022

jpsamaroo commented Feb 23, 2022

jpsamaroo commented Feb 25, 2022

jpsamaroo commented Feb 25, 2022

jpsamaroo commented Feb 25, 2022

simeonschaub commented Feb 25, 2022

jpsamaroo commented Feb 25, 2022

simeonschaub commented Feb 25, 2022

jpsamaroo commented Feb 25, 2022

giordano Feb 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

giordano commented Mar 1, 2022

jpsamaroo commented Mar 1, 2022

giordano commented Mar 2, 2022

jpsamaroo commented Mar 3, 2022

giordano commented Mar 3, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

giordano Feb 26, 2022 •

edited

Loading