Closed Bug 1340760 Opened 7 years ago Closed 7 years ago

PrintfTarget stuff doesn't get linked into sdp_file_parser at least on Mac

Categories

(Core :: XPCOM, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file, 5 obsolete files)

STEPS TO REPRODUCE (on Mac:

1)  Pull current tip m-c (in my case I'm on rev d11c29c1db3a).
2)  Try to build (debug in my case)

EXPECTED RESULTS: Things build

ACTUAL RESULTS:

 0:01.29 Undefined symbols for architecture x86_64:
 0:01.29   "mozilla::PrintfTarget::vprint(char const*, __va_list_tag*)", referenced from:
 0:01.29       char* mozilla::Smprintf<mozilla::MallocAllocPolicy>(char const*, ...) in SdpHelper.o
 0:01.29 ld: symbol(s) not found for architecture x86_64
 0:01.29 clang: error: linker command failed with exit code 1 (use -v to see invocation)
 0:01.29 /Users/bzbarsky/mozilla/inbound/mozilla/config/rules.mk:627: recipe for target 'sdp_file_parser' failed

Manishearth is seeing this too.

The failing command line is:

Executing: /opt/local/bin/ccache /Users/bzbarsky/bin/clang++ -std=gnu++11 -o sdp_file_parser -Qunused-arguments -Qunused-arguments -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++11-compat-pedantic -Wc++14-compat -Wc++14-compat-pedantic -Wc++1z-compat -Wimplicit-fallthrough -Wstring-conversion -Wthread-safety -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-exceptions -fno-strict-aliasing -stdlib=libc++ -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -gdwarf-2 -fno-omit-frame-pointer -Wl,-filelist,/Users/bzbarsky/mozilla/inbound/obj-firefox/media/webrtc/signaling/fuzztest/tmp7GSQ3N.list -framework Cocoa -lobjc -framework AudioToolbox -framework ExceptionHandling -Wl,-executable_path,/Users/bzbarsky/mozilla/inbound/obj-firefox/dist/bin -fcolor-diagnostics ../../../../security/libnss3.dylib
Flags: needinfo?(ttromey)
Actually, looks like this just needs to link to mozglue.  I have no idea why the tree is green...
Attachment #8838828 - Flags: review?(nfroyd)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Flags: needinfo?(ttromey)
I had the same issue, but after removing a lot of old cruft I had accumulated in my mozconfig, it built fine again.

Sorry, I didn't keep track of exactly what I removed.
There *may* have been: --enable-dmd --enable-ffmpeg --enable-rust --enable-eme=widevine
OK, so a local opt build succeeds even without this patch.

A "--enable-debug --enable-optimize" build (which is what infra does) _also_ succeeds.  Which explains why the tree is green.  I expect the point is we're including some of the printf stuff as inlines in a header (e.g. nsDebug.h) but not actually _using_ them.  In an --enable-optimize build I bet the optimizer removes all stuff before we ever get to trying to link, so the link succeeds.
Gerald, did you perhaps remove --disable-optimize?
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #4)
> Gerald, did you perhaps remove --disable-optimize?

Ah yes, that's a definite possibility.
For some value of "fun", I just tried building with --disable-optimize, and I did hit the error. So it looks like your theory is correct.
Maybe we should have --disable-optimize --enable-debug builds jobs on automation.
That would be very nice, yes...
Comment on attachment 8838828 [details] [diff] [review]
Link sdp_file_parser against mozglue, since it uses the PrintfTarget stuff from there

Review of attachment 8838828 [details] [diff] [review]:
-----------------------------------------------------------------

Sure!
Attachment #8838828 - Flags: review?(nfroyd) → review+
Filed bug 1341404 for comment 7's suggestion.
Thank you for dealing with this.
Comment on attachment 8839667 [details]
Bug 1340760: P3. Add low-latency option to FFmpeg.

https://reviewboard.mozilla.org/r/114248/#review115680

::: dom/media/platforms/ffmpeg/FFmpegVideoDecoder.h:96
(Diff revision 1)
>  
>    PtsCorrectionContext mPtsContext;
>    int64_t mLastInputDts;
>  
>    DurationMap mDurationMap;
> +  bool mLowLatency;

note to self, make this const
Comment on attachment 8839666 [details]
Bug 1340760: P2. Add Low Latency option to CreateDecoderParams.

https://reviewboard.mozilla.org/r/114246/#review115684
Attachment #8839666 - Flags: review?(gsquelart) → review+
Comment on attachment 8839667 [details]
Bug 1340760: P3. Add low-latency option to FFmpeg.

https://reviewboard.mozilla.org/r/114248/#review115686
Attachment #8839667 - Flags: review?(gsquelart) → review+
Comment on attachment 8839668 [details]
Bug 1340760: P4. Never use WMF decoders when low latency is required.

https://reviewboard.mozilla.org/r/114250/#review115692
Attachment #8839668 - Flags: review?(gsquelart) → review+
My apologies for using the wrong bug number.
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b5c2b030ed0
Link sdp_file_parser against mozglue, since it uses the PrintfTarget stuff from there.  r=froydnj
Attachment #8839767 - Attachment is obsolete: true
Attachment #8839767 - Flags: review?(nfroyd)
https://hg.mozilla.org/mozilla-central/rev/8b5c2b030ed0
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Attachment #8839665 - Attachment is obsolete: true
Attachment #8839666 - Attachment is obsolete: true
Attachment #8839667 - Attachment is obsolete: true
Attachment #8839668 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.