Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
> On 26 Nov 2014, at 19:31, Thiago Macieira wrote: > > On Wednesday 26 November 2014 10:10:15 Christophe de Dinechin wrote: >> It compiles OK, but it fails to link stating that it does not find the >> vtable for QAbstractOpenGLFunctions, referenced from the compiler-generated >> copy constructor for QAbstractOpenGLFunctions. Maybe the problem is that >> there should be a copy constructor in the class? Even if marked private, if >> the intent is that you can't copy the class (but I don't see why not). > > That class is not copyable. You must find out what caused the copy in the > first > place and shoot it down. I did find that. As I wrote earlier, if it's not copyable, then it should have a private copy constructor. Otherwise, there's no way to know, as the compiler generates an implicit copy constructor for you. Best, Christophe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
> On 26 Nov 2014, at 10:21, Konstantin Ritt wrote:
>
> struct OpenGLState : GraphicState { TaoOpenGLFunctions *funcs; ... }
> voi-la
Nope: I don't inherit the GL functions that way, so I have to rewrite every
glFoo as funcs->glFoo, which is double plus annoying. And then, there are
enough levels of indirection in the existing implementation as is, no need to
add One More Level Of Indirection™ ;-)
The copy constructor trick did it, though, so my recommendation would be to add
a copy constructor to QAbstractOpenGLFunctions.
Thanks for the help,
Christophe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
> Try with a class that has a copy constructor or with a usage pattern that > causes the compiler to generate a copy constructor. Which gives me a possible fix: in my TaoOpenGLFunctions, I can add a copy constructor that invokes the default constructor instead of the copy constructor. So I can solve my problem, but I still think this is a bug in QAbstractOpenGLFunctions. It should either provide a copy constructor, possibly private if you want to generate a compile-time error, or be marked as Q_GUI_EXPORT. Thanks, Christophe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
On 26 Nov 2014, at 09:46, Sean Harmer wrote:
>
> On Wednesday 26 Nov 2014 09:13:38 Christophe de Dinechin wrote:
>>> On 26 Nov 2014, at 09:04, Konstantin Ritt wrote:
>>>
>>> class QAbstractOpenGLFunctions
>>> (note missing Q_GUI_EXPORT)
>>
>> Do you mean this is a bug, or that I'm using it wrong and it's not supposed
>> to be visible in the library? If not, why is its destructor virtual
>> (implying that the symbol for dtor and vtable at least should be exported).
>
> How are you trying to use this class? It's not meant to be used directly but
> rather one of it's concrete subclasses.
I'm not using it directly. I have something that looks like this:
#include
#if QT_VERSION < 0x050100
struct TaoOpenGLFunctions {};
// additional stuff to get glew.h
#else
# include
struct TaoOpenGLFunctions : QOpenGLFunctions_3_0 {};
#endif
struct OpenGLState : GraphicState, TaoOpenGLFunctions { ... }
It compiles OK, but it fails to link stating that it does not find the vtable
for QAbstractOpenGLFunctions, referenced from the compiler-generated copy
constructor for QAbstractOpenGLFunctions. Maybe the problem is that there
should be a copy constructor in the class? Even if marked private, if the
intent is that you can't copy the class (but I don't see why not).
> We've been using the concrete
> subclasses in a number of projects and have not had any problem.
Try with a class that has a copy constructor or with a usage pattern that
causes the compiler to generate a copy constructor.
Thanks
Christophe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Unsatisfied symbols for QAbstractOpenGLFunctions
> On 26 Nov 2014, at 09:04, Konstantin Ritt wrote: > > class QAbstractOpenGLFunctions > (note missing Q_GUI_EXPORT) Do you mean this is a bug, or that I'm using it wrong and it's not supposed to be visible in the library? If not, why is its destructor virtual (implying that the symbol for dtor and vtable at least should be exported). Thanks Christophe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Unsatisfied symbols for QAbstractOpenGLFunctions
I'm trying to adapt Tao3D (http://tao3d.sourceforge.net) to the "new" way of doing OpenGL on Qt. I run into unsatisfied symbols for QAbstractOpenGLFunctions (specifically, the vtable and the destructor), despite the fact that QOpenGLFunctions_3_0 (which derives from QAbstractOpenGLFunctions) is present in the libQtGui.a library. I'm using the MinGW binaries from the installer. Why would a derived class be in the library if the base class is not? $ nm libQt5Gui.a | grep QOpenGLFunctions_3_0 I __imp___ZTV20QOpenGLFunctions_3_0 I __nm___ZTV20QOpenGLFunctions_3_0 I __imp___ZTI20QOpenGLFunctions_3_0 I __nm___ZTI20QOpenGLFunctions_3_0 T __ZN20QOpenGLFunctions_3_0D2Ev I __imp___ZN20QOpenGLFunctions_3_0D2Ev T __ZN20QOpenGLFunctions_3_0D1Ev I __imp___ZN20QOpenGLFunctions_3_0D1Ev T __ZN20QOpenGLFunctions_3_0D0Ev I __imp___ZN20QOpenGLFunctions_3_0D0Ev T __ZN20QOpenGLFunctions_3_0C2Ev I __imp___ZN20QOpenGLFunctions_3_0C2Ev T __ZN20QOpenGLFunctions_3_0C1Ev I __imp___ZN20QOpenGLFunctions_3_0C1Ev T __ZN20QOpenGLFunctions_3_025initializeOpenGLFunctionsEv I __imp___ZN20QOpenGLFunctions_3_025initializeOpenGLFunctionsEv T __ZN20QOpenGLFunctions_3_019isContextCompatibleEP14QOpenGLContext I __imp___ZN20QOpenGLFunctions_3_019isContextCompatibleEP14QOpenGLContext T __ZN20QOpenGLFunctions_3_014versionProfileEv I __imp___ZN20QOpenGLFunctions_3_014versionProfileEv $ nm libQt5Gui.a | grep QAbstractOpenGL [nothing] Christophe de Dinechin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
