Add cstdint header #10
Conversation
Hmm, this builds fine for me on fedora 43's gcc 15.2.1 -- what exactly are you building with, and what are you building? (I do get deprecated warnings on std::wstring_convert that we'll need to look into sooner or later, but it does build all the way for me) |
|
Hi @martinetd, I'm building this for a yocto project on aarch64. I haven't tried building it for x86_64 though. I've tested this patch using the following bitbake command in a project where meta-flutter is included. There might be some of the includes that aren't necessary because cstdint is included indirectly, I just added the include to all source files that included Do you see any issues with merging this? I can check the code for redundant includes if you want. I've also submitted this patch as a patch to the meta-flutter layer meta-flutter/meta-flutter#741. |
|
It's just that I don't like merging what I don't understand, I was about to ask if you already had 95f56d9 applied... but that's your patch, so I assume it wasn't enough 😅 In general extra includes add up to build time so I'd rather be precise about it if it's not too much effort, otherwise I guess this is fine, I'll try to reproduce without bitbake... By the way, note by default flutter-embedded-linux builds with clang, not gcc, but I also have the latest 21.1.8 here, and I also tried cross compiling to aarch64, so I'm not quite sure what it could be.. (EDIT: and I did try kludging the CMakeLists.txt to build with gcc successfully as well :|) |
|
On Thu Feb 5, 2026 at 2:23 PM CET, Dominique Martinet wrote:
martinetd left a comment (flutter-elinux/flutter-embedded-linux#10)
It's just that I don't like merging what I don't understand, I was about to ask if you already had 95f56d9 applied... but that's your patch, so I assume it wasn't enough 😅
That I can get behind. I only built the drm-gbm-backend binary with that
patch, so this should be considered a follow-up to that which fixes all
of the targets (those that are in meta-flutter anyways).
In general extra includes add up to build time so I'd rather be precise about it if it's not too much effort, otherwise I guess this is fine, I'll try to reproduce without bitbake...
True. Given that you cannot reproduce it, I'm actually more inclined to
include all of the additions, as someone making changes would probably
be able to compile successfully, and having this patch makes it
probably-less-likely-tm to break for others
I found at least this post which hit the same (albeit being quite old)
https://www.reddit.com/r/archlinux/comments/13j4zgs/uint8_t_does_not_name_a_type_and_glibcxx_3430_not/
|
While I'd tend to agree in general, I'm honestly not familiar enough with the project yet, so I really want to understand even if it's a bit slower -- thanks for putting up with me! So yesterday I had "only" tried building all the backends and examples in the repo, so from the list of targets you gave it should have been the same.. but I went one step further and tried to just compile each file individually in a brute-force approach: And this did turn half a dozen of errors, so I've pushed in your branch something that fixed them -- what do you think? So I still don't understand your errors, but my guess is that meta-flutter either has patches or uses a slightly different tree that has includes in a different order or something? But either way it should no longer fail on our headers 😅 |
martinetd
force-pushed
the
master
branch
2 times, most recently
from
3f54966 to
0b256e4
Compare
This allows compiling each individual file manually, so should fix any problem with newer compilers. Reported-by: Frede Hoey Braendstrup <frede@vokalo.io>
|
On Fri Feb 6, 2026 at 1:00 AM CET, Dominique Martinet wrote:
martinetd left a comment (flutter-elinux/flutter-embedded-linux#10)
> True. Given that you cannot reproduce it, I'm actually more inclined to
include all of the additions, as someone making changes would probably
be able to compile successfully, and having this patch makes it
probably-less-likely-tm to break for others
While I'd tend to agree in general, I'm honestly not familiar enough with the project yet, so I really want to understand even if it's a bit slower -- thanks for putting up with me!
No worries, turns out you we're right to be concerned. While it doens't
hurt anything (except maybe build time), It also doens't fix anything.
This repo is used as the base source for a few different yocto recipes,
building each of the targets from my other comment, and apparently I had
only applied my initial patch from #2 to one of them.
I should have investigated further before submitting a PR. Sorry for the
noise.
I do think that your patch might be worthwhile to commit regardless as.
|
No worry, glad this was figured out
Yes, let's move forward with it -- I've reopened it as #12 |
2 participants
GCC 15.2 doens't have uint8_t defined by default, so all files using it should include cstdint in C++ files or stdint.h in C files.