[cfe-users] Clang (with Visual Studio) wrongly complains about missing variables

[David Blaikie via cfe-users]

I'm not sure it's the right/necessary solution, but one way would be to
move the function definition (for the_keyboard) out of line (define it in
some .cpp/.cc/whatever file, not in the header) - if you don't want it to
be inlined.

On Mon, Sep 20, 2021 at 6:56 AM John Emmas via cfe-users <
cfe-users at lists.llvm.org> wrote:

> On 20/09/2021 12:36, John Emmas via cfe-users wrote:
> >
> > But if I switch VS2019 to use Clang (when building the EXE) Clang's
> > linker will complain that it can't find the variable 'revision_num'.
> > But of course, 'revision_num' is an internal variable that's private
> > to the DLL [...] - so is there maybe some linker option that'll tell
> > Clang to ignore variables if the code never needs access to them?
> >
>
> Another possibility just occurred to me...  here's a real-world example
> from our code:-
>
> #if defined (BUILDING_DLL)
>    #define DLL_API __declspec(dllexport)
> #else
>    #define DLL_API __declspec(dllimport)
> #endif
>
> namespace Gtkmm2ext {
>
>    class DLL_API Keyboard
>    {
>      public:
>        Keyboard ();
>        ~Keyboard ();
>
>        static Keyboard& the_keyboard() { return *_the_keyboard };
>
>      protected:
>        static Keyboard* _the_keyboard;
>    };
>
> } /* namespace */
>
> The above example is from a DLL but when I try to build the
> corresponding EXE, Clang's linker complains that it can't find
> '_the_keyboard' - so did the compiler (maybe) implement its call to
> 'the_keyboard()' as inline code, rather than importing it from the DLL?
> Maybe for very simple code like this, Clang will try to be clever and
> implement stuff inline if it can?  And if so, is there some way to turn
> off that feature?  Thanks,
>
> John
> _______________________________________________
> cfe-users mailing list
> cfe-users at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20210920/70275c4f/attachment.html>