Closed Bug 1595805 Opened 3 months ago Closed 3 months ago

Undefined symbols when linking macosx cross-compiled build with ASAN and fuzziness

Categories

(Infrastructure & Operations :: Infrastructure: Tools, defect)

x86_64
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kvark, Assigned: kvark)

References

Details

Attachments

(1 file)

There is a strange linking issue with https://phabricator.services.mozilla.com/D49458 , described in detail in https://github.com/rust-lang/rust/issues/66285

Basically, linking libgkrust.a with optimization, ASAN, and fuzziness, from linux to macosx, may strip out some of the objects (like "spirv_cross.o"), which later fails to link into "XUL" with "Undefined symbols..." error.

Blocks: 1575008
Assignee: infra → dmalyshau
Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8984a9fbc4e0
Disable LTO on macosx fuzzy builds r=froydnj
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED

Nathan, should we be keeping the bug open in order to eventually address this better than the workaround merged?

Flags: needinfo?(nfroyd)

(In reply to Dzmitry Malyshau [:kvark] from comment #4)

Nathan, should we be keeping the bug open in order to eventually address this better than the workaround merged?

LTO is a performance optimization which I don't think fuzzing builds are going to worry too much about, so I'd be OK with either leaving open or closing, with a slightly preference for closing.

Flags: needinfo?(nfroyd)

I'm seeing new link errors, which look very much related, now on other OSX targets and Windows MinGW:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028360&revision=79a071bf26b5a3da9904a7ebd8d5bae48f4b443c

Notice the previous try of the same jobs - https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028349&revision=9085fdb3dde4e841375002a20f21c0f5dbf9aff5
No spirv_cross stuff was changed in-between, the new commits just add wgpu functionality.

Nathan, would you have any suggestions on how to approach this? Would disabling LTO on all those targets be even an option?

Flags: needinfo?(nfroyd)

(In reply to Dzmitry Malyshau [:kvark] from comment #6)

I'm seeing new link errors, which look very much related, now on other OSX targets and Windows MinGW:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028360&revision=79a071bf26b5a3da9904a7ebd8d5bae48f4b443c

Notice the previous try of the same jobs - https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=286028349&revision=9085fdb3dde4e841375002a20f21c0f5dbf9aff5
No spirv_cross stuff was changed in-between, the new commits just add wgpu functionality.

Nathan, would you have any suggestions on how to approach this? Would disabling LTO on all those targets be even an option?

I have no problem with turning off LTO on the MinGW builds (unless Tor is using LTO, ni? to tjr for that).

I'm less excited about turning off LTO on the Mac opt builds, but we could prooobably get away with that?

Unfortunately, LTO is required on the mac shippable instrumented build (and even if we turned it off there, we use LTO on the profile-use build, and I'd bet the same problem would show up there), so we have to fix that. It sounds like the Rust issue that you filed just stalled out? We might be able to get mw to help debug this if we had a kind of stripped-down testcase, which it sounds like https://github.com/rust-lang/rust/issues/66285#issuecomment-552543578 had?

Flags: needinfo?(nfroyd) → needinfo?(tom)

(In reply to Nathan Froyd [:froydnj] from comment #7)

I have no problem with turning off LTO on the MinGW builds (unless Tor is using LTO, ni? to tjr for that).

I believe their build just uses our configuration settings when you set --enable-optimize and export MOZILLA_OFFICIAL=1

https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/firefox/mozconfig-windows-x86_64

So disabling LTO for MinGW would wind up disabling it for them I think...

Flags: needinfo?(tom)
You need to log in before you can comment on or make changes to this bug.