Undefined symbols for wxNavigationEnabled<wxNonOwnedWindow>
Tim Biedert
after having recently switched from wxWidgets 2.9.2 to 2.9.3, my
formerly working application now produces linker errors of which I'm
not sure if they're the result of an wxWidgets internal problem.
Undefined symbols for architecture x86_64:
"wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()"
"wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocus() const"
"wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocusRecursively()
const"
"wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocusFromKeyboard()
const"
"wxNavigationEnabled<wxNonOwnedWindow>::AddChild(wxWindowBase*)"
"wxNavigationEnabled<wxNonOwnedWindow>::RemoveChild(wxWindowBase*)"
I'm not actively doing anything with wxNavigationEnabled. It's the
same code which worked fine with 2.9.2 before the introduction of
wxNavigationEnabled (see blog post
http://wxwidgets.blogspot.com/2011/07/another-victory-in-war-against-macros.html)
Providing the following definitions, the application links fine again:
template<> void wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()
{}
template<> bool wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocus()
const
{ return true; }
template<> bool
wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocusRecursively() const
{ return true; }
template<> bool
wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocusFromKeyboard()
const
{ return true; }
template<> void
wxNavigationEnabled<wxNonOwnedWindow>::AddChild(wxWindowBase*)
{}
template<> void
wxNavigationEnabled<wxNonOwnedWindow>::RemoveChild(wxWindowBase*)
{}
Am I supposed to define these methods myself? Unfortunately, they are
not documented at all.
Thank you very much!
Tim
Vadim Zeitlin
TB> after having recently switched from wxWidgets 2.9.2 to 2.9.3, my
TB> formerly working application now produces linker errors of which I'm
TB> not sure if they're the result of an wxWidgets internal problem.
TB>
TB> Undefined symbols for architecture x86_64:
TB> "wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()"
Is this under OS X? How do you build wxWidgets itself and your own
application? Is the problem reproducible in the samples, e.g.
sample/minimal? Have you tried running nm to check where are these symbols
referenced from?
Looking at the code, the only idea I have is that perhaps we need to add
WXDLLIMPEXP_CORE to wxNavigationEnabled declaration in include/wx/containr.h,
could you please try if doing this (and rebuilding wxWidgets and your code,
of course) helps?
TB> Am I supposed to define these methods myself?
No, definitely not. But I don't see this problem here so I have no idea
where is it coming from...
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Stefan Csomor
>TB> after having recently switched from wxWidgets 2.9.2 to 2.9.3, my
>TB> formerly working application now produces linker errors of which I'm
>TB> not sure if they're the result of an wxWidgets internal problem.
>TB>
>TB> Undefined symbols for architecture x86_64:
>TB> "wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()"
>
> Is this under OS X? How do you build wxWidgets itself and your own
>application? Is the problem reproducible in the samples, e.g.
>sample/minimal? Have you tried running nm to check where are these symbols
>referenced from?
>
> Looking at the code, the only idea I have is that perhaps we need to add
>WXDLLIMPEXP_CORE to wxNavigationEnabled declaration in
>include/wx/containr.h,
>could you please try if doing this (and rebuilding wxWidgets and your
>code,
>of course) helps?
It's a problem when using clang for compiles, I have reverted to llvm-gcc
thereofre, since I thought it was just a buggy template instantiation, but
I'll try your suggestion and report back
Best,
Stefan
Stefan Csomor
>>TB> after having recently switched from wxWidgets 2.9.2 to 2.9.3, my
>>TB> formerly working application now produces linker errors of which I'm
>>TB> not sure if they're the result of an wxWidgets internal problem.
>>TB>
>>TB> Undefined symbols for architecture x86_64:
>>TB> "wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()"
>>
>> Is this under OS X? How do you build wxWidgets itself and your own
>>application? Is the problem reproducible in the samples, e.g.
>>sample/minimal? Have you tried running nm to check where are these
>>symbols
>>referenced from?
>>
>> Looking at the code, the only idea I have is that perhaps we need to add
>>WXDLLIMPEXP_CORE to wxNavigationEnabled declaration in
>>include/wx/containr.h,
>>could you please try if doing this (and rebuilding wxWidgets and your
>>code,
>>of course) helps?
>
>It's a problem when using clang for compiles, I have reverted to llvm-gcc
I've seen that I already had tried adding WXDLLIMPEXP_CORE to the class
declaration many months ago, but this still doesn't help. What did
however, was adding WXDLLIMPEXP_CORE to every single virtual method of
this template class Š r70787
Best,
Stefan
Vadim Zeitlin
SC> I've seen that I already had tried adding WXDLLIMPEXP_CORE to the class
SC> declaration many months ago, but this still doesn't help. What did
SC> however, was adding WXDLLIMPEXP_CORE to every single virtual method of
SC> this template class Š r70787
Unfortunately this breaks MSVC build, see e.g.
There really doesn't seem to be any way to apply DLL export declaration to
an individual member of an already DLL exported class (and it looks like
the template is somehow DLL exported by default with MSVC).
So we have the choice between defining some WXDLLIMPEXP_METHOD_CORE which
would be defined as WXDLLIMPEXP_CORE for Unix compilers (or maybe just
clang?) and nothing for the others or just reverting this change and hope
that clang will fix it in their future releases because to be honest I'm
not looking forward to explicitly annotating all template class member
functions with this macro.
What do you think?
Tim Biedert
clang. Furthermore, given the little search results on the issue, the
target group must be vanishingly small.
However, a little hint how to fix it in the documentation would be
really great!
Thank you!
Tim
On Mar 4, 1:41 am, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> On Sat, 3 Mar 2012 17:33:44 +0000 Stefan Csomor <cso...@advancedconcepts.ch> wrote:
>
> SC> I've seen that I already had tried adding WXDLLIMPEXP_CORE to the class
> SC> declaration many months ago, but this still doesn't help. What did
> SC> however, was adding WXDLLIMPEXP_CORE to every single virtual method of
> SC> this template class Š r70787
>
> Unfortunately this breaks MSVC build, see e.g.
>
> There really doesn't seem to be any way to apply DLL export declaration to
> an individual member of an already DLL exported class (and it looks like
> the template is somehow DLL exported by default with MSVC).
>
> So we have the choice between defining some WXDLLIMPEXP_METHOD_CORE which
> would be defined as WXDLLIMPEXP_CORE for Unix compilers (or maybe just
> clang?) and nothing for the others or just reverting this change and hope
> that clang will fix it in their future releases because to be honest I'm
> not looking forward to explicitly annotating all template class member
> functions with this macro.
>
> What do you think?
> VZ
>
> --
> TT-Solutions: wxWidgets consultancy and technical support
> http://www.tt-solutions.com/
>
> < 1KViewDownload
Stefan Csomor
>SC> I've seen that I already had tried adding WXDLLIMPEXP_CORE to the
>class
>SC> declaration many months ago, but this still doesn't help. What did
>SC> however, was adding WXDLLIMPEXP_CORE to every single virtual method of
>SC> this template class Š r70787
>
> Unfortunately this breaks MSVC build, see e.g.
>
>http://buildbot.tt-solutions.com/wx/builders/XPSP2%20VC9%20wxMSW%20trunk%2
>0release/builds/2561/steps/compile/logs/stdio
>
>There really doesn't seem to be any way to apply DLL export declaration to
>an individual member of an already DLL exported class (and it looks like
>the template is somehow DLL exported by default with MSVC).
Sorry, Ok, I'll try with WXDLLIMPEXP_INLINE_CORE then, this helped us the
last time in the same situation
Thanks,
Stefan
Stefan Csomor
>I agree you shouldn't modify the code in order to adept to a bug in
>clang. Furthermore, given the little search results on the issue, the
>target group must be vanishingly small.
It will come up more frequently, I've already received private mails about
this, so we should tackle it, if we can
Best,
Stefan