[LLVMdev] Using C++'11 language features in LLVM itself
Robinson, Paul
Paul.Robinson at am.sony.com
Fri Jan 11 11:53:05 PST 2013
On Jan 11, 2013, at 9:50 AM, [mdaniels at lanl.gov] wrote:
> On Jan 11, 2013, at 10:02 AM, dag at cray.com wrote:
>
> > "Daniels, Marcus G" <mdaniels at lanl.gov> writes:
> >
> >> Anyway, I thought the question here amounted to how to ensure that
> >> people can make binaries of LLVM libraries and a working clang
> >> executable on Windows.
> >
> > No, it's more than that. Many (most?) groups integrate clang and/or
> > llvm libraries into larger projects.
>
>
> So it's not a problem that the C++ ABI mapping between clang and MSVC
> isn't quite perfect, but it is a problem if the compiled form of the
> library isn't embeddable in MSVC projects?
Exactly.
> Once you've got the MSVC-built library, you can't blindly count on
> using in conjunction with other MSVC generated things.
That's true for any third-party library. IIRC it's a problem even
for Microsoft's own DLLs, I think I've had to tweak my defines so
my debug/release projects exactly match what MS did for its own RTLs.
Incredibly annoying but I think MSVC users are used to this kind of thing.
> I could see there are examples where this wouldn't matter like
> OpenCL implementations. If there is a desire to close the loop
> (a Windows hosted clang that is interoperable with MSVC), it is in
> some sense useful if Mingw or clang generated object code doesn't
> quite mimic MSVC. That will provide further motive to examine the
> issues.
This is not the goal (at least, not *my* goal). My goal is to
permit an MSVC user to build a Windows-hosted tool with all the
Windows bells and whistles, that can use the delivered Clang/LLVM
libs, which consequently must be built with the same MSVC version
as the tool that's trying to use them. You cannot do this, in
general, if Clang/LLVM are built with MinGW.
Interoperability of Clang-built and MSVC-built binaries would be a
longer-term goal of the Clang/LLVM projects, and I am pleased to
see progress in those areas, but it's not all there yet.
--paulr
More information about the llvm-dev
mailing list