Some change that landed on mozilla-central between July 8, 4:10 AM PDT and July 9, 4:10 AM PDT broke the automated AdressSanitizer builds:
/usr/bin/ld: ../../media/webrtc/trunk/src/modules/modules_rtp_rtcp/rtp_rtcp/source/rtp_packet_history.o: relocation R_X86_64_PC32 against `_ZNSt6vectorIjSaIjEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPjS1_EEmRKj' can not be used when making a shared object; recompile with -fPIC
The full build log is here: http://email@example.com/try-linux64/try-linux64-bm14-try1-build8272.txt.gz
@Randall: Ms2ger on IRC suggested that this is related to some change that you made recently, is that likely?
Related to webrtc preffing on over the weekend, yes, but glandium thinks there's a missing file in config/system-headers. Since all the ones included in rt_packet_history.cc or included from it seem to be normal (cstring/cstddef/map/assert), and it doesn't happen in normal builds, the suspicion is that ASan adds some headers(?)
Someone who knows ASan should look at this.
I am unable to reproduce it locally without patching and try will not give me the patch. Can you add instructions on how to reproduce the problem to this bug.
Yea seems like try is having problems. The patch that the autobuild script pushes to try is here:
Note, this could be a clang issue of some sort (not necessarily due to asan).
ok, I am taking a look at it. The build is still going, but I can reproduce the relocations.
(In reply to Rafael Ávila de Espíndola (:espindola) from comment #5)
> ok, I am taking a look at it. The build is still going, but I can reproduce
> the relocations.
Thanks Rafael :) Meanwhile I modified the patch to use --disable-webrtc to keep the daily builds running, and that works fine for now.
Thanks for the bug report. It does look like a clang issue. I think I fixed it in 160034. I am giving in some extra testing and will let you know when the new package is available on tooltool.
Decoder, there is a new clang manifest in bug 772853. Would you mind trying it to see if it fixes the build for you?
A new version of clang is at
Can you give it a try?
Thanks Rafael, this is fixed with the most recent clang version :)