RNP does not build with linux64-clang-win-cross toolchain since April 15
Categories
(Thunderbird :: Build Config, defect)
Tracking
(Not tracked)
People
(Reporter: rjl, Assigned: rjl)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Compiling the RNP shared library fails when it's a win64-targeted cross-compile build.
The error message:
lld-link: error: undefined symbol: __umodti3
lld-link: error: undefined symbol: __udivti3
Both of those are used by Botan's bigint module.
Assignee | ||
Comment 1•5 years ago
|
||
[edit, fix treeherder link]
Those symbols are supposed to be coming from clang_rt.builtins-x86_64.lib, and the link command does explicitly include that file:
/win64-cross-moz-fetches/clang.0415/bin/lld-link -NOLOGO -DLL -OUT:rnp.dll -PDB:rnp.pdb -SUBSYSTEM:WINDOWS,6.01 -MACHINE:X64 @/moz/obj-win64-openpgp_dev/comm/third_party/rnp/rnp_dll.list ./module.res -LARGEADDRESSAWARE -DEBUG -OPT:REF,ICF -guard:cf,nolongjmp -DEF:rnp.dll.def user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib secur32.lib /win64-cross-moz-fetches/clang.0415/lib/clang/9.0.1/lib/windows/clang_rt.builtins-x86_64.lib
This broke when the linux64-clang-win-cross toolchain made the change to using the 1-stage compiler for clang-cl.exe. Prior to that change, the build worked.
This is only happening on cross-compiled win64 builds. Builds done on Windows with clang-cl do work.
The differences between linux64-clang-win-cross from April 9 and April 14 are small. clang-cl.exe and lib/clang/9.0.1/lib/windows/* changed, including clang_rt.builtins-x86-64.lib.
umodti3.c (from compiler-rt) has #ifdefs around the implementation:
#ifdef CRT_HAS_128BIT
https://github.com/llvm-mirror/compiler-rt/blob/1dd2eb5ffc3a86c9d38ec6beaef179f00460be70/lib/builtins/umodti3.c#L15
Which is defined in int_types.h:
// MSVC doesn't have a working 128bit integer type. Users should really compile
// compiler-rt with clang, but if they happen to be doing a standalone build for
// asan or something else, disable the 128 bit parts so things sort of work.
#if defined(_MSC_VER) && !defined(__clang__)
#undef CRT_HAS_128BIT
#endif
So, that means that when compiling compiler-rt with cl.exe (as is the case with our 1stage build) the 128bit functions are not available.
For a quick fix, I changed the 1-stage build to a 2-stage so compiler-rt is compiled with clang-cl. I'm not sure if that is acceptable for Firefox though since the whole point was to save time by not waiting for the 3-stage build.
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=61bc7b73d7a4f372299fa11ac106e501d1bc7a64
Mike, is switching the 1stage clang-cl to a 2stage a possibility?
Assignee | ||
Comment 3•5 years ago
|
||
The clang_rt.builtins lib files produced by the 1stage build do not include
functions necessary for 128bit integers. This functionality is required by the
OpenPGP libraries that Thunderbird is using, specifically Botan's bigint module.
Updated•5 years ago
|
Comment 5•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•