Closed Bug 1367932 Opened 4 years ago Closed 3 years ago

Undefined symbol _res_9_init with rustc 1.190-nightly


(Firefox Build System :: General, defect)

Not set


(firefox56 fixed)

Tracking Status
firefox56 --- fixed


(Reporter: rillian, Assigned: tbourvon)


(Blocks 1 open bug)



(1 file)

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)
That symbol is in -lresolv. And it presumably is a consequence of

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?
Flags: needinfo?(giles)
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: Possibly also assisted by adding more convenient rustc output a la rust-lang/rust#31471.

That needs to be ported to config/
Flags: needinfo?(giles)
This issue made it into rust 1.19.0-beta.1, which otherwise we build with:

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/

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.
Flags: needinfo?(giles)
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.
Flags: needinfo?(giles)
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

::: toolkit/library/
(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
Fix compile errors with SA caused by missing -lresolv on macOS r=rillian
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Assignee: nobody → tbourvon
Product: Core → Firefox Build System

Tristan, it looks like you are the assignee on this bug, but under a different email. Are you still working on this bug? If not, would you please unassign yourself?

Flags: needinfo?(tristanbourvon)

Sorry for the spurious NI request, missed that this bug had been resolved.

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