59 bytes, text/x-review-board-request
rustc 1.19.0-nightly (5b13bff52 2017-05-23) has an undefined symbol issue on macOS 10.7 native static-analysis and tc-cross debug builds. Native opt build is ok. > INFO - Undefined symbols for architecture x86_64: > INFO - "_res_9_init", referenced from: > INFO - __ZN3std3net11lookup_host17h4921acf881e7a50cE in libgkrust.a(std-438eba4cd7d88a45.0.o) https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b3efd185e85&selectedJob=102081909 https://treeherder.mozilla.org/logviewer.html#?job_id=102081909&repo=try&lineNumber=34834
That symbol is in -lresolv. And it presumably is a consequence of https://thesquareplanet.com/blog/the-story-of-a-rust-bug/ That raises the interesting question whether we actually want rust code to be using libc's dns resolution...
Nice. And indeed rustc tells us we should have linked with -lresolv. > INFO - note: library: resolv Time to dust off that staticlib dependency-tracking patch.
Has it been dusted?
I has not. I've been trying to unblock mac stylo builds and haven't been able to look at it. The basis is this hack I wrote for testing the mp4 parser's glue code: https://github.com/mozilla/mp4parse-rust/blob/master/mp4parse_capi/examples/Makefile#L22 Possibly also assisted by adding more convenient rustc output a la rust-lang/rust#31471. That needs to be ported to config/rules.mk
This issue made it into rust 1.19.0-beta.1, which otherwise we build with: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b175c6eacd78a4dce0427cab6ef2623844984e2a&selectedJob=105270190 We can work around by just adding -lresolv to the macOS build config.
I fixed it by adding -lresolv to the LDFLAGS on line 67 of toolkit/library/moz.build I'm not certain I fully understand the problem so I'm not sure if this is the correct way to fix it either. Can anyone confirm this? If that's the correct solution I can submit a patch.
I'm ok with the fix as a work-around. It seems to do no harm even with rust 1.18.0. The correct fix is to teach the build system to parse the dependent library list out of the cargo output and append it to the link line of the corresponding final library or executable. Per #1 we could also fix this particular instance of the bug by writing a shim around the Firefox resolver to replace the system api when linking rust-std into XUL, similar to what we do with allocators.
Ran into this too, and with the workaround in Tristan's diff everything seems to work fine. Would be cool if this could be merged!
Comment on attachment 8878879 [details] Bug 1367932 - Fix compile errors with SA caused by missing -lresolv on macOS https://reviewboard.mozilla.org/r/150130/#review156754 ::: toolkit/library/moz.build:68 (Diff revision 1) > > # This option should go away in bug 1290972, but we need to wait until > # Rust 1.12 has been released. > + # We're also linking against libresolv to solve bug 1367932. > if CONFIG['OS_ARCH'] == 'Darwin': > - LDFLAGS += ['-Wl,-no_compact_unwind'] > + LDFLAGS += ['-Wl,-no_compact_unwind,-lresolv'] I would have gone with a separate `LDFLAGS` entry for `-lresolv` since the driver understands that, but this works.
Attachment #8878879 - Flags: review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/c802a2225e3e Fix compile errors with SA caused by missing -lresolv on macOS r=rillian
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.