Re: Assistance diagnosing linker failure with Blink mojo bindings in VR service on WIP CL?

[Colin Blundell]

On Tue, Jan 28, 2025 at 7:34 PM Colin Blundell <blun...@google.com> wrote:

+chromium-mojo in case folks on that list have any insight. Thanks!

(from right address)

 

On Mon, Jan 27, 2025 at 9:29 AM Colin Blundell <blun...@chromium.org> wrote:

Hi folks,

Vikas is working on a CL adding GpuMemoryBufferHandle to the ExportedSharedImage Mojo struct. This causes a linker failure in the Blink mojo bindings for the VR service. Do you folks see an obvious cause/fix in the CL?

Thanks,

Colin

[Colin Blundell]

+chromium-mojo in case folks on that list have any insight. Thanks!

[Daniel Cheng]

I haven't quite figured out what's going on. The interesting part is the error:

ld.lld: error: undefined symbol: gfx::mojom::GpuMemoryBufferPlatformHandle::~GpuMemoryBufferPlatformHandle()
>>> referenced by unique_ptr.h:78 (../../third_party/libc++/src/include/__memory/unique_ptr.h:78)
>>>               obj/device/vr/public/mojom/vr_service_blink/vr_service.mojom-blink.o:(mojo::internal::Serializer<gfx::mojom::GpuMemoryBufferHandleDataView, gfx::GpuMemoryBufferHandle>::Serialize(gfx::GpuMemoryBufferHandle&, mojo::internal::MessageFragment<gfx::mojom::internal::GpuMemoryBufferHandle_Data>&))

While linking libdevice_vr_service_mojo_bindings_blink.so. This only fails in component builds, and the one really odd thing here is:

- we are building the Blink variant of the C++ bindings

- but it's referencing a regular variant symbol (gfx::mojom::GpuMemoryBufferPlatformHandle)

What I'm having trouble figuring out is where this reference is coming from, as the linker error gives no obvious clue what's instantiating this unique_ptr...

Daniel

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMGE5NHtrLtdYn0B5vFHkhmVF0w51kep5%3DrzwVe-kEObcwtstQ%40mail.gmail.com.

[Marijn Kruisselbrink]

The blink variant uses the (shared) typemap of mojom::GpuMemoryBufferHandle to gfx::GpuMemoryBufferHandle. And in the type traits for that typemap a mojo::StructPtr<gfx::mojom::GpuMemoryBufferPlatformHandle> is used as the type of the "platform_handle" field. That struct ptr inside it has a unique_ptr<gfx::mojom::GpuMemoryBufferPlatformHandle>. I assume that's the one that is causing problems... Although I have no idea how shared typemaps actually work and why what is done is causing problems...

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAF3XrKr7%2BT0QXW2dyesJCkF75nauQ_W0nC99RNFA_waf7GXMZQ%40mail.gmail.com.

[Daniel Cheng]

Oh... that would explain it. A shared typemap shouldn't be referencing a specific variant–it should be working with the DataView types and converting it directly to whatever the shared C++ type is.

(I was mixing up GpuMemoryBufferHandle and GpuMemoryBufferPlatformHandle which is why my search wasn't quite working. Doh)

Let me see how hard it is to fix...

Daniel

[vikas soni]

Thanks Daniel/Marjin for helping.

I have been trying to update shared_typemap in build files to somehow expose the GpuMemoryBufferPlatformHandle to the blink variant but no luck.

Not sure if GpuMemoryBufferPlatformHandle being a "Union" instead of Struct has to do anything with it.