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

57 views
Skip to first unread message

geisserml

unread,
Nov 1, 2025, 7:03:57 PM11/1/25
to pdfium
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.

geisserml

unread,
Nov 1, 2025, 7:27:10 PM11/1/25
to pdfium
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

unread,
Nov 3, 2025, 2:05:08 PM11/3/25
to pdfium
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.
ppc64le_cross.patch

geisserml

unread,
Nov 11, 2025, 10:53:38 AM11/11/25
to pdfium
As a related question: would it be possible to use the clang compiler with libgcc instead of libclang_rt builtins?
Is there perhaps a config variable for doing so, or if not, could this be added?
I was looking into [1] for a compiler that runs on the host architecture out of an emulated container, but they don't build the target libclang_rts (nor would it be easy to do so), and instead recommend using the builds with libgcc, see [2].

[1]: https://github.com/mayeut/static-clang-images
[2]: https://github.com/mayeut/static-clang-images/issues/6#issuecomment-3517273371 ff.

geisserml

unread,
Nov 11, 2025, 1:17:32 PM11/11/25
to pdfium
Ok, I think we've figured out how to do it. See resolution in the thread referenced above.

geisserml

unread,
Dec 22, 2025, 2:14:47 PM12/22/25
to pdfium
As to the initial question, I can now say the answer is also yes (my colleague recently cross-compiled pdfium with is_clang=false, so I investigated again).
Turns out the problem was just me being stuck with pdfium 7191. It works fine with newer pdfium, e.g. 7592.

Also, building for ppc64(le) is now really straightforward, using the existing `target_cpu=ppc64` handlers. Thank you very much for the apparent improvements here.
Just two minor fixes are still needed on our side:
- patching //build/config/sysroot.gni, or manually setting `sysroot=//build/linux/debian_bullseye_ppc64el-sysroot`
- patching //build/linux/sysroot_scripts/install-sysroot.py, or manually invoking it with `ppc64le` instead of just `ppc64`
Reply all
Reply to author
Forward
0 new messages