Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[engine] All Linux builds default to building GLFW (X11 dep) #95711

Closed
jwinarske opened this issue Dec 23, 2021 · 26 comments · Fixed by flutter/engine#30917
Closed

[engine] All Linux builds default to building GLFW (X11 dep) #95711

jwinarske opened this issue Dec 23, 2021 · 26 comments · Fixed by flutter/engine#30917
Assignees
Labels
customer: going engine flutter/engine repository. See also e: labels. P0 Critical issues such as a build break or regression r: fixed Issue is closed as already fixed in a newer version team Infra upgrades, team productivity, code health, technical debt. See also team: labels. waiting for PR to land (fixed) A fix is in flight

Comments

@jwinarske
Copy link

Yesterday 32-bit arm engine builds started failing

../../third_party/glfw/src/monitor.c -o obj/third_party/glfw/src/glfw.monitor.o
| In file included from ../../third_party/glfw/src/monitor.c:28:
| In file included from ../../third_party/glfw/src/internal.h:169:
| ../../third_party/glfw/src/x11_platform.h:36:10: fatal error: 'X11/Xlib.h' file not found
| #include <X11/Xlib.h>
|          ^~~~~~~~~~~~
| 1 error generated.

Master

Looks like glfw client has been enabled by default. This is the only scenario that does this. It should default to not building glfw client. X11 is not always available nor desirable.

Complete build log available here:
https://github.com/meta-flutter/meta-flutter/runs/4613236435?check_suite_focus=true

@darshankawar darshankawar added the in triage Presently being triaged by the triage team label Dec 23, 2021
@darshankawar
Copy link
Member

Labeling it for further input from the team.

/cc @stuartmorgan

@darshankawar darshankawar added e: glfw GLFW desktop embedding engine flutter/engine repository. See also e: labels. passed first triage team Infra upgrades, team productivity, code health, technical debt. See also team: labels. and removed passed first triage in triage Presently being triaged by the triage team labels Dec 23, 2021
@stuartmorgan stuartmorgan removed the e: glfw GLFW desktop embedding label Dec 23, 2021
@stuartmorgan
Copy link
Contributor

This isn't coming from the GLFW Linux embedding, it's the engine example.

@jwinarske
Copy link
Author

Someone checked something in two days ago that affected this. I run nightly builds and it looks like the glfw client (example) started getting built by default. This shouldn't be the case.

@stuartmorgan
Copy link
Contributor

Presumably it was flutter/engine#30442

@jwinarske
Copy link
Author

Yep.

@chinmaygarde this should not build by default. It's dependent on X11 even though glfw can be built for others. Also glfw sucks for embedded Linux as it requires lots of rework...

@zanderso zanderso added the P1 High-priority issues at the top of the work list label Jan 4, 2022
@jwinarske
Copy link
Author

This is now blocking all builds - meta-flutter, AGL, and Toyota internal builds. X11 cannot be a dependency for Linux builds.

@csells
@cmc5788

@jwinarske
Copy link
Author

Any glfw/x11 dependency should be behind --no-build-glfw-shell

@csells csells added customer: going P2 and removed P1 High-priority issues at the top of the work list labels Jan 15, 2022
@chinmaygarde
Copy link
Member

chinmaygarde commented Jan 19, 2022

Stuart is right. The example GLFW embedder (not the one in the shell) was not being built earlier at all. The linked patch started building it under the assumption that linux hosts will be able to build the GLFW dependency. We need to be able to distinguish between the linux hosts that can build the example and those that can't. The GLFW shell is not the same as the examples however. I can add another gn flag (say --build-embedder-examples) that can be toggled. @jwinarske: Would that work? You would have to say --no-build-embedder-examples.

chinmaygarde added a commit to chinmaygarde/flutter_engine that referenced this issue Jan 19, 2022
We recently started building the examples in the `examples` directory. However,
those examples use the GLFW dependency that not all embedders have. This broke
their build. Those builder may now use `--build-embedder-examples` to avoid
building the examples.

Fixes flutter/flutter#95711
@jwinarske
Copy link
Author

jwinarske commented Jan 20, 2022

@chinmaygarde Whatever we use to control it, the x11 dependency has to be disabled by default, opposed to enabled. Otherwise it's broken until fixed. If we use --build-embedder-examples then it should default to false.

When an unknown argument is passed to flutter/tools/gn it causes build to fail, which is the primary reason why the breaking change should default to false. Otherwise everything downstream has to account when the flag can be introduced. Really the best case for all the downstream deps is to use a "revert" patch workaround. Something seemingly so simple causes hours of work for many people.

@jwinarske
Copy link
Author

@chinmaygarde is this issue going to roll to beta channel, or can that be prevented?

@cmc5788
Copy link
Contributor

cmc5788 commented Jan 20, 2022

@chinmaygarde -- I think the issue is that the commit that made x11 a dep for all Linux builds has already rolled to beta. A flag that disables it can't be used until that flag also rolls to beta. As @jwinarske mentioned, x11 deps are breaking for our build, so in the interim between this behavior being introduced and this flag rolling to beta, we have no solution.

I'd tend to agree that x11 deps being introduced to Linux default build is a breaking change and should be cherrypicked off beta as the default behavior (and is probably also not ideal as a default generally), but if not, we'd at least need the flag available on beta as a cherrypick hotfix to unbrick our builds.

Sorry for the urgency. We'll investigate adding a customer test to guard against this kind of regression in the future. But for now this is a big problem for us.

@zanderso
Copy link
Member

@jwinarske @cmc5788 flutter/engine#30442 is on beta channel. flutter/engine#30917 may not be ideal, but if it is sufficient to unblock you, we can get it cherry-picked to beta. I believe the next hotfix release will be next week.

@darshankawar darshankawar added the r: fixed Issue is closed as already fixed in a newer version label Jan 20, 2022
@jwinarske
Copy link
Author

@zanderso @chinmaygarde
The "proposed/merged" fix is not acceptable. It defaults to building GLFW. If GLFW had flags to determine backend then it would be usable, but GLFW is hardcoded to X11. The standard backends for embedded Linux are:

  1. Wayland (commercial)
  2. DRM/KMS (commercial)
  3. X11/XCB (mostly non-commercial, desktop compatibility, legacy, hobby)

Because the build enables GLFW by default, we would need to track when we could use the flag verses not. Adding a "unknown" flag to flutter/tools/gn causes it to fail, opposed to be ignored. So everything downstream that does not have X11 is broken. The proper logic to unblock downstream is to disable the default build of a hardcoded (X11) GLFW. This line should default to false: https://github.com/chinmaygarde/flutter_engine/blob/02873f210a09083146647647b2df3b81afe58864/examples/examples.gni#L8

AGL reported this morning their Flutter builds are officially broken.

We need this resolved ASAP, as well as a hot fix into beta. I reported this issue 29 days ago, and I was a week late on reporting it.

@csells @cmc5788

@jwinarske jwinarske changed the title [engine] 32-bit engine build is defaulting to build glfw (x11 dep) [engine] All Linux builds default to building GLFW (X11 dep) Jan 20, 2022
@zanderso zanderso added P2 and removed P2 labels Jan 20, 2022
@zanderso
Copy link
Member

@jwinarske I'm very sorry for the trouble, but I'd like to understand better why the flag added by flutter/engine#30917 won't work for you. Are you using/building several different versions/channels of Flutter? If so, which ones and for what purposes?

flutter/engine#30946

@jwinarske
Copy link
Author

@zanderso From master to beta, the build fails. For any channel that does not support the new flag, the build fails if the flag is set. Setting up CI to track if this commit is present so we know when we can add the flag is not acceptable. The flag that enables building GLFW needs to be disabled by default in order to unblock downstream builds.

@zanderso
Copy link
Member

zanderso commented Jan 20, 2022

@jwinarske IIUC, if we cherry-pick flutter/engine#30917 to beta, then the flag will be consistently present on both master and beta. Sorry if my question above was unclear, but what I'd like to learn is whether there's anything about your setup that means that even if the flag is on both master and beta, you'll still be blocked.

@cmc5788
Copy link
Contributor

cmc5788 commented Jan 20, 2022

@zanderso -- thank you for following up on this! Let me know if the following explanation makes a bit more sense;

The primary concern is that adding a flag to opt out of x11 once hot-fixed is not super practical for us since we have a number of downstream customers (such as AGL) relying on our Flutter builds that are not directly consuming a source we can adjust in a single place.

It's not a matter of adding this flag in one place; we have to advise a number of downstream customers in cases where we can't just directly step in and apply patches, in partner codebases and not just internally.

For that reason we'd really strongly prefer to see the default behavior on all channels hot-fixed to the non-broken builds as default, as opposed to having to opt into the corrected behavior and then advise to propagate flag to all downstream customer builds, even if it requires an additional commit (one-line change) now to change the default before hot-fixing. We'd prefer to see that commit if it enables the more ideal behavior for Linux customers instead of piling on.

@zanderso
Copy link
Member

@cmc5788 That makes sense. Thanks for the explanation. It would be helpful if you can confirm that applying flutter/engine#30917 and then flutter/engine#30946 to the current beta channel resolves the issue.

@cmc5788
Copy link
Contributor

cmc5788 commented Jan 20, 2022

@zanderso -- It looks correct; when it's on master we'll be able to run a canary build confirming.

@zanderso
Copy link
Member

@cmc5788 Both are landed on master.

@cmc5788
Copy link
Contributor

cmc5788 commented Jan 20, 2022

Thanks! It looks good and we'll report back on canary build status. Thanks again for your responsiveness on all of this.

@jwinarske
Copy link
Author

@zanderso canary build on master looks good.
https://github.com/meta-flutter/meta-flutter/runs/4888483652

@cmc5788
Copy link
Contributor

cmc5788 commented Jan 20, 2022

@jwinarske great news! if that can be cherrypicked to channels at some point we should be in good shape?

@jwinarske
Copy link
Author

@cmc5788 Yes, now we just need the cherry picking for channels affected.

@zanderso
Copy link
Member

FYI @iskakaushik re: customer test discussion.

@godofredoc @devoncarew @itsjustkevin for cherry-pick this needs flutter/engine@db06032 followed by flutter/engine@0ae4613

jwinarske added a commit to meta-flutter/meta-flutter that referenced this issue Jan 22, 2022
@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 10, 2022
HidenoriMatsubayashi pushed a commit to HidenoriMatsubayashi/meta-flutter that referenced this issue Feb 14, 2022
HidenoriMatsubayashi pushed a commit to sony/meta-flutter that referenced this issue Feb 14, 2022
* Fix depot_tools error
* Fix flutter/flutter#95711
@flutter-triage-bot flutter-triage-bot bot added P0 Critical issues such as a build break or regression and removed P2 labels Jun 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
customer: going engine flutter/engine repository. See also e: labels. P0 Critical issues such as a build break or regression r: fixed Issue is closed as already fixed in a newer version team Infra upgrades, team productivity, code health, technical debt. See also team: labels. waiting for PR to land (fixed) A fix is in flight
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants