Page MenuHomeFreeBSD

graphics/libGLU: Update to 9.0.2
ClosedPublic

Authored by kbowling on Jun 22 2021, 8:19 PM.

Details

Summary

There is a report of unmet GL dep after libglvnd if it is built with OPTIONS_X11 unset, inside libGLU: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241568#c4

This update was guided along by Matt Turner (gentoo/freedesktop) and makes libGLU not link to X11 when built with OPTIONS GLVND.

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kbowling created this revision.
tcberner added inline comments.
graphics/libGLU/Makefile
28

^ this looks rather dated, please use the options helpers [1] :)

[1] https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-options

kbowling marked an inline comment as done.

Did you test runtime on Wayland[1] or plain KMS[2]? osmesa seems to be for headless.

[1] Consumers that use GLU + GLEW may need glew-wayland (see its pkg-message)
[2] Similar to kmscube but something with GLU

Did you test runtime on Wayland[1] or plain KMS[2]? osmesa seems to be for headless.

[1] Consumers that use GLU + GLEW may need glew-wayland (see its pkg-message)
[2] Similar to kmscube but something with GLU

I did not, but I did code inspection and the GL calls all look like stuff in the nurbs helpers, I imagine it would work ok. Unsure if vendor GL driver has better implementations. it seems in any common sense case you'd want OPTIONS X11 set on this (even for a a wayland desktop since most people want xwayland). Would you prefer I make the option a RADIO to select X11 vs OSMESA or something?

Sent a mail to Matt Turner (gentoo/nvidia/mesa) to get some clarification.

I am not part of x11@, but I think it looks fine. I won't "approve" so someone from x11@ can do it.

Add a dep on egl so we get needed mesa headers.

Matt's suggestion is what @jbeich suggested in PR241568, I'll get a patch to freedesktop and amend this PR if it passes his review:

No, I don't think that's what you want to do. OSMesa is a kludge from
before a time when all 3D APIs had off-screen rendering.

What we should do is update GLU's configure.ac to attempt to use
libOpenGL rather than libGL, perhaps with an --enable-libglvnd
configuration option.

See https://gitlab.freedesktop.org/mesa/glu/-/blob/master/configure.ac#L77

If you want to submit a merge request I'll be happy to review it and
tag a new release.

kbowling retitled this revision from graphics/libGLU: Support !X11 builds to graphics/libGLU: Update to 9.0/2.
kbowling edited the summary of this revision. (Show Details)
kbowling edited the test plan for this revision. (Show Details)
kbowling retitled this revision from graphics/libGLU: Update to 9.0/2 to graphics/libGLU: Update to 9.0.2.Jun 24 2021, 10:44 PM
zeising requested changes to this revision.Jun 25 2021, 9:58 AM
zeising added a subscriber: zeising.
zeising added inline comments.
Mk/Uses/gl.mk
5

Why is this new dep needed?
Please keep it as small letters, all the others are, and I think that throughout the ports tree, most USE_* are as well.

graphics/libGLU/Makefile
20–21

Is there a reason libglvnd is made optional? I haven't looked at all the other GL related ports, but at least in mesa it is not made optional.

This revision now requires changes to proceed.Jun 25 2021, 9:58 AM
graphics/libGLU/Makefile
20–21

libglvnd is optional in mesa-devel and transparent in all non-mesa ports, see GL_DEFAULT machinery. A quick fix here is to switch USE_GL=gl to USE_GL=egl but a proper fix would be to rename USE_GL=gl to USE_GL=glx then re-introduce USE_GL=gl for pure OpenGL consumers that can use libOpenGL.so.

kbowling added inline comments.
Mk/Uses/gl.mk
5

It's a new library that corrects sins of the past and is only provided by libglvnd for now (and hopefully ever but who knows what future vendors may do), see https://gitlab.freedesktop.org/glvnd/libglvnd#architecture the tl;dr is libOpenGL is OpenGL without X11 (GLX).

I like the casing here because that's the new library's name and throwing that away de-emphasizes the library name. I find the weird mixmatched casing of the libs above it awkward and unfortunate. Since it's a new dep let's leave it like this.

graphics/libGLU/Makefile
20–21

This is the proper fix right now, we can make libglvnd the only GL provider in 1-2 months if there is no long tail fallout but I want it to bake like this for the quarterly.

EGL is something entirely different, libGLU should use libOpenGL when available and the meta build system (ports) shall clearly communicate it.

libGL is OpenGL + GLX. libOpenGL is a new library that comes from libglvnd cleanup for exactly the case we are solving here in libGLU.

Again, libGL == libGLX + libOpenGL. We don't get to redefine that and this is the right fix per upstream.

kbowling marked 2 inline comments as done.

Is there some variant of this that can be checked in like dropping Mk/Uses/gl.mk changes or can someone else do it to their liking?

Too much complexity for a single port. Maybe land only the update for now.

imp added inline comments.
Mk/Uses/gl.mk
5

The "OpenGL" is a bit out of place. "opengl" would be more in line with the standard practices.

Please update porter's handbook
Please remove port option for libglvnd

kbowling marked an inline comment as done.

Commenting that zeising approved with the changes mentioned above on x11 call

This revision was not accepted when it landed; it landed in state Needs Review.Jun 29 2021, 1:26 AM
This revision was automatically updated to reflect the committed changes.