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: Philip Nienhuis
Subject: Re: MinGW: 'QUnixTerminalImpl' has not been declared
Date: Tue, 25 Sep 2012 13:45:44 -0700 (PDT)

Michael Goffioul wrote
> On Sat, Sep 22, 2012 at 2:40 AM, Daniel J Sebald <

> daniel.sebald@

> >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:

> prnienhuis@

> .**net<

> address@hidden

> >>>
>>>> wrote:
>>>>
>>>> Michael Goffioul wrote
>>>> > On Thu, Sep 20, 2012 at 5:46 AM, Daniel J Sebald <
>>>>
>>>> > daniel.sebald@
>>>>
>>>> > >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
>>>> &lt;http://qterminal-module.mk&gt;.
>>>>
>>>
>>> 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.

Just an update:

I simply hand-edited configure.ac (added win32-terminal=yes) just to check
if compilation worked (I know, brute force). And it seemed to help.

But then it turned out that compilation somewhere in libgui broke with
"Fquit not declared in this scope".
Comparing my (working) Linux build from the very same source (parent:
15438:e39a51e0d54b tip) it turns out that indeed in
<BUILD>/libinterp/builtin-defun-decls.h the statement DEFUN_DECL (Fquit) is
missing (+ several more).
So does Fquit (or quit() ?) exist in MinGW?

Anyway, time to give up. Next week I'll hopefully have more time.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/MinGW-build-error-setenv-was-not-declared-in-this-scope-tp4644240p4644626.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


reply via email to

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