relocation R_386_GOTOFF against undefined hidden symbol `tabs_4d51_TabsBridgedEngine_reset' can not be used when making a shared object
Categories
(Toolkit :: UniFFI Bindings, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox108 | --- | fixed |
firefox109 | --- | fixed |
firefox110 | --- | fixed |
People
(Reporter: glandium, Assigned: glandium)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
diannaS
:
approval-mozilla-release+
|
Details | Review |
On some platforms (happens on Debian i386 and s390x), the build fails with an error like:
relocation R_386_GOTOFF against undefined hidden symbol `tabs_4d51_TabsBridgedEngine_reset' can not be used when making a shared object
/usr/bin/ld: final link failed: bad value
The problem on i386 is that tabs.uniffi.rs
doesn't contains tabs_4d51_
prefixes, but tabs_1c79_
.
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Set release status flags based on info from the regressing bug 1791851
:skhamis, since you are the author of the regressor, bug 1791851, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 2•2 years ago
|
||
There are apparently two problems, one immediate and one theoretical:
- The hash used in the ffi function prefixes depends on the in-memory properties of
ComponentInterface
'stypes.type_definitions
. - The
uniffi_meta::checksum
function relies onDefaultHasher
, which is not guaranteed to stay the same across versions of rust, so the rust version used to pre-generatetoolkit/components/uniffi-js/UniFFIGeneratedScaffolding.cpp
might not generate the same hash as the rust version that builds tree.
Assignee | ||
Comment 3•2 years ago
|
||
- The hash used in the ffi function prefixes depends on the in-memory properties of
ComponentInterface
'stypes.type_definitions
.
Mmmm that's actually not it. types
is not hashed. Its content was the only difference in the output of dbg!()
for the hashed value...
Comment 4•2 years ago
|
||
This almost looks like another manifestation of bug 1797714 (but Debian i386 being impacted gives me pause)
Assignee | ||
Comment 5•2 years ago
|
||
Oh, the reason it happens on Debian but not on our CI (after all we do have 32-bits Linux builds) is that the Debian build is not cross-compiled, so it's using a x86 rust compiler. I can totally reproduce off the application-services repo on x86_64 after installing a i686 rust compiler (e.g. rustup default stable-i686-unknown-linux-gnu
) and removing rust-toolchain.toml (and checking the generated tabs.uniffi.rs).
After digging a little, it turns out the difference comes from the impl Hash for [T]
, which is called for each Vec
, and which does a hasher.write_length_prefix(slice.len())
, which translates to hasher.write_usize(slice.len())
, which translates to hasher.write(&slice.len().to_ne_bytes())
, which will do feed the hasher with 4 bytes on 32-bits and 8 bytes on 64-bits, and with different bytes order depending on the endian, so it is in fact, the same as bug 1797714.
The lesson here is that std::hash::Hash
is not meant to be used the way uniffi uses it.
Assignee | ||
Comment 6•2 years ago
|
||
(And the executive summary of the issue is that Firefox fails to build on any platform that is not little-endian 64-bits)
Comment 7•2 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #5)
The lesson here is that
std::hash::Hash
is not meant to be used the way uniffi uses it.
Yeah - https://github.com/mozilla/uniffi-rs/issues/1393. In the meantime, we decided to prioritize doing the generation at build-time because that would side-step the issue in most cases and also fix other pain points with having the generated code checked in. If that turns out to be tricky we intend fixing it in uniffi first.
The other reason we side-stepped that is because ideally we'd get rid of that hash entirely - in the meantime, uniffi kinda assumes that the uniffi bindgen utility will generally be built using the same compiler that will be used to build the generated code, but I'm not sure whether the above is an example of when this will not be true - ie, it sounds like we might need to fix it in uniffi anyway?
(Removing ni from Sammy as I think we understand what's going on here)
Assignee | ||
Comment 8•2 years ago
|
||
IIRC, generating the code at build time would be very difficult because of how the integration between C++ and rust code in the build system works. I'm looking at a quick-and-dirty stable hash for Debian.
Assignee | ||
Comment 9•2 years ago
|
||
I'm testing applying this on Debian: https://github.com/mozilla/uniffi-rs/compare/main...glandium:uniffi-rs:checksum
Assignee | ||
Comment 11•2 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #9)
I'm testing applying this on Debian: https://github.com/mozilla/uniffi-rs/compare/main...glandium:uniffi-rs:checksum
Confirmed to work on 32-bits and big-endian. I'll polish it and send a PR.
Assignee | ||
Comment 12•2 years ago
|
||
Assignee | ||
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
Comment 15•2 years ago
•
|
||
Backed out 2 changesets (Bug 1804360, Bug 1805809) for causing build bustages CLOSED TREE
Log: https://treeherder.mozilla.org/logviewer?job_id=399934643&repo=autoland&lineNumber=70834
Backout: https://hg.mozilla.org/integration/autoland/rev/37e8f20bbb82f3a3f85833d84be4a28393cefbe0
Assignee | ||
Comment 16•2 years ago
|
||
Duh of course it failed, the checksum changes based on the uniffi version, so we need an update in the generated code in tree.
Assignee | ||
Comment 17•2 years ago
|
||
Updated•2 years ago
|
Comment 18•2 years ago
|
||
Comment 19•2 years ago
|
||
bugherder |
Comment 20•2 years ago
|
||
Backed out for causing bug 1806321.
https://hg.mozilla.org/mozilla-central/rev/370b88940241e124a82dee16c6fce90ee25af36b
Comment 21•2 years ago
|
||
hey everyone, thanks for the fix.
Is it possible to backport it to the beta branch?
Never noticed, as I do my test rides of nightly with a cross compiler setup, hence it got away
Comment 22•2 years ago
|
||
Comment 23•2 years ago
|
||
bugherder |
Assignee | ||
Comment 25•2 years ago
|
||
Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.
Beta/Release Uplift Approval Request
- User impact if declined: Build failures on 32-bits or big-endian hosts.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Build-time only, no functional change, and if something goes wrong, it does so visibly at build time.
- String changes made/needed: N/A
- Is Android affected?: No
Assignee | ||
Comment 26•2 years ago
|
||
Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.
Beta/Release Uplift Approval Request
- User impact if declined: If a dot release comes out, it would be good to have this in it too. See beta approval.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
- String changes made/needed:
- Is Android affected?: No
Comment 27•2 years ago
|
||
Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.
Approved for Desktop 109.0b6 and Mobile 109.0b3.
Comment 28•2 years ago
|
||
bugherder uplift |
Comment 29•2 years ago
|
||
Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.
Approved for 108.0.2
Comment 30•2 years ago
|
||
bugherder uplift |
Description
•