Building on X11/nVIDIA, USE_ANGLE_WEBGL=OFF I don't have libgbm, and building webkit for me has always succeeded without it. GL seems to work fine; for example, I can run the tanks demo. Now my build fails because GBM does not exist on my system. After removing the GBM dependency introduced by r290506, webkit still builds and runs fine. Is this going to be a hard dependency going forward, because (older) nVIDIA drivers maybe don't have it.
(In reply to Jim Mason from comment #0) > Building on X11/nVIDIA, USE_ANGLE_WEBGL=OFF > > I don't have libgbm, and building webkit for me has always succeeded without > it. GL seems to work fine; for example, I can run the tanks demo. Now my > build fails because GBM does not exist on my system. > > After removing the GBM dependency introduced by r290506, webkit still builds > and runs fine. > > Is this going to be a hard dependency going forward, because (older) nVIDIA > drivers maybe don't have it. There has been some talk internally about making GBM unneeded at build time, and relying on dlopening() it where needed/available at runtime. I wonder if we could make the GBM dependency optional with USE_ANGLE_WEBGL disabled in the meantime, though 🤔️
No, because it will be used outside of ANGLE too.
Thanks for the report! In the patch we forgot to add the ` if (USE_ANGLE_WEBGL) ` around the find_package option, but the compilation is correctly guarded. That is why it stops when the library is not found in the system but it compiles and works correctly if you remove the find_package manually, the not ANGLE solution does not require gbm. This was fixed in a commit later here: https://trac.webkit.org/changeset/289575/webkit Just try to update to that commit and it should work. Anyway, As Zan is explaining we are planning to make ANGLE/GBM solution the default one in the near future and focus on working/supporting just that technology for the future. We will maintain the old solution for some time though.
(In reply to Alejandro G. Castro from comment #3) > Thanks for the report! > > In the patch we forgot to add the ` if (USE_ANGLE_WEBGL) ` around the > find_package option, but the compilation is correctly guarded. That is why > it stops when the library is not found in the system but it compiles and > works correctly if you remove the find_package manually, the not ANGLE > solution does not require gbm. This was fixed in a commit later here: > > https://trac.webkit.org/changeset/289575/webkit > Oops sorry, this commit was previous to that one :-), so yep, you have to move back to the previous commit because we are already moving to use the technology outside ANGLE. Sorry again for the confusion. I'm keeping the bug open to check more comments about the situation in your configuration for the new solutions. Thanks again!
We can't add required packages like r290506. New dependencies should be optional.
Even if it makes video playback and WebGL optional down the line?
(In reply to Adrian Perez from comment #1) > (In reply to Jim Mason from comment #0) > > Building on X11/nVIDIA, USE_ANGLE_WEBGL=OFF > > > > I don't have libgbm, and building webkit for me has always succeeded without > > it. GL seems to work fine; for example, I can run the tanks demo. Now my > > build fails because GBM does not exist on my system. > > > > After removing the GBM dependency introduced by r290506, webkit still builds > > and runs fine. > > > > Is this going to be a hard dependency going forward, because (older) nVIDIA > > drivers maybe don't have it. > > There has been some talk internally about making GBM unneeded at build > time, and relying on dlopening() it where needed/available at runtime. > This is the end goal but hasn't been started yet. The two libraries were added as deps to not block the ongoing work.
(In reply to Zan Dobersek from comment #6) > Even if it makes video playback and WebGL optional down the line? With dlopen()-y solution these two would end up being optional at runtime.
(In reply to Zan Dobersek from comment #6) > Even if it makes video playback and WebGL optional down the line? No, that would be a regression.
I've commented in the other bug but I'll add it here too to make sure everyone is updated, this week we discussed the way to move forward with the new buffer sharing architecture and we are going to add a new define to guard the gbm code. This will allow to compile without it using the current architecture.
Resolved with changes in bug #237974.
(In reply to Zan Dobersek from comment #11) > Resolved with changes in bug #237974. Confirmed, thanks!
This has returned because of this commit: https://commits.webkit.org/254947@main
(In reply to Jim Mason from comment #13) > This has returned because of this commit: > > https://commits.webkit.org/254947@main Thanks for reporting! Would you mind creating a different bug and closing this one, it is better for us to handle it that way because it is a different problem added later.
Reopening in new issue as requested.