Tommaso Cucinotta schreef:
CXX GuiView.o
GuiView.cpp: In member function ‘virtual void
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest&,
lyx::DispatchResult&)’:
GuiView.cpp:2997: error: no matching function for call to
‘lyx::frontend::GuiView::lfunUiToggle(const char [11])’
GuiView.h
CXX GuiView.o
GuiView.cpp: In member function ‘virtual void
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest&,
lyx::DispatchResult&)’:
GuiView.cpp:2997: error: no matching function for call to
‘lyx::frontend::GuiView::lfunUiToggle(const char [11])’
GuiView.h:300: note: candidates are: v
Hi Abdel,
"blame" is suggesting, I have to address you ...
[ 62%] Building CXX object
src/CMakeFiles/lyx.dir/usr/src/lyx/lyx-devel/src/BufferView.o
cd /usr/BUILD/BuildLyx/src && /usr/bin/c++ -DQT_NO_STL -DQT_NO_KEYWORDS
-DHAVE_GETTEXT -DUSE_HUNSPELL=1 -DENABLE_NLS=1 -
DUSE_ASPELL=1 -DHAVE_ICON
Helge Hafting writes:
> Abdelrazak Younes wrote:
>> rgheck wrote:
>>>
>>> I reported this a while back, and the advice was to use external boost.
>>
>> Well even if the advice is true this should be fixed. gcc-4.4 is out
>> so we should support it. Maybe it is just a matter of upgrading our
>> in
Helge Hafting wrote:
Abdelrazak Younes wrote:
rgheck wrote:
I reported this a while back, and the advice was to use external boost.
Well even if the advice is true this should be fixed. gcc-4.4 is out
so we should support it. Maybe it is just a matter of upgrading our
internal boost?
If
Abdelrazak Younes wrote:
rgheck wrote:
I reported this a while back, and the advice was to use external boost.
Well even if the advice is true this should be fixed. gcc-4.4 is out so
we should support it. Maybe it is just a matter of upgrading our
internal boost?
If external boost works s
Original-Nachricht
> Datum: Thu, 09 Jul 2009 18:04:51 +0200
> Von: Jean-Marc Lasgouttes
> An: Abdelrazak Younes
> CC: rgheck , LyX Developers
> Betreff: Re: boost in trunk does not compile with gcc-4.4
> Abdelrazak Younes writes:
>
> > rgheck
Abdelrazak Younes writes:
> rgheck wrote:
>>
>> I reported this a while back, and the advice was to use external boost.
>
> Well even if the advice is true this should be fixed. gcc-4.4 is out
> so we should support it. Maybe it is just a matter of upgrading our
> internal boost?
Yes. We have ve
rgheck wrote:
I reported this a while back, and the advice was to use external boost.
Well even if the advice is true this should be fixed. gcc-4.4 is out so
we should support it. Maybe it is just a matter of upgrading our
internal boost?
Abdel.
I reported this a while back, and the advice was to use external boost.
rh
[ 0%] Building CXX object
src/support/CMakeFiles/support.dir/home/younes/devel/lyx/trunk/src/support/ForkedCalls.o
cd
/home/younes/devel/lyx/trunk/development/cmake/qtcreator-build/src/support
&& /us
Am Freitag 21 November 2008 schrieb Pavel Sanda:
> this is a linker problem and i think it will diappear if you make distclean
> your tree or do a build from fresh sources.
> pavel
Thanks Pavel. This is not the first time I had to make distclean. I should
have had remembered.
Kornel
--
Kornel Benko wrote:
> Hi,
> this is on ubuntu 8.10 with gcc 4.3.2.
> ...
> make[4]: Entering directory `/usr/BUILD/BuildLyxConfigure/src'
> g++ -g -O -o lyx main.o ASpell.o SpellBase.o BiblioInfo.o Box.o
> Dimension.o
> PrinterParams.o Thesaurus.o liblyxcore.a liblyxmathed.a liblyxinsets.a
>
Hi,
this is on ubuntu 8.10 with gcc 4.3.2.
...
make[4]: Entering directory `/usr/BUILD/BuildLyxConfigure/src'
g++ -g -O -o lyx main.o ASpell.o SpellBase.o BiblioInfo.o Box.o Dimension.o
PrinterParams.o Thesaurus.o liblyxcore.a liblyxmathed.a liblyxinsets.a
frontends/liblyxfrontends.a frontend
Tommaso Cucinotta wrote:
> In order to compile, I need this, on my system
make distclean should be sufficient.
Jürgen
In order to compile, I need this, on my system
* Ubuntu Intrepid
* gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,obj
g++ -o debug/src/client/client.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -pthread -DQT_GUI_LIB
-DQT_SHARED -Idebug/src -Isrc -Isrc -I/usr/include -I/usr/include/qt4
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
src/client/client.cpp
src/client/client.cpp: In function 'int main(int, c
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
I would be surprised.
You'd be surprised if we didn't complain? Are we, as a group, that docile?
No, I'd be surprised that 4.3 cannot accept code that is valid in 4.2.
At least the documentation sugg
Richard Heck <[EMAIL PROTECTED]> writes:
>> I would be surprised.
> You'd be surprised if we didn't complain? Are we, as a group, that docile?
No, I'd be surprised that 4.3 cannot accept code that is valid in 4.2.
JMarc
Jean-Marc Lasgouttes wrote:
Because then I would have used QDrag::start, just to get complains by
Qt 4.3 people that it does not complile.
I would be surprised.
You'd be surprised if we didn't complain? Are we, as a group, that docile?
rh
Stefan Schimanski <[EMAIL PROTECTED]> writes:
>> Why cannot people use qt 4.2 for development? We have had a lot of
>> compatibility problems with qt 4.3.
I use Qt4.2 too. Usually problems are noticed pretty fast. What I am
not sure about, though, is whether somebody tests LyX 1.5.x with Qt 4.1.
On Saturday 15 March 2008 03:26:59 rgheck wrote:
> (Does F9 include 4.4? That's alpha right now
> anyway)
No. It usually enters rawhide (to be F9 now) when it is in the release
candidate stage. Since we one month away from F9 planned release I am sure it
will not come with F9. The scheduled
Am 15.03.2008 um 04:39 schrieb Bo Peng:
What to do about QDrag::exec is another question. Presumably Andre
will
have a good idea.
Why cannot people use qt 4.2 for development? We have had a lot of
compatibility problems with qt 4.3.
Because then I would have used QDrag::start, just to get
> What to do about QDrag::exec is another question. Presumably Andre will
> have a good idea.
Why cannot people use qt 4.2 for development? We have had a lot of
compatibility problems with qt 4.3.
Bo
rgheck wrote:
Bo Peng wrote:
src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'
Should we bump QT requirement to 4.3???
Oh, no, not another one of THESE discussions! I think the last time we
discussed this issue, we came to some kind of agreement that w
Bo Peng wrote:
src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'
Should we bump QT requirement to 4.3???
Oh, no, not another one of THESE discussions! I think the last time we
discussed this issue, we came to some kind of agreement that we'd stay
"a ve
src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no
member named 'exec'
Should we bump QT requirement to 4.3???
Bo
Am 14.03.2008 um 23:48 schrieb Bo Peng:
src/frontends/qt4/GuiToolbar.cpp: In member function 'void
lyx::frontend::GuiLayoutBox::setIconSize(QSize)':
src/frontends/qt4/GuiToolbar.cpp:663: error: 'WA_MacSmallSize' is not
a member of 'Qt'
src/frontends/qt4/GuiToolbar.cpp:664: error: 'WA_MacNormalS
src/frontends/qt4/GuiToolbar.cpp: In member function 'void
lyx::frontend::GuiLayoutBox::setIconSize(QSize)':
src/frontends/qt4/GuiToolbar.cpp:663: error: 'WA_MacSmallSize' is not
a member of 'Qt'
src/frontends/qt4/GuiToolbar.cpp:664: error: 'WA_MacNormalSize' is not
a member of 'Qt'
Missing #ifdef
On Sat, Oct 13, 2007 at 11:51:47PM +0200, Uwe Stöhr wrote:
> Unfortunately I could also not use Qt 4.2's designer - it doesn't start
> because my system config is for Qt 4.3, and when I change the config back
> to Qt 4.2, I couldn't compile using Qt 4.3.
Not sure what "system config" means in th
> For now the workaround is: open the layout with Qt 4.2's designer and save it.
I updated the ui file using qt422.
Bo
This is because I used Qt 4.3's designer. I don't know why this doesn't compile with Qt 4.2. I
googled and couldn't found a hint on trolltech.com where this behaviour is described.
Unfortunately I could also not use Qt 4.2's designer - it doesn't start because my system config is
for Qt 4.3, and
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h: In member function 'void
Ui_HyperlinkUi::setupUi(QDialog*)':
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h:45: error: 'class
QGridLayout' has no member named 'setLeftMargin'
try1/src/frontends/qt4/ui/ui_HyperlinkUi.h:46: error: 'class
QGridLayout' has no mem
On Thu, 06 Sep 2007 10:01:31 -0500
Bo Peng <[EMAIL PROTECTED]> wrote:
> g++ -o try1/src/MenuBackend.o -c
> -I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -Itry1/src -Isrc -Isrc
> -Itry1/intl -Iintl src/MenuBackend.cpp
> src/MenuBackend.cpp: In member function `lyx::Menu&
> lyx::Menu::read(lyx::Lex
g++ -o try1/src/MenuBackend.o -c
-I/home/bpeng/lyx-devel/lyx-1.6-rw/boost -g -O -Itry1/src -Isrc -Isrc
-Itry1/intl -Iintl src/MenuBackend.cpp
src/MenuBackend.cpp: In member function `lyx::Menu&
lyx::Menu::read(lyx::Lexer&)':
src/MenuBackend.cpp:306: error: `Elements' is not a member of `lyx::MenuIt
Bo Peng wrote:
So you think this is acceptable?
For day to day development, yes.
But please try not to break the trunk.
I am trying hard in general. Just not in this case.
Abdel.
> > So you think this is acceptable?
>
> For day to day development, yes.
But please try not to break the trunk.
> On the contrary, for development I want performance first.
...
Bo
Bo Peng wrote:
??? That's the basic idea behind pch. The same thing would happen with
scons I think.
So you think this is acceptable?
For day to day development, yes.
I did not add pch to scons because of
this exact reason. I want a reliable build more than performance.
On the contrary, f
> ??? That's the basic idea behind pch. The same thing would happen with
> scons I think.
So you think this is acceptable? I did not add pch to scons because of
this exact reason. I want a reliable build more than performance.
Bo
Bo Peng wrote:
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this time.
This is about cmake's allowing you to compile a lyx.exe without this header.
???
> > Please try to fix cmake.
>
> This is not about fixing cmake but about me not being careful enough.
> pch support can be disabled in CMake. In general I am careful with new
> header but I forgot this time.
This is about cmake's allowing you to compile a lyx.exe without this header.
Bo
Bo Peng wrote:
Thanks, sorry for the inconvenience.
So this is another pch problem???
Yes.
Please try to fix cmake.
This is not about fixing cmake but about me not being careful enough.
pch support can be disabled in CMake. In general I am careful with new
header but I forgot this time.
>
> Thanks, sorry for the inconvenience.
So this is another pch problem??? Please try to fix cmake.
Bo
Alfredo Braunstein wrote:
Bo Peng wrote:
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
fixed.
Thanks, sorry for the inconvenience.
Abdel.
Bo Peng wrote:
> src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
> type `struct QTabBar'
> /home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
> forward declaration of `struct QTabBar'
fixed.
A/
src/frontends/qt4/GuiView.cpp:126: error: invalid use of undefined
type `struct QTabBar'
/home/bpeng/lyx-devel/qt422/include/QtGui/qtabwidget.h:36: error:
forward declaration of `struct QTabBar'
If this is another 4.3 only stuff, please make qt 4.3 the minimal
required version for lyx 1.6.0, OR i
My copy of qt is 4.3.0. It must have added these. I'll remove them
manually. That should fix the problem.
rh
Georg Baum wrote:
with qt 4.2.1:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-I../../.
with qt 4.2.1:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-I../../../../src -I../../../../src/frontends -I../../../../images -DQT_SHARED
-I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4
Edwin Leuven wrote:
> Bernhard Roider wrote:
>> Hello,
>>
>> Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the
>> default constructor from class OutputParams but it is needed by the
>> local variable runparams in the method InsetMathMBox::write(..)
>
> i did the attached to m
Bernhard Roider wrote:
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the
default constructor from class OutputParams but it is needed by the
local variable runparams in the method InsetMathMBox::write(..)
i did the attached to make it compile. haven't seen any regr
Hello,
Changeset 17470 (http://www.lyx.org/trac/changeset/17470) removed the default constructor from class
OutputParams but it is needed by the local variable runparams in the method InsetMathMBox::write(..)
Bernhard
51 matches
Mail list logo
