<div dir="ltr">Looking back in the thread, I found the example code, and I see that MSVC refuses to inline this helper, but clang will inline it. I believe clang is permitted to inline it, MSVC will export the static data member (_the_keyboard), so everything should work as long as you provide a definition of _the_keyboard in the DLL and set -DBUILDING_DLL.<div><br></div><div>Example:</div><div><br></div><div>$ cat t.cpp<br>#if defined (BUILDING_DLL)<br>   #define DLL_API __declspec(dllexport)<br>#else<br>   #define DLL_API __declspec(dllimport)<br>#endif<br>   class DLL_API Keyboard<br>   {<br>     public:<br>       Keyboard ();<br>       ~Keyboard ();<br>       static Keyboard& the_keyboard() { return *_the_keyboard; }<br>     protected:<br>       static Keyboard* _the_keyboard;<br>   };<br>#if defined(BUILDING_DLL)<br>Keyboard *Keyboard::_the_keyboard = nullptr;<br>#else<br>Keyboard &useit() { return Keyboard::the_keyboard(); }<br>#endif<br><br>$ cl -c t.cpp  -O2 -DBUILDING_DLL && dumpbin -directives t.obj</div><div>...<br>   /EXPORT:?_the_keyboard@Keyboard@@1PEAV1@EA,DATA<br>...</div><div><br></div><div>clang-cl does support /Ob0 if you want to prevent it from inlining, but that's a big hammer, you could use __declspec(noinline) as a more targeted workaround.</div><div><br></div><div>So, I think this just comes down to different inliner heuristics in MSVC and clang. If you provide and export a definition of this static global, things should link as expected.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 22, 2021 at 9:50 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Probably Reid and Hans are folks to start with for Windows support</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 22, 2021 at 4:38 AM Jeffrey Walton via cfe-users <<a href="mailto:cfe-users@lists.llvm.org" target="_blank">cfe-users@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Sep 22, 2021 at 7:21 AM John Emmas via cfe-users<br>
<<a href="mailto:cfe-users@lists.llvm.org" target="_blank">cfe-users@lists.llvm.org</a>> wrote:<br>
><br>
> On 21/09/2021 14:24, John Emmas via cfe-users wrote:<br>
> ><br>
> > clang-cl /? reveals that it'll handle the Microsoft variant of /Ob0<br>
> > ...<br>
> All the signs here are that Clang is still trying to inline stuff - even<br>
> when it's been told not to... so is there some way I could check if it<br>
> responds correctly to "/Ob0"?  Maybe ask a question on cfe-dev ?<br>
<br>
LLVM dev would probably be a good place to bring up the topic.<br>
<br>
Several people work on the Windows port. There's one person in<br>
particular who does most of the heavy lifting (but I don't recall the<br>
person's name). LLVM dev is where to find the people.<br>
<br>
Jeff<br>
_______________________________________________<br>
cfe-users mailing list<br>
<a href="mailto:cfe-users@lists.llvm.org" target="_blank">cfe-users@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users</a><br>
</blockquote></div>
</blockquote></div>