Eric Niebler <eric@boostpro.com> writes:
For a few days now I've been plagued by output target conflicts between
the clang and libclang projects in Visual Studio. The errors I'm getting
look like this:
<snip>
At the very least, there is a bug in the CMake files because both these
projects try to build bin/[config]/clang.pdb. There seems to be other
conflicts too, leading to the above linker errors, but I can't track it
down. (Maybe clang.exp or clang.obj or clang.lib?)
Suggestion: Why not make libclang generate libclang.[dll|lib] instead of
clang.[lib|dll]? I think that would avoid these problems.
The proper name of the library is "clang", not "libclang". Changing it
to libclang only for VS would be arbitrary and would break the build for
multi-platform clients.
Yep, both projects use lib/[config]/clang.exp as their export library.
This causes havoc. I've worked around the problem by manually changing
the generated clang.vcproj to use "expclang" as the name of the import
library, which makes it generate lib/[clang]/expclang.exp and
lib/[config]/expclang.lib. This doesn't break anything because nobody
uses the exports from clang.exe. I'm not even sure why we're generating
an import library for clang.exe.
I've also turned off incremental linking for both clang.vcproj and
libclang.vcproj because they both try to use bin/[config]/clang.ilk as
their incremental link file.
If I knew more CMake, I would suggest a patch, but I'll leave that for
someone else.
Thanks for investigating, the information you provided is valuable. Next
time please open a bug report, though.
The real fix would be to not create an exports file for clang.exe, as
you suggest. It seems that the exports file is created when the
executable exports symbols (a Windows executable can act as a dll too.)
So now the question is locating where those symbols are exported. The
only place that uses dllexport is on include/clang-c/Index.h when
_CINDEX_LIB_ is true. But that macro is not defined when clang.exe is
created.
Inspecting clang.exe with depends.exe shows this two exported functions:
std::_Mutex::_Mutex(enum std::_Uninitialized)
class std::_Init_locks & std::_Init_locks::operator=(class std::_Init_locks const &)
No idea why they are there. Actually, it seems that most (all?)
executables created by the build exports those symbols and the lib
directory is plagued with .exp and .lib files corresponding to the LLVM
executables.
I have no time right now for running a build on my Windows VM (which
takes a while) but will look at the problem before the weekend, unless
someone beats me to it.