Windows question: Dozens of linker warnings and errors

Project Infrastructure LLVM Dev List Archives
1

Hi again again,

I’m trying to build my compiler frontend in C++ on Windows 7 x64 using clang++.exe. I want to use clang++ for my project so that I get a feel for how mature and usable the Windows support is as I gradually get up to speed with LLVM for Windows. I could develop on Linux, but I need the Windows support so I figure I might as well do it the hard way.

My code is fairly simple C++ with a few template classes, a rare virtual function, and nothing very fancy. I am able to compile my code without warnings (although clang++ earlier on found a couple of very serious issues in my code). But when I get to the link phase, all hell breaks loose:

I get a ton of these warnings:

Memory.o : warning LNK4006: _InterlockedBitTestAndSet already defined in Stream.o; second definition ignored
Memory.o : warning LNK4006: _InterlockedBitTestAndReset already defined in Stream.o; second definition ignored
Memory.o : warning LNK4006: _InterlockedBitTestAndComplement already defined in Stream.o; second definition ignored
Memory.o : warning LNK4006: _MemoryBarrier already defined in Stream.o; second definition ignored
Memory.o : warning LNK4006: _ReadPMC already defined in Stream.o; second definition ignored

I don’t use InterlockedBitTestAndSet anywhere in my code and the same goes for the rest of the symbols that are being warned about.

After that, I get a ton of errors form the linker because it complains about the above symbols already being defined.

I also get a few errors like this:

Bitset_test-423377.o : error LNK2001: unresolved external symbol __ZTVN10__cxxabiv120__si_class_type_infoE

Any ideas? Is the Windows support simply not mature enought for real use or am I doing something wrong? I invoke the linker through clang++ by giving the input object files and a library that must be linked against, made with Microsoft’s LIB tool. I use Microsoft LIB because LINK rejects libraries created using llvm-ar.

I only use the -c, -o, -v, and -D options to clang++.exe and nothing else. Nothing advanced yet.

Is it that clang++/Windows simply don’t support the use of libraries yet? The hello world example works great, but I do aspire to more than that.

If I have missed an important note in the documentation, then I apologize greatly in advance.

Sincerely,
Mikael Lyngvig

2

Hi again again,

I'm trying to build my compiler frontend in C++ on Windows 7 x64 using
clang++.exe. I want to use clang++ for my project so that I get a feel for
how mature and usable the Windows support is as I gradually get up to speed
with LLVM for Windows. I could develop on Linux, but I need the Windows
support so I figure I might as well do it the hard way.

My code is fairly simple C++ with a few template classes, a rare virtual
function, and nothing very fancy. I am able to compile my code without
warnings (although clang++ earlier on found a couple of very serious issues
in my code). But when I get to the link phase, all hell breaks loose:

I get a ton of these warnings:

Memory.o : warning LNK4006: _InterlockedBitTestAndSet already defined in
Stream.o; second definition ignored
Memory.o : warning LNK4006: _InterlockedBitTestAndReset already defined in
Stream.o; second definition ignored
Memory.o : warning LNK4006: _InterlockedBitTestAndComplement already defined
in Stream.o; second definition ignored
Memory.o : warning LNK4006: _MemoryBarrier already defined in Stream.o;
second definition ignored
Memory.o : warning LNK4006: _ReadPMC already defined in Stream.o; second
definition ignored

I don't use InterlockedBitTestAndSet anywhere in my code and the same goes
for the rest of the symbols that are being warned about.

After that, I get a ton of errors form the linker because it complains about
the above symbols already being defined.

This is due to clang not understanding force_inline. These functions
are defined in a header included from Windows.h, so it ends up getting
a definition everywhere it is included.

I also get a few errors like this:

Bitset_test-423377.o : error LNK2001: unresolved external symbol
__ZTVN10__cxxabiv120__si_class_type_infoE

Any ideas? Is the Windows support simply not mature enought for real use or
am I doing something wrong? I invoke the linker through clang++ by giving
the input object files and a library that must be linked against, made with
Microsoft's LIB tool. I use Microsoft LIB because LINK rejects libraries
created using llvm-ar.

I only use the -c, -o, -v, and -D options to clang++.exe and nothing else.
Nothing advanced yet.

Is it that clang++/Windows simply don't support the use of libraries yet?
The hello world example works great, but I do aspire to more than that.

If I have missed an important note in the documentation, then I apologize
greatly in advance.

Sincerely,
Mikael Lyngvig

The rest of the issues are due to clang not supporting the Microsoft
C++ ABI yet. To use clang on Windows for C++ code you will need to use
it with MinGW as it provides libraries that use the GNU C++ ABI.

- Michael Spencer

3

Thanks for the quick reply. I had a feeling that it was due to missing Windows support in clang++ and LLVM.

“”"
This is due to clang not understanding force_inline. These functions
are defined in a header included from Windows.h, so it ends up getting
a definition everywhere it is included.
“”"

How much work would it take to add support for force_inline? Are there any plans for when/if it will be supported? I don’t know anything about force_inline, but I guess supporting it is a relatively simple matter. After all, isn’t a forced_inline construct similar to an inlined template method? In the old MS-OMF days, we’d start talking about COMDATs and stuff like that, but I don’t know how it is done nowadays.

“”"
The rest of the issues are due to clang not supporting the Microsoft
C++ ABI yet. To use clang on Windows for C++ code you will need to use
it with MinGW as it provides libraries that use the GNU C++ ABI.

“”"
I guess this is quite a mouthful, but when do you roughly expect the Microsoft C++ ABI to be supported? v4.0 or later? Is there anything not too overwhelming and/or complex that I can do to speed up this process?

I am asking these questions because I see myself as a wannabe client of the LLVM tools - I don’t know much about code generation and I don’t really want to know much about it, all I want to do is to make my own production language using LLVM as the portable (also to Windows/M$) backend. My hope is that LLVM can save me the hassles of meddling around with assembler and so on, as I’d much rather spend my energy on my language. But if the Windows support is broken, partial beyond use, or never to be finished up, I cannot use LLVM. Then I’d have spend my energy on writing my own simple code generator, which would never generate code of a quality anywhere near LLVM. Or, I could go ahead and do my own silly backend and then check up on LLVM in a couple of years, to see if the Windows support was matured.

By the way, I do have a background in linkers and compilers for Windows platforms, so if I can help with anything, I’ll be glad to do so. Just don’t expect me to work miracles from day one because it has been almost 15 years since I last worked with compilers and linkers.

Perhaps I can contribute in the field of Windows support? I once wrote a librarian for OMF (the ancient object file format used under DOS) and COFF. I could probably add support for COFF archives to llvm-ar, if need be. And stuff like that.

Sincerely,
Mikael

4

Thanks for the quick reply. I had a feeling that it was due to missing
Windows support in clang++ and LLVM.

"""
This is due to clang not understanding force_inline. These functions
are defined in a header included from Windows.h, so it ends up getting
a definition everywhere it is included.
"""

How much work would it take to add support for force_inline? Are there any
plans for when/if it will be supported? I don't know anything about
force_inline, but I guess supporting it is a relatively simple matter.
After all, isn't a forced_inline construct similar to an inlined template
method? In the old MS-OMF days, we'd start talking about COMDATs and stuff
like that, but I don't know how it is done nowadays.

It should be trivial. Clang already parses it. It just needs to get
hooked up to the attribute system, as we already support the gnu
version of it (I believe alwaysinline).

"""
The rest of the issues are due to clang not supporting the Microsoft
C++ ABI yet. To use clang on Windows for C++ code you will need to use
it with MinGW as it provides libraries that use the GNU C++ ABI.

"""
I guess this is quite a mouthful, but when do you roughly expect the
Microsoft C++ ABI to be supported? v4.0 or later? Is there anything not
too overwhelming and/or complex that I can do to speed up this process?

People are actively working on it, but I have no idea when it will be ready.

I am asking these questions because I see myself as a wannabe client of the
LLVM tools - I don't know much about code generation and I don't really want
to know much about it, all I want to do is to make my own production
language using LLVM as the portable (also to Windows/M$) backend. My hope
is that LLVM can save me the hassles of meddling around with assembler and
so on, as I'd much rather spend my energy on my language. But if the
Windows support is broken, partial beyond use, or never to be finished up, I
cannot use LLVM. Then I'd have spend my energy on writing my own simple
code generator, which would never generate code of a quality anywhere near
LLVM. Or, I could go ahead and do my own silly backend and then check up on
LLVM in a couple of years, to see if the Windows support was matured.

LLVM already supports Windows quite well. The issue is clang and the
MS C++ ABI. If you are writing your own language that does not need to
interact with the C++ ABI then everything will be fine.

By the way, I do have a background in linkers and compilers for Windows
platforms, so if I can help with anything, I'll be glad to do so. Just
don't expect me to work miracles from day one because it has been almost 15
years since I last worked with compilers and linkers.

Perhaps I can contribute in the field of Windows support? I once wrote a
librarian for OMF (the ancient object file format used under DOS) and COFF.
I could probably add support for COFF archives to llvm-ar, if need be. And
stuff like that.

Increasing support for Windows across LLVM is a welcome addition. My
main area on LLVM currently is actually binary tools, and adding
object file support to llvm-ar is one of the items on my list. You may
also be interested in the lld linker project (lld.llvm.org).

Sincerely,
Mikael

- Michael Spencer

5

I can confirm this. Even if you do need to interface to C/C++, clang
works fine for that as long as you stick to the mingw libraries instead
of msvc. There are already a number of full-blown LLVM-based language
projects by 3rd parties you can take a look at, see
http://llvm.org/releases/3.1/docs/ReleaseNotes.html#externalproj.

Speaking about my own project (http://pure-lang.googlecode.com/), we've
had that up and running on Linux, *BSD, OS X and Windows at least since
the days of LLVM 2.5, using first llvm-gcc and then clang as an
LLVM-capable C/C++ compiler for inlining C/C++ in Pure. I vaguely recall
some issues with clang 3.0 on Windows due to hardcoded paths. But clang
2.9 has been working great on Windows for me and other Pure users,
hopefully 3.1 will be the same.

Albert

6

I have been using LLVM to support my own language compiler on windows exclusively for some time now. I can link using either MinGW or MSVC though I haven’t got into exception handling. I keep my LLVM up to date with trunk and have not had any problems. I generally use clang compiled test projects linked against MinGW for seeing how various details of the build process should work.

7

“”"
Increasing support for Windows across LLVM is a welcome addition. My
main area on LLVM currently is actually binary tools, and adding
object file support to llvm-ar is one of the items on my list. You may
also be interested in the lld linker project (lld.llvm.org).

“”"

I am looking at the llvm-ar and Archive.cpp source code right now. It seems it to only supports ELF archives (and COFF, etc. object files) at the time? I guess we’ll have to refactor so as to introduce a polymorphic class hierarchy. Or, how do you do it in LLVM? Not that I am about to code anything; I won’t touch anything until we have clearly decided what I should and should not do and until you give me a “go!”. I don’t even know if you really want me to look at implementing COFF archive support or not. After all, it is on your to-do list, not mine :slight_smile: My plan now is to spend some days studying the llvm-ar and lib/Object files and get to know them well enough that I know what should and should not be done.

Also, I suppose you already have this:

http://msdn.microsoft.com/library/windows/hardware/gg463125 (Microsoft PE Common Object File Format Specification v8.0)

If not, you’re going to need it sooner or later.

Also, I have to warn that my C++ is a bit rusty. I have coded in C++ since 1990, but I have hardly used it the past 10 years so there is some catching up to do. For instance, I just ran into the “explicit” keyword and had to do a Google search to find out what that meant. Also, I’m only vaguely familiar with the STL. I’m not unfamiliar with OOP, etc., it is just that I have been using Python and C# for the past decade.

Cheers,
Mikael