trunk does no compile

As in the subject: insets/InsetTabular.cpp: In member function ‘int lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’: insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’ in

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta: insets/InsetTabular.cpp: In member function ‘int lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’: insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’ in

Re: trunk does no compile

On 29.01.2011 13:24, Kornel wrote: Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta: insets/InsetTabular.cpp: In member function ‘int lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’: insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’ in

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Peter Kümmel: This cured it for me, but I fear it is not the proper c++ patch. Kornel Yes, the cast isn't nice. Does attached patch also fix the problem? If yes, I think you could commit it. Peter Yes, it compiles now. Kornel

Re: trunk does no compile

I can confim that trunk doesn't compile for me either: insets/InsetTabular.cpp:2259: error: ambiguous overload for ‘operator’ in ‘lyx::operator(((lyx::otexstream)((lyx::otexstream*)os)), ((const char*)\\multirow{)) lyx::Tabular::rowSpan(cell)’ ./support/docstream.h:154: note: candidates are:

Re: trunk does no compile

On Sat, Jan 29, 2011 at 02:23:04PM +0100, Kornel wrote: Am Samstag, 29. Januar 2011 schrieb Peter Kümmel: This cured it for me, but I fear it is not the proper c++ patch. Kornel Yes, the cast isn't nice. Does attached patch also fix the problem? If yes, I think you

Re: trunk does no compile

Il 29/01/2011 15:54, Enrico Forestieri ha scritto: Please, don't. It breaks compilation if size_t is typedef'd to unsigned int. I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream class itself. Assuming the latter works fine

Re: trunk does no compile

Il 29/01/2011 17:07, Tommaso Cucinotta ha scritto: Il 29/01/2011 15:54, Enrico Forestieri ha scritto: Please, don't. It breaks compilation if size_t is typedef'd to unsigned int. I can also share my template-based one, that avoids code replication and actually turns this burden over the

Re: trunk does no compile

Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream class itself. Assuming the latter works fine on all architectures, this one should as well :-). Forgot to attach.

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: Yes, the cast isn't nice. Does attached patch also fix the problem? If yes, I think you could commit it. Please, don't. It breaks compilation if size_t is typedef'd to unsigned int. Yes, it compiles now. Kornel, does it

Re: trunk does no compile

Il 29/01/2011 18:37, Kornel ha scritto: Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: Yes, the cast isn't nice. Does attached patch also fix the problem? If yes, I think you could commit it. Please, don't. It breaks compilation if size_t is typedef'd to unsigned int.

Re: trunk does no compile

On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream class itself. Assuming the latter works fine on all

Re: trunk does no compile

On Sat, Jan 29, 2011 at 06:37:44PM +0100, Kornel wrote: Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: Yes, the cast isn't nice. Does attached patch also fix the problem? If yes, I think you could commit it. Please, don't. It breaks compilation if size_t is typedef'd to

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at the first attempt of typing a character in text-mode LyX was asserting :-). I'm using the Enrico's patch

Re: trunk does no compile

Am 29.01.2011 um 19:12 schrieb Enrico Forestieri: On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream

Re: trunk does no compile

On Sat, Jan 29, 2011 at 08:06:37PM +0100, Stephan Witt wrote: Am 29.01.2011 um 19:12 schrieb Enrico Forestieri: On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: I can also share my template-based one, that avoids

Re: trunk does no compile

On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote: overload-2.diff: Compiles fine too. Thanks for testing. Tommaso: Ok, apart from compiling, is it only me who's experience a crash when typing any character in text mode (seems it was not at all due to my template-based patch of

Re: trunk does no compile

On 29 January 2011 16:49, Enrico Forestieri for...@lyx.org wrote: On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote: Tommaso: Ok, apart from compiling, is it only me who's experience a crash when typing any character in text mode (seems it was not at all due to my template-based

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Guillaume Pothier: I don't get it. You mean TeX-mode? Cannot see any crash here. Same here. I'm getting the crash when loading a file: Not here. Insert-File-Plain Text... is ok, and so is ...-Plain Text, Join Lines Kornel signature.asc

Re: trunk does no compile

Il 29/01/2011 19:12, Enrico Forestieri ha scritto: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at the first attempt of typing a character in text-mode LyX was asserting :-). I'm using the Enrico's patch that works fine (at

Re: trunk does no compile

Il 30/01/2011 01:28, Tommaso Cucinotta ha scritto: If it is the same currently committed, then it is sufficient to: -) create a new file -) type any letter and kaboom! So, on my system, I need the patch below in order to be able to use LyX trunk again (r37368): Index: src/Paragraph.cpp

Re: trunk does no compile

On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 19:12, Enrico Forestieri ha scritto: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at the first attempt of typing a character in text-mode

Re: trunk does no compile

Am 30.01.2011 um 02:23 schrieb Enrico Forestieri: On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote: Il 29/01/2011 19:12, Enrico Forestieri ha scritto: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at

trunk does no compile

As in the subject: insets/InsetTabular.cpp: In member function ‘int lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’: insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’ in

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta: > insets/InsetTabular.cpp: In member function ‘int > lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’: > insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’ > in >

Re: trunk does no compile

On 29.01.2011 13:24, Kornel wrote: > Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta: >> insets/InsetTabular.cpp: In member function ‘int >> lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’: >> insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Peter Kümmel: > > This cured it for me, but I fear it is not the proper c++ patch. > > > > > > > > Kornel > > Yes, the cast isn't nice. Does attached patch also fix the problem? > If yes, I think you could commit it. > > Peter Yes, it compiles now.

Re: trunk does no compile

I can confim that trunk doesn't compile for me either: insets/InsetTabular.cpp:2259: error: ambiguous overload for ‘operator<<’ in ‘lyx::operator<<(((lyx::otexstream&)((lyx::otexstream*)os)), ((const char*)"\\multirow{")) << lyx::Tabular::rowSpan(cell)’ ./support/docstream.h:154: note: candidates

Re: trunk does no compile

On Sat, Jan 29, 2011 at 02:23:04PM +0100, Kornel wrote: > Am Samstag, 29. Januar 2011 schrieb Peter Kümmel: > > > This cured it for me, but I fear it is not the proper c++ patch. > > > > > > > > > > > > Kornel > > > > Yes, the cast isn't nice. Does attached patch also fix the problem? > >

Re: trunk does no compile

Il 29/01/2011 15:54, Enrico Forestieri ha scritto: Please, don't. It breaks compilation if size_t is typedef'd to unsigned int. I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream class itself. Assuming the latter works fine

Re: trunk does no compile

Il 29/01/2011 17:07, Tommaso Cucinotta ha scritto: Il 29/01/2011 15:54, Enrico Forestieri ha scritto: Please, don't. It breaks compilation if size_t is typedef'd to unsigned int. I can also share my template-based one, that avoids code replication and actually turns this burden over the

Re: trunk does no compile

Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: I can also share my template-based one, that avoids code replication and actually turns this burden over the odocstream class itself. Assuming the latter works fine on all architectures, this one should as well :-). Forgot to attach.

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: > > > Yes, the cast isn't nice. Does attached patch also fix the problem? > > > If yes, I think you could commit it. > > Please, don't. It breaks compilation if size_t is typedef'd to unsigned > int. > > > Yes, it compiles now. > > Kornel,

Re: trunk does no compile

Il 29/01/2011 18:37, Kornel ha scritto: Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: > > > Yes, the cast isn't nice. Does attached patch also fix the problem? > > > If yes, I think you could commit it. > > Please, don't. It breaks compilation if size_t is typedef'd to unsigned >

Re: trunk does no compile

On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: > Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: > > > >>I can also share my template-based one, that avoids code replication > >>and actually turns this burden over the odocstream class itself. > >>Assuming > >>the latter

Re: trunk does no compile

On Sat, Jan 29, 2011 at 06:37:44PM +0100, Kornel wrote: > Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: > > > > Yes, the cast isn't nice. Does attached patch also fix the problem? > > > > If yes, I think you could commit it. > > > > Please, don't. It breaks compilation if size_t is

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Enrico Forestieri: > > just don't even try it: my own brand new automated tests just started > > to fail because, with that template-ish thing, at the first attempt of > > typing a character in text-mode LyX was asserting :-). > > > > > > > > I'm using the

Re: trunk does no compile

Am 29.01.2011 um 19:12 schrieb Enrico Forestieri: > On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: > >> Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: >>> I can also share my template-based one, that avoids code replication and actually turns this burden over

Re: trunk does no compile

On Sat, Jan 29, 2011 at 08:06:37PM +0100, Stephan Witt wrote: > Am 29.01.2011 um 19:12 schrieb Enrico Forestieri: > > > On Sat, Jan 29, 2011 at 05:52:08PM +0100, Tommaso Cucinotta wrote: > > > >> Il 29/01/2011 17:13, Tommaso Cucinotta ha scritto: > >>> > I can also share my template-based

Re: trunk does no compile

On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote: > overload-2.diff: > > Compiles fine too. Thanks for testing. > Tommaso: > > Ok, apart from compiling, is it only me who's experience a crash when > > typing any character in text mode (seems it was not at all due to my > > template-based

Re: trunk does no compile

On 29 January 2011 16:49, Enrico Forestieri wrote: > On Sat, Jan 29, 2011 at 07:39:19PM +0100, Kornel wrote: > >> Tommaso: >> > Ok, apart from compiling, is it only me who's experience a crash when >> > typing any character in text mode (seems it was not at all due to my >> >

Re: trunk does no compile

Am Samstag, 29. Januar 2011 schrieb Guillaume Pothier: > >> I don't get it. You mean TeX-mode? Cannot see any crash here. > > > > Same here. > > I'm getting the crash when loading a file: Not here. "Insert->File->Plain Text..." is ok, and so is "...->Plain Text, Join Lines...". Kornel

Re: trunk does no compile

Il 29/01/2011 19:12, Enrico Forestieri ha scritto: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish thing, at the first attempt of typing a character in text-mode LyX was asserting :-). I'm using the Enrico's patch that works fine (at

Re: trunk does no compile

Il 30/01/2011 01:28, Tommaso Cucinotta ha scritto: If it is the same currently committed, then it is sufficient to: -) create a new file -) type any letter and kaboom! So, on my system, I need the patch below in order to be able to use LyX trunk again (r37368): Index: src/Paragraph.cpp

Re: trunk does no compile

On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote: > Il 29/01/2011 19:12, Enrico Forestieri ha scritto: > >>just don't even try it: my own brand new automated tests just started > >>to fail because, with that template-ish thing, at the first attempt of > >>typing a character in

Re: trunk does no compile

Am 30.01.2011 um 02:23 schrieb Enrico Forestieri: > On Sun, Jan 30, 2011 at 01:28:49AM +0100, Tommaso Cucinotta wrote: > >> Il 29/01/2011 19:12, Enrico Forestieri ha scritto: just don't even try it: my own brand new automated tests just started to fail because, with that template-ish

trunk does not compile

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:

Re: trunk does not compile

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])’

trunk does not compile

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:

Re: trunk does not compile

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])’

Trunk does not compile

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_ICONV=1

Trunk does not compile

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

Re: boost in trunk does not compile with gcc-4.4

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

Re: boost in trunk does not compile with gcc-4.4

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

Re: boost in trunk does not compile with gcc-4.4

Helge Hafting helge.haft...@hist.no 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

Re: boost in trunk does not compile with gcc-4.4

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

Re: boost in trunk does not compile with gcc-4.4

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

Re: boost in trunk does not compile with gcc-4.4

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

boost in trunk does not compile with gcc-4.4

[ 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

Re: boost in trunk does not compile with gcc-4.4

I reported this a while back, and the advice was to use external boost. rh

Re: boost in trunk does not compile with gcc-4.4

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.

Re: boost in trunk does not compile with gcc-4.4

Abdelrazak Younes you...@lyx.org 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

Re: boost in trunk does not compile with gcc-4.4

Original-Nachricht Datum: Thu, 09 Jul 2009 18:04:51 +0200 Von: Jean-Marc Lasgouttes lasgout...@lyx.org An: Abdelrazak Younes you...@lyx.org CC: rgheck rgh...@bobjweil.com, LyX Developers lyx-devel@lists.lyx.org Betreff: Re: boost in trunk does not compile with gcc-4.4

boost in trunk does not compile with gcc-4.4

[ 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 &&

Re: boost in trunk does not compile with gcc-4.4

I reported this a while back, and the advice was to use external boost. rh

Re: boost in trunk does not compile with gcc-4.4

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.

Re: boost in trunk does not compile with gcc-4.4

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?

Re: boost in trunk does not compile with gcc-4.4

Original-Nachricht > Datum: Thu, 09 Jul 2009 18:04:51 +0200 > Von: Jean-Marc Lasgouttes <lasgout...@lyx.org> > An: Abdelrazak Younes <you...@lyx.org> > CC: rgheck <rgh...@bobjweil.com>, LyX Developers <lyx-devel@lists.lyx.org> > Betre

Trunk does not compile

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

Re: Trunk does not compile

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

Re: Trunk does not compile

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

Trunk does not compile

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

Re: Trunk does not compile

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

Re: Trunk does not compile

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

Re: Trunk does not compile

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

Re: Trunk does not compile

Tommaso Cucinotta wrote: In order to compile, I need this, on my system make distclean should be sufficient. Jürgen

Re: Trunk does not compile

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

Re: Trunk does not compile

Tommaso Cucinotta wrote: > In order to compile, I need this, on my system make distclean should be sufficient. Jürgen

Trunk does not compile (client).

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,

Trunk does not compile (client).

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,

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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.

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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.

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Trunk does not compile.

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

Re: Trunk does not compile.

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:

Trunk does not compile: QDrag::exec is 4.3 only.

src/frontends/qt4/GuiWorkArea.cpp:1478: error: 'class QDrag' has no member named 'exec' Should we bump QT requirement to 4.3??? Bo

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Re: Trunk does not compile: QDrag::exec is 4.3 only.

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

Trunk does not compile.

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

Re: Trunk does not compile.

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:

  1   2   >