Updating the mingw-clang trunk breaks build
Categories
(Firefox Build System :: General: Unsupported Platforms, enhancement)
Tracking
(Not tracked)
People
(Reporter: tjr, Assigned: tjr)
References
(Blocks 1 open bug)
Details
In https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a26b92c653f1c6d7c0a199c1548f4ebf419d262 I update to the latest for libunwind, mingw-clang, mingw, and clang. (I also had to update the build script a little.)
The build starts failing with:
/builds/worker/workspace/build/src/sccache2/sccache /builds/worker/workspace/build/src/clang/bin/x86_64-w64-mingw32-clang++ -mwindows -shared -Wl,--gc-sections -Wl,--out-implib -Wl,libcrashinjectdll.a -Wl,-pdb,crashinjectdll.pdb -o crashinjectdll.dll crashinjectdll.o ./module.res -Wl,-S -Wl,--dynamicbase -Wl,--icf=safe ../../../../build/win32/crashinjectdll/crashinjectdll.def -luuid -lusp10 -lgdi32 -lwinmm -lwsock32 -luserenv -lsecur32
lld-link: error: undefined symbol: __imp_mozalloc_abortreferenced by /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/throw_gcc.h:140
crashinjectdll.o:(_ZSt19__throw_regex_errori)
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
We had previously seen this issue in Bug 1443823 and Bug 1448749 (on the mingw-gcc build).
In this case however, I don't think the issue is with the wrong name, so much as we're now requiring things we didn't require before. Compare this build - memory/mozalloc/mozalloc_abort.o is built at 12:30:13; while crashinjectdll.dll is built at 12:30:11 - 2 minutes before mozalloc_abort.
The symbols from the two differ:
Working Build:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 d .data$tid
0000000000000000 N .debug$S
0000000000000000 N .debug$S
0000000000000000 N .debug$S
0000000000000000 N .debug$T
0000000000000000 n .llvm_addrsig
0000000000000000 p .pdata$DllMain
0000000000000000 t .text
0000000000000000 t .text$DllMain
0000000000000000 t .text$_Z14CrashingThreadPv
0000000000000000 r .xdata$DllMain
0000000000000000 a @feat.00
0000000000000000 T DllMain
0000000000000000 T _Z14CrashingThreadPv
> U __imp_CreateThread
0000000000000000 D tid
Broken build:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 d .data$tid
0000000000000000 N .debug$S
0000000000000000 N .debug$S
0000000000000000 N .debug$S
0000000000000000 N .debug$S
0000000000000000 N .debug$T
0000000000000000 i .drectve
0000000000000000 n .llvm_addrsig
0000000000000000 p .pdata$DllMain
0000000000000000 p .pdata$_ZSt19__throw_regex_errori
0000000000000000 r .rdata
0000000000000000 r .str
0000000000000000 t .text
0000000000000000 t .text$DllMain
0000000000000000 t .text$_Z14CrashingThreadPv
0000000000000000 t .text$_ZSt19__throw_regex_errori
0000000000000000 r .xdata$DllMain
0000000000000000 r .xdata$_ZSt19__throw_regex_errori
0000000000000000 a @feat.00
0000000000000000 T DllMain
0000000000000000 T _Z14CrashingThreadPv
0000000000000000 T _ZSt19__throw_regex_errori
U __imp_CreateThread
U __imp_mozalloc_abort
U snprintf
U strerror
0000000000000000 D tid
|
Assignee | |
Comment 1•5 years ago
|
||
Bisecting clang shows the problem starts occurring with revision 359020 which is this commit: https://github.com/llvm-mirror/libcxx/commit/dbd4f51025003a7c869c4e5267ab8780e91367d5
|
|
Assignee | |
Comment 2•5 years ago
|
||
Besides this weird clang crash, updating to trunk also causes xgetbv compilation errors. These three patches fixed it for mozilla-central though:
https://hg.mozilla.org/try/rev/ff5fbf591978bf1b5646c8745dccbb73c5c9a437
https://hg.mozilla.org/try/rev/5984f5e6225a5eb8cbbf4d97e772643d5b165875
https://hg.mozilla.org/try/rev/a783727061e86cb39dad0d1fd8291c25cd3e0859
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 3•4 years ago
|
||
This works now. Bug 1633761
Description
•