It appears that USE_QT5 always/often induces the unneeded OpenGL dependency. The recipe to cure this has been floated around: to add "LDFLAGS+=-Wl,--as-needed" in the individual ports. For example, this was done in this submission: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224470 Routinely adding such LDFLAGS to ports seems to be wrong to me. If --as-needed changes the list of actually linked libraries, then the list needs to be fixed instead? Does USE_QT5=gui always supply wrong link flags, erroneously containing the opengl lib? Is this a problem of framework, or Qt ports, or Qt upstream?
This is not blocking anything, you can add the LDFLAGS to the individual port.
--as-needed also eliminates XORG dependencies in the above-mentioned submission. So xorg libs supplied by USE_QT5 are also bogus.
qt5-gui depends on both GL and X11; the platform abstractions loaded by qt5-gui are what is actually going to call into GL. So the dependency is only "unneeded" if you have a GUI application that isn't going to run on X11 or GL, ever. I suppose if you're into Qt Automotive on FreeBSD with only the framebuffer that makes sense.
I'd prefer to leave this open with an explicit "needs information" tag for a bit, but Bugzilla doesn't seem to support that state. Setting to "in progress" with intent to close soon. This PR no longer blocks PR #224470, which was committed with the as-needed flags. The comment in the committed Makefile points to this PR. But what is the actual problem? This PR just states that some dependencies are unneeded, some link flags are wrong, without saying what, or why it, is actually wrong. A concrete example and some explanation would go a long way; otherwise the only real response can be (paraphrased from comment #1) "yeah, just add as-needed if you feel like it".
Yes, it's not a hard error, just unnecessary dependencies. I'll find an example and will add more explanation.
I think adding the flags to the offending child-ports is the better solution.