Bluetooth unit tests are breaking the build (linker errors)?

[Yves Arrouye]

This is after a git rebase-update of master/origin and a gclient sync. Is this a new issue?

autoninja -C out_${BOARD}/Release unit_tests

...

lld.elf: error: undefined symbol: bluez::FakeBluetoothDeviceClient::FakeBluetoothDeviceClient()
>>> referenced by arc_bluetooth_bridge_unittest.cc
>>>               obj/chrome/browser/chromeos/unit_tests/arc_bluetooth_bridge_unittest.o:(arc::ArcBluetoothBridgeTest::SetUp())

lld.elf: error: undefined symbol: bluez::FakeBluetoothDeviceClient::RemoveAllDevices()
>>> referenced by arc_bluetooth_bridge_unittest.cc
>>>               obj/chrome/browser/chromeos/unit_tests/arc_bluetooth_bridge_unittest.o:(arc::ArcBluetoothBridgeTest::SetUp())

lld.elf: error: undefined symbol: bluez::FakeBluetoothGattServiceClient::FakeBluetoothGattServiceClient()
>>> referenced by arc_bluetooth_bridge_unittest.cc
>>>               obj/chrome/browser/chromeos/unit_tests/arc_bluetooth_bridge_unittest.o:(arc::ArcBluetoothBridgeTest::SetUp())

lld.elf: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
dm-country ~/chromium/src$

[Yves Arrouye]

Ping. Also tried with amd64-generic after another git rebase-update and gclient sync today. Same failure linking unit tests.

[James Cook]

From your out_${BOARD}/Release output directory, it looks like you're building for a Chrome OS device. I'm not sure unit_tests is supposed to compile for real devices. I'm pretty sure unit_tests won't run on a real device.

For Chrome OS, unit_tests is generally built for the linux "emulator" and runs on the host workstation. This is what happens on the linux-chromeos-rel bot (https://ci.chromium.org/p/chromium/builders/ci/linux-chromeos-rel).

FWIW, I can build unit_tests on gLinux with this out/Default/args.gn file:

target_os = "chromeos"
use_goma = true
is_debug = false
dcheck_always_on = true
is_component_build = true
enable_nacl = false
blink_symbol_level = 0
is_chrome_branded = true
enable_cros_libassistant = false

--
--
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/CAFpPgjrwOrFaZY9i79_mENmonoD2%2Bc2FENQ8NxKgQgyLxC3BTw%40mail.gmail.com.

[James Cook]

Oh, and I see the same linker errors you do when trying to build unit_tests using the toolchain for an "eve" chromebook.

[Yves Arrouye]

Thanks. This is why I tried with amd64_generic too. That should build a Linux binary, right, on my gLinuzx machine? The target OS is still Chrome OS, but that is standard for simple Chrome for example.

[Yves Arrouye]

I'll double check the args.gn for my amd64_generic build.

[James Cook]

To run code on the host, just set target_os="chromeos" in args.gn and you're done. I wouldn't try to use the amd64_generic toolchain / board setup. It's possible that amd64_generic used to work on gLinux purely by chance, but it's untested in the chromium CI/CQ. When in doubt, I would try to make my args similar to the linux-chromeos-rel bot, which is what the CI/CQ tests.