octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGW: 'QUnixTerminalImpl' has not been declared


From: Michael Goffioul
Subject: Re: MinGW: 'QUnixTerminalImpl' has not been declared
Date: Sat, 22 Sep 2012 11:13:05 -0400

On Sat, Sep 22, 2012 at 2:40 AM, Daniel J Sebald <address@hidden> wrote:
On 09/20/2012 03:28 PM, Philip Nienhuis wrote:
Michael Goffioul wrote:
On Thu, Sep 20, 2012 at 4:07 PM, Philip Nienhuis
<address@hidden <mailto:address@hiddennet>> wrote:

Michael Goffioul wrote
> On Thu, Sep 20, 2012 at 5:46 AM, Daniel J Sebald &lt;

> daniel.sebald@

> &gt;wrote:
>
>>
>>> In the attached patch I replaced setenv with octave_putenv since
>>>> "lo-utils.h" is already include in the list of header files.
>>>> (octave_env::putenv() is a simple call to octave_putenv. John,
if we
>>>> should be using OOP over library call, let us know.) Please
give that a
>>>> try under MinGW.
>>>>
>>>
>>> OK using your patch the build continues until:
>>>
>>> :
>>> libtool: compile: g++ -shared-libgcc -DHAVE_CONFIG_H -I.
>>> -I../../octave/libgui -I..
>>> -IX:/programs/msys/home/**Philip/qt4/qt-everywhere-**
>>> opensource-src-4.7.4/include
>>> -IX:/programs/msys/home/**Philip/qt4/qt-everywhere-**
>>> opensource-src-4.7.4/include/**QtCore
>>> -IX:/programs/msys/home/**Philip/qt4/qt-everywhere-**
>>> opensource-src-4.7.4/include/**QtGui
>>> -I.././octave/libgui/**qterminal/libqterminal -DUNICODE
>>> -I/x/Programs/gplibs/include -I/x/Programs/OctaveLibs/**include
>>> -I/x/programs/GnuWin32/include -mieee-fp
>>> -Ic:/Programs/gplibs/include/**freetype2
-Ic:/Programs/gplibs/include
>>> -IX:/Programs/gplibs/include -g -O2 -MT qterminal/libqterminal/**
>>> qterminal
>>> _libqterminal_la-moc-**QTerminal.lo -MD -MP -MF
>>> qterminal/libqterminal/.deps/**qterminal_libqterminal_la-moc-**
>>> QTerminal.Tpo
>>> -c qterminal/libqterminal/moc-**QTerminal.cc -DDLL_EXPORT -DPIC -o
>>> qterminal/libqterminal/.libs/**qterminal_libqterminal_la-moc-**
>>> QTerminal.oqterminal/**libqterminal/moc-QTerminal.cc:**41:8:
>>> error: 'QUnixTerminalImpl' has not been declared
>>> qterminal/libqterminal/moc-**QTerminal.cc: In member function
'virtual
>>> void* QTerminal::qt_metacast(const char*)':
>>> qterminal/libqterminal/moc-**QTerminal.cc:59:12: error:
>>> 'QUnixTerminalImpl' has not been declared
>>> qterminal/libqterminal/moc-**QTerminal.cc: In member function
'virtual
>>> int
>>> QTerminal::qt_metacall(**QMetaObject::Call, int, void**)':
>>> qterminal/libqterminal/moc-**QTerminal.cc:64:11: error:
>>> 'QUnixTerminalImpl' has not been declared
>>> make[3]: ***
>>>
[qterminal/libqterminal/**qterminal_libqterminal_la-moc-**QTerminal.lo]
>>> Error 1
>>> make[3]: Leaving directory `/home/Philip/octdev/oct-3.7/**libgui'
>>> make[2]: *** [all] Error 2
>>> make[2]: Leaving directory `/home/Philip/octdev/oct-3.7/**libgui'
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory `/home/Philip/octdev/oct-3.7'
>>> make: *** [all] Error 2
>>>
>>
>> I haven't forgotten about this compile issue; there hasn't been
enough
>> time to get to it.
>>
>> Clearly there is no reason a Windows build should want to access
>> QUnixTerminalImpl, so we'll have to place some conditional
pre-compile
>> statements around some code somewhere. I'll attempt that and
add the
>> setenv/putenv fix in the same patch and place it on Savannah bug
track
>> Thursday or Friday. That way if we find more we can update the
patch in
>> the bug tracker.
>>
>
> Does the moc command include the flag -DWIN32? (it should)

You mean in <SRCDIR>/libgui/Makefile.am? It contains:

:
MOC_CPPFLAGS =


It's modified in qterminal-module.mk <http://qterminal-module.mk>.

That contains:

:
if WIN32_TERMINAL

qterminal_libqterminal_la_SOURCES = \
qterminal/libqterminal/win32/QTerminalColors.cpp \
qterminal/libqterminal/win32/QWinTerminalImpl.cpp

qterminal_libqterminal_la_MOC += \
qterminal/libqterminal/win32/moc-QWinTerminalImpl.cc

qterminal_libqterminal_la_CPPFLAGS += -DUNICODE

# This flag is required to let MOC know about Q_OS_WIN32.
MOC_CPPFLAGS += -DWIN32
:

so apparently WIN32_TERMINAL wasn't declared properly somewhere.
(BTW IIRC the ".... += -DUNICODE" was from a patch you sent me a while
ago.)

Not necessarily.  The -DWIN32 flag is expected to trigger something in the tools that will eventually define Q_OS_WIN32, I'm guessing.  Verify that that is in fact happening.  You can do this by searching for Q_OS_WIN32 used in a make file or such.  On my unix system I don't see Q_OS_WIN32 anywhere other than a couple "#if" precompile conditionals.

Not likely, but it wouldn't surprise me if Q_OS_WIN32 isn't being generated on your system.  I have no idea how the Windows users are actually building Octave, but I often see things about MinGW or something else that sounds like an emulator of sorts.  Perhaps the tools don't feel that this is true Windows compilation.

So, my suggestion is to be systematic.  First check that your config.status file shows

     S["WIN32_TERMINAL_FALSE"]="#"
     S["WIN32_TERMINAL_TRUE"]=""

then check that Q_OS_WIN32 is defined somewhere.  I think that the first definitions being correct and the latter (Q_OS_WIN32) not would result in the errors you are seeing.

The moc-QTerminal.cc file is

** Meta object code from reading C++ file 'QTerminal.h'

so if this MOC looks in QTerminal.h and Q_OS_WIN32 is not defined the MOC will create a moc-QTerminal.cc file with

const QMetaObject QTerminal::staticMetaObject = {
    { &QUnixTerminalImpl::staticMetaObject, qt_meta_stringdata_QTerminal,
      qt_meta_data_QTerminal, 0 }
};

where line 41, position 8 is the &QUnixTerminalImpl line in my unix-generated file.

Q_OS_WIN32 is a Qt-specific macro that is defined in qglobal.h. It is defined on Windows system, when WIN32, _WIN32 or __WIN32__ macro is defined. One of these macro is always defined by MinGW or MSVC. But the problem here is not about compiling with MinGW/MSVC, it is about moc-file generation with MOC. The moc tool does NOT define the above macros automatically, so you need to provide them manually. If you don't, then the MOC-internal C++ parser will not have Q_OS_WIN32 defined and wrong code will be generated. When you use qmake, this is not a problem, because the qmake-generated Makefiles will add the required macros on the moc command line. However, this was lost when we moved to autotools, even for moc-generation. So we need to provide at least one Windows-specific macro to moc to have the proper code generated.

Normally, the -DWIN32 flag is provided to MOC when detecting a Win32-terminal system. This is achieved using automake conditional, based on the canonical host type (see configure.ac). So Philip is right, it looks like the automake condition WIN32_TERMINAL is not set to true as it should.

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]