I get unresolved external symbol __muloti4 when attempting to compile GNU m4
for Windows commandline.
See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22
Looking into this, I see that some parts of compiler-rt are disabled for
Windows due to the __LP64__ define. The code seem not portable as is to the
MS compiler, but according to my tests the code compiles and links OK with
clang: I have not tested functionality though. Regarding the __LP64__
define, it's wrong to define it for Windows. SUA/Interix have LP64 long type
model, while Cygwin, mingw and native Windows have LLP64. _M_X64 or
__x86_64__ is more common.
So I wonder, is the disabled compiler-rt parts intentional and not suitable
If not so, what can be done to enable it?
We should be building the __int128_t support bits for any target which has an __int128_t type... which I guess includes 64-bit Windows. Patch welcome. (We should probably be checking whether __SIZEOF_INT128__ is defined.)
Thanks for the reply. I'm new to using clang and I have no idea how common my problem with GNU m4 is. Maybe it's a rare event. Anyway, I'm thinking of recompile the whole clang_rt.builtins-x86_64.lib with clang. At least that's better than cherry-picking symbols when needed I think. Perhaps compiling compiler-rt with clang is a solution that could be defined in the make files, as an alternative. That way the library would be free from concerns of other compilers.
Yes, __SIZEOF_INT128__ would be more logical than a 64-bit define.
I successfully rebuilt my clang_rt.builtins-x86_64.lib using
clang and the
and also used the -C7, -Zl and -nodefaultlib flags to get a complete non-dependency release library
As a sidenote I noticed that the LLVM binary repository libraries have the
injected, which IMO is a bit of a problem. However, I don't think it's possible to set the -Zl compiler flag explicitly for static library builds, as it would require a kind of "static library compiler flag" Cmake variable. Seem to be a limitation of the build system, or? On the other hand I have not yet experienced any problem with these defaultlib dependencies. Perhaps clang is not using the /DEFAULTLIB linker flag?