Update the buildroot to use our own clang when building with bitcode-marker

Xcode knows how to massage the .S files we compile for libpng and Dart without explicitly adding .section __LLVM,__asm to the source. If we want to use the clang toolchain (and, more importantly, support GOMA builds), we need to patch those soures upstream.

Dart has decided the file is no longer needed for the compilation target and will remove it.

Not sure when that happened but it's been removed.

Since writing this, something else will require updating - we're compiling some Dart code somewhere and will need to add -fembed-bitcode or somesuch.

Still have the libpng issue as well.

It would also be interesting if ther ewas just some way to tell LLVM clang to do the same thing Xcode clang does in this case.

pnggroup/libpng#319 merged May 2020. Is this unblocked?

Asking because this may enable us to use goma and speed up the engine builds per https://github.com/flutter/buildroot/blob/33358ba597f875f6646522fd4ea86c1b31404d77/build/toolchain/clang.gni#L28-L29.

Unless I'm misunderstanding the implication.

That needs to get rolled into https://flutter.googlesource.com/third_party/libpng/+/refs/heads/master/arm/filter_neon.S and then updated in the DEPS file to be pulled into the engine.

@gw280

\cc @gw280

@dnfield

@dnfield I tried to roll libpng forward here https://flutter-review.googlesource.com/c/third_party/libpng/+/14320. To patch it in do:

$ cd third_party/libpng
$ git checkout master
$ git cl patch 14320

Building for Android arm64 fails on the .section __LLVM,__asm directive

$ ./flutter/tools/gn --runtime-mode debug --android --android-cpu arm64
$ ninja -C out/android_debug_arm64
FAILED: obj/third_party/libpng/arm/libpng.filter_neon.o 
/usr/local/google/home/zra/flutter_goma/gomacc ../../buildtools/linux-x64/clang/bin/clang -MD -MF obj/third_party/libpng/arm/libpng.filter_neon.o.d -DPNG_ARM_NEON_OPT=2 -DUSE_OPENSSL=1 -DUSE_OPENSSL_CERTS=1 -DANDROID -DHAVE_SYS_UIO_H -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D__compiler_offsetof=__builtin_offsetof -Dnan=__builtin_nan -D_LIBCPP_DISABLE_AVAILABILITY=1 -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../.. -Igen -I../../third_party/libcxx/include -I../../third_party/libcxxabi/include -I../../third_party/libcxxabi/include -I../../third_party/libpng -I../../third_party/zlib -fno-strict-aliasing -fPIC -pipe -fcolor-diagnostics -ffunction-sections -funwind-tables -fno-short-enums -nostdinc++ -mno-outline-atomics --target=aarch64-linux-android -fno-strict-aliasing -fPIC -pipe -fcolor-diagnostics -ffunction-sections -funwind-tables -fno-short-enums -nostdinc++ -mno-outline-atomics --target=aarch64-linux-android -Wall -Wextra -Wendif-labels -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-deprecated-copy -Wno-psabi -Wno-non-c-typedef-for-linkage -Wno-range-loop-construct -isystem../../third_party/android_tools/ndk/sources/android/support/include -isystem../../third_party/android_tools/ndk/sysroot/usr/include/aarch64-linux-android -D__ANDROID_API__=22 -fvisibility=hidden --sysroot=/usr/local/google/home/zra/flutter/engine/src/third_party/android_tools/ndk/sysroot -Wstring-conversion -Wnewline-eof -Oz -fno-ident -fdata-sections -ffunction-sections -fomit-frame-pointer -flto -g2 -Wno-sign-compare  -c ../../third_party/libpng/arm/filter_neon.S -o obj/third_party/libpng/arm/libpng.filter_neon.o
../../third_party/libpng/arm/filter_neon.S:24:17: error: expected string in directive
.section __LLVM,__asm

Hm. Also discussed here pnggroup/libpng#347

This worked when I added it, although I can't remember if I tested the Android build or just the iOS/macOS host. I'll try to look into it.

pnggroup/libpng#383

The issue about .section __LLVM,__asm has been fixed in clang: https://bugs.llvm.org/show_bug.cgi?id=39659, and has rolled into the Engine, so I will take a crack at using our clang for debug and profile.

Done in flutter-team-archive/buildroot#459

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.

Navigation Menu

Repository navigation

Update the buildroot to use our own clang when building with bitcode-marker #39281

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Update the buildroot to use our own clang when building with bitcode-marker #39281

Description

Activity

dnfield commented on Sep 21, 2019

dnfield commented on Oct 31, 2019

dnfield commented on Oct 31, 2019

dnfield commented on Jan 28, 2020

jmagman commented on May 12, 2021

jmagman commented on May 12, 2021

dnfield commented on May 12, 2021

jmagman commented on May 12, 2021

zanderso commented on Jun 2, 2021

dnfield commented on Jun 2, 2021

dnfield commented on Jun 2, 2021

zanderso commented on Jun 2, 2021

zanderso commented on Jun 7, 2021

github-actions commented on Jul 31, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions