Live Caption returns Soda errors

[pjpreilly]

Enabling Live Caption on the latest Canary #1100821 on osx Lion returns these soda errors...

[krackers]

Seems like std::bad_optional_access was only added in C++17 onwards, so is not going to be present in libc++ for versions older than sierra or so? Also apparently libsoda ("Google Chrome SODA Offline Speech Recognition library") is not distributed in source form, so you won't be able to polyfill it either.

I don't remember, does chromium-legacy already link against a newer libc++ from llvm, or does it link against the system provided libc++? Eventually may have to start doing the former as more c++17 features start getting used...

Can also see this discussion from macports which might be relevant: https://trac.macports.org/ticket/62426

[Wowfunhappy]

I'm pretty sure Chromium Legacy is built against its own statically-linked libc++. But clearly that won't apply to libsoda if it's distributed as a binary.

It might be possible to do some install_name_tool trickery to make the libsoda binary load a different library. (Note that from what I've read, loading a different libc++ dynamically as opposed to statically increases the likelihood of ODR errors. I only partially understand what that means.) Unfortunately, it might make more sense to just disable Live Captioning in Chromium Legacy.

[krackers]

increases the likelihood of ODR errors

I find it not helpful to think in terms of ODR since by this point symbols are already mangled and everything, so talking in terms of ODR is not precise enough. If the main chromium framework is statically linked to its own libc++, and we do some dynamic linker magic to forcelibsoda to point to a custom libc++, then I think it should be OK. Reason is that (1) this is no different than what ofifical chrome is doing in terms of using two different libc++ between versions. (2) It will only cause an issue with incompatible struct definitions/etc. if you pass C++ objects at the boundary between libraries, which you shouldn't do anyway. (3) Internally within each library they use the correct symbols (because former is statically linked, no conflict).

So to me the rule is that: 1) passing cpp objects between libraries that use different libcpp will cause bad behavior, for obvious reasons 2) If the libc++ library did things properly, in the majority of cases the above will actually be caught at link time. For instance, GCC libcxx uses inline namespace so all of its standard objects will be mangled differently than clang ones. So linker will complain. See https://stackoverflow.com/questions/12542971/using-libstdc-compiled-libraries-with-clang-stdlib-libc

3) Inline symbol namespacing will also prevent symbol conflicts even with a flat linker namespace. 3) In the case that above doesn't happen (maybe different version of same vendor libcxx, or just no inline namespace used) then no error will be thrown at link time, so if the libraries do pass c++ objects at the boundary we will get bad behavior at runtime.

4) Moreover if in a flat naemspace the symbols could collide so even behavior for code exected solely internal within library could be bad. OSX has 2-level namespace, so this is not an issue I think.

[blueboxd]

Unfortunately, libsoda.so is not open-source, distributed as a binary extension like Widevine. So, we can do nothing from the source with undefined symbols on older macOSes...