[cfe-dev] cmake & vc++: clang vs. libclang woes

[Óscar Fuentes]

Eric Niebler <eric at boostpro.com> writes:

> On 4/5/2011 1:14 PM, Eric Niebler wrote:
>> 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.