llvm dev - Dec 2017 - Unresolved symbols in compiler-rt

Hello all,

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
for Windows?
If not so, what can be done to enable it?

Thanks Erik

On 12/8/2017 11:27 AM, Jerker Bäck via llvm-dev wrote:
> Hello all,
>
> 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
> for Windows?
> 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.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

Hi Eli,

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.

Regards Erik

-----Original Message-----
From: Friedman, Eli [mailto:efriedma at codeaurora.org] 
Sent: Friday, December 8, 2017 8:50 PM
To: Jerker Bäck; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Unresolved symbols in compiler-rt

On 12/8/2017 11:27 AM, Jerker Bäck via llvm-dev wrote:
> Hello all,
>
> 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
> for Windows?
> 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.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

Update:

I successfully rebuilt my clang_rt.builtins-x86_64.lib using
clang and the 
CRT_HAS_128BIT defined 
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 
/DEFAULTLIB:libcmt.lib 
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?

Erik