[llvm-dev] Problem with mingw32 DLL build

[Reid Kleckner via llvm-dev]

On Tue, Mar 1, 2016 at 1:32 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
>
> I don't disagree with your analysis, but I'd like to get a build bot that
> tests DLL builds with a host toolchain other than mingw32 if this is in
> fact common to those configs (as no other bot broke that i saw)... But
> that's a separate issue.
>

We don't support BUILD_SHARED_LIBS=ON with MSVC. It doesn't come with tools
that make it easy to support this configuration. CMake recently added some
support for building DLLs that export all symbols, but it's very new and
requires you to annotate all your exported global data, i.e. pass ids.

The base class isn't *just* providing the static variable. It is also
> providing the accessor method. I really like using a method instead of raw
> access to the static data member. It is also providing the name of the
> pass. So what we'd likely end up with is still having the base class but
> having a friend declaration and private static data member in the derived
> class.
>

Sure, that'd work.


> But before going there, I'd like to ask if there is another approach that
> would work: do you see any ways to effectively cause the static data member
> to be emitted reliably?
>

I'm sure we could come up with a way to get the ID emitted reliably at the
definition of the analysis, but we also need to ensure that the ID is
unique, which means we need something like the extern template declaration
in the header.

I think your idea of using CRTP to stamp out the pass name and ID accessor
is reasonable, and then we can use a normal C++ declaration/definition pair
in the derived class for the ID.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/122dfcc8/attachment.html>