Cross compiling Chromium for linux arm64 fails

[Shubham Kanodia]

I've been trying to cross compile for linux arm64 from a linux x86 machine (ubuntu), but I run into this error —

```

[88/41434] SOLINK ./libwtf.so
FAILED: libwtf.so libwtf.so.TOC
python3 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="../../third_party/llvm-build/Release+Asserts/bin/llvm-readelf" --nm="../../third_party/llvm-build/Release+Asserts/bin/llvm-nm"  --sofile="./libwtf.so" --tocfile="./libwtf.so.TOC" --output="./libwtf.so" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared -Wl,-soname="libwtf.so" -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,--color-diagnostics -Wl,--no-call-graph-profile-sort --target=aarch64-linux-gnu -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ --sysroot=../../build/linux/debian_bullseye_arm64-sysroot -Wl,-rpath=\$ORIGIN -L../../build/linux/debian_bullseye_arm64-sysroot/usr/lib/aarch64-linux-gnu -o "./libwtf.so" @"./libwtf.so.rsp"
ld.lld: error: undefined symbol: partition_alloc::internal::page_characteristics
>>> referenced by partitions.cc
>>>               obj/third_party/blink/renderer/platform/wtf/wtf/partitions.o:(partition_alloc::internal::PageAllocationGranularity())
>>> referenced by partitions.cc
>>>               obj/third_party/blink/renderer/platform/wtf/wtf/partitions.o:(partition_alloc::internal::PageAllocationGranularity())
>>> referenced by partitions.cc
>>>               obj/third_party/blink/renderer/platform/wtf/wtf/partitions.o:(partition_alloc::internal::PageAllocationGranularity())
>>> referenced 3 more times
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
[121/41434] CXX obj/ui/aura/aura/window.o

```

My args.gn is —

```

enable_nacl=false
symbol_level=0
blink_symbol_level=0
v8_symbol_level=0
target_os = "linux"
target_cpu="arm64"
cc_wrapper="env CCACHE_SLOPPINESS=time_macros ccache"
v8_target_cpu = "arm64"
treat_warnings_as_errors = false

```

What could be going wrong here?

[Takuto Ikuta]

Does your build compile this line?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/25fe7258-fd91-48e1-82df-6c3879a88e6en%40chromium.org.

[Avi Drissman]

FYI, this code is very new, landed in https://chromium-review.googlesource.com/c/chromium/src/+/3545665. If this continues to be an issue, file a bug and I will ping in the author.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALNjmModKKuMjZ9noGpHjOYd8JaunGA-3%2B46DV79Ln9drGKoQw%40mail.gmail.com.

[Avi Drissman]

Jorrit Jongma, the author of this patch, writes me:

I can’t post to that link and do not immediately have time to investigate more in-depth, but I did do a quick rebuild:

 

git rebase-update
gclient sync
autoninja -C out/Default chrome

On my Ubuntu x86_64 box this produces binaries that run on my Asahi arm64 install.

 

args.gn:

 

target_cpu = "arm64"

enable_nacl = false

symbol_level = 0

blink_symbol_level = 0

v8_symbol_level = 0

is_debug = false

dcheck_always_on = false

is_official_build = true

cc_wrapper = "ccache"

 

(ccache sloppiness is set to include_file_mtime in env)

 

Not sure what causes the difference, but the possibility of an issue exactly like this is exactly why I wanted to move both the declaration and its implementation to separate files added to base, but the reviewers on the original patch did not seem to like that.

 

Thanks,

Jorrit Jongma

On Wed, Apr 20, 2022 at 11:41 PM Shubham Kanodia <shubham...@gmail.com> wrote:

This was my change to page_allocator_constants.h, after which the compilation went through —

PageAllocationGranularityShift() {
#if BUILDFLAG(IS_WIN) || defined(ARCH_CPU_PPC64)
// Modern ppc64 systems support 4kB (shift = 12) and 64kB (shift = 16) page
// sizes. Since 64kB is the de facto standard on the platform and binaries
// compiled for 64kB are likely to work on 4kB systems, 64kB is a good choice
// here.
return 16; // 64kB
#elif defined(_MIPS_ARCH_LOONGSON)
return 14; // 16kB
#elif BUILDFLAG(IS_APPLE) && defined(ARCH_CPU_64_BITS)
return vm_page_shift;
#elif BUILDFLAG(IS_LINUX) && defined(ARCH_CPU_ARM64)
// arm64 supports 4kb (shift = 12), 16kb (shift = 14), and 64kb (shift = 16)
// page sizes. Retrieve from or initialize cache.
// int shift = page_characteristics.shift.load(std::memory_order_relaxed);
// if (UNLIKELY(shift == 0)) {
// shift = __builtin_ctz((int)PageAllocationGranularity());
// page_characteristics.shift.store(shift, std::memory_order_relaxed);
// }
return 12;
#else
return 12; // 4kB
#endif
}

PAGE_ALLOCATOR_CONSTANTS_DECLARE_CONSTEXPR ALWAYS_INLINE size_t
PageAllocationGranularity() {
#if BUILDFLAG(IS_APPLE) && defined(ARCH_CPU_64_BITS)
// This is literally equivalent to |1 << PageAllocationGranularityShift()|
// below, but was separated out for IS_APPLE to avoid << on a non-constexpr.
return vm_page_size;
#elif BUILDFLAG(IS_LINUX) && defined(ARCH_CPU_ARM64)
// arm64 supports 4kb, 16kb, and 64kb page sizes. Retrieve from or
// initialize cache.
return 1 << PageAllocationGranularityShift();
#else
return 1 << PageAllocationGranularityShift();
#endif
}

[Shubham Kanodia]

So to confirm, if I replace the PageCharacteristics variables with static values, the compilation succeeds (though now I'm having problems running the compiled binary Seg fault).

On Thursday, April 21, 2022 at 8:39:58 AM UTC+5:30 Avi Drissman wrote:

[Shubham Kanodia]

On Thursday, April 21, 2022 at 8:39:58 AM UTC+5:30 Avi Drissman wrote:

[Jorrit Jongma]

Did you try with my args.gn Avi posted above?

I just did a new pull/sync/build, this time for full Chromium instead of just the chrome target, and that worked perfectly on my box.

This is what my build just produced: https://drive.google.com/file/d/1gfba7gOtIEn9Otog9qHg62Ea8YH-aBFI/view?usp=sharing

I'd be curious to know if that one segfaults or works for you. The latter would imply a build rather than code issue.

Have you tried purging your entire ccache, git checkout main, git rebase-update, gclient sync, then autoninja?

[Kristjan Rich]

The simplest solution is to install a VirtuelBox. Then you set them up and connect everything there. If it's the best anyway, your pc stays clean. if you catch four, you can delete it and reinstall a link is below Bro.

https://www.kali.org/

[Qi Tiezheng]

I submitted a patch. https://bugs.chromium.org/p/chromium/issues/detail?id=1346491