Is it possible to cross-compile with is_clang=false ?

[geisserml]

I was wondering whether it would be possible to cross-compile with gcc instead of clang, to avoid the need for libclang_rt?

The context is, I am attempting to cross-compile for ppc64le, where there is a sysroot but no libclang_rt. [1]

I added a gcc_toolchain("ppc64le") section to build/toolchain/linux/BUILD.gn and manually set the right sysroot path in GN config, but am ending up with the error below.

I wonder, is that because the code really doesn't support cross-compilation with gcc, or am I just missing something here, like a system dependency, or another config that needs to be set?

```
[1/993] CC obj/third_party/libjpeg_turbo/libjpeg12/jcapistd.o
FAILED: obj/third_party/libjpeg_turbo/libjpeg12/jcapistd.o
powerpc64le-linux-gnu-gcc -MD -MF obj/third_party/libjpeg_turbo/libjpeg12/jcapistd.o.d -DNO_GETENV -DNO_PUTENV -DBITS_IN_JSAMPLE=12 -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_INSTRUMENTED_WITH_ASAN=0 -DCR_LIBCXX_REVISION=f034fd5662d033c281ab6a9b45164066ddd18809 -DCR_SYSROOT_KEY=20250129T203412Z-1 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DMANGLE_JPEG_NAMES -I../.. -Igen -I../../buildtools/third_party/libc++ -I../../third_party/libjpeg_turbo/src -Wall -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -Wno-comments -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -fno-strict-overflow -fno-ident -fno-strict-aliasing -fstack-protector -funwind-tables -fPIC -pipe -pthread -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -O2 -fdata-sections -ffunction-sections -fno-math-errno -fno-omit-frame-pointer -g0 -fno-builtin-abs -fvisibility=hidden -std=gnu11 --sysroot=../../build/linux/debian_bullseye_ppc64el-sysroot -c ../../third_party/libjpeg_turbo/src/jcapistd.c -o obj/third_party/libjpeg_turbo/libjpeg12/jcapistd.o
In file included from /usr/lib/gcc/powerpc64le-linux-gnu/12/include/stdint.h:9,
                 from ../../third_party/libjpeg_turbo/src/jconfigint.h:41,
                 from ../../third_party/libjpeg_turbo/src/jinclude.h:26,
                 from ../../third_party/libjpeg_turbo/src/jcapistd.c:21:
../../build/linux/debian_bullseye_ppc64el-sysroot/usr/include/stdint.h:26:10: fatal error: bits/libc-header-start.h: No such file or directory
   26 | #include <bits/libc-header-start.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```

I also tried target_cpu = "arm" to rule out it's due to unhandled architecture, but am running into the same issue when is_clang = false is set. With default is_clang = true it works, though.

[1]: cf. https://groups.google.com/g/pdfium/c/z1jKcpqtXpc/m/0uc5CBEyAgAJ

[geisserml]

Another test with target_cpu = "x86" and is_clang = false produced this error:

```

FAILED: x64/obj/third_party/nasm/nasm/eval.o
gcc -MMD -MF x64/obj/third_party/nasm/nasm/eval.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_INSTRUMENTED_WITH_ASAN=0 -DCR_LIBCXX_REVISION=f034fd5662d033c281ab6a9b45164066ddd18809 -DCR_SYSROOT_KEY=20250129T203412Z-1 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DHAVE_CONFIG_H -I../.. -Ix64/gen -I../../buildtools/third_party/libc++ -I../../third_party/nasm -I../../third_party/nasm/asm -I../../third_party/nasm/disasm -I../../third_party/nasm/include -I../../third_party/nasm/output -I../../third_party/nasm/x86 -fno-strict-overflow -fno-ident -fno-strict-aliasing -fstack-protector -funwind-tables -fPIC -pipe -pthread -m64 -msse3 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -O2 -fdata-sections -ffunction-sections -fno-math-errno -fno-omit-frame-pointer -g0 -fno-builtin-abs -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -Wno-comments -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -std=gnu11 --sysroot=../../build/linux/debian_bullseye_amd64-sysroot -c ../../third_party/nasm/asm/eval.c -o x64/obj/third_party/nasm/nasm/eval.o
In file included from ../../build/linux/debian_bullseye_amd64-sysroot/usr/include/inttypes.h:25,
                 from ../../third_party/nasm/include/compiler.h:81,
                 from ../../third_party/nasm/asm/eval.c:38:
../../build/linux/debian_bullseye_amd64-sysroot/usr/include/features.h:461:12: fatal error: sys/cdefs.h: No such file or directory
  461 | #  include <sys/cdefs.h>
      |            ^~~~~~~~~~~~~
```

I am also not sure why it says "x64" and "--sysroot=../../build/linux/debian_bullseye_amd64-sysroot" despite my passing target_cpu = "x86" ...

[geisserml]

Okay, I finally managed to cross-compile ppc64le with clang after all.
I realized I could just get the libclang_rt.builtins.a prebuilt from debian [1] so I don't need to dive into how to cross-compile them.
It's not ideal though, as I guess the minor version does not match up exactly. I hope this won't cause issues.

Also had to apply a patch, derived from Marvin Gießing's work, which is attached. This is against pdfium 7191.

I tested the resulting pypdfium2 wheel in a manylinux2014 container and it seems to work.

[1]: https://packages.debian.org/sid/ppc64el/libclang-rt-21-dev/download