Re: LyX CVS compile error: insetlabel.C

On Tue, Feb 17, 2004 at 09:01:07AM +0100, Alfredo Braunstein wrote: > Angus Leeming wrote: > > > Why don't we (you) just remove this cruft from src/insets > > (insettheorem too). They no longer compile, they aren't ver y complex > > anyway and can always be retrieved from the Attic. > > There

LyX CVS compile error: insetlabel.C

Clean repository, Cygwin environment: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF .deps/insetlabel.Tpo -c

Re: LyX CVS compile error: insetlabel.C

Kayvan A. Sylvan wrote: Clean repository, Cygwin environment: Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you just remove them? -- Angus

Re: LyX CVS compile error: insetlabel.C

On Mon, Feb 16, 2004 at 07:31:05PM +, Angus Leeming wrote: Kayvan A. Sylvan wrote: Clean repository, Cygwin environment: Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you just remove them? That worked! After removing it, doing ./autogen.sh and compiling. Thanks,

Re: LyX CVS compile error: insetlabel.C

On Mon, Feb 16, 2004 at 12:56:41PM -0800, Kayvan A. Sylvan wrote: On Mon, Feb 16, 2004 at 07:31:05PM +, Angus Leeming wrote: Kayvan A. Sylvan wrote: Clean repository, Cygwin environment: Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you just remove them?

Re: LyX CVS compile error: insetlabel.C

On Monday 16 February 2004 9:24 pm, Kayvan A. Sylvan wrote: If these are not used, them how come they show up anyway? Because Lars was playing with them a year or so ago? [EMAIL PROTECTED] ~/src/lyx] cvs update -dP 21 | grep -v 'cvs server' U src/insets/insetlist.C U src/insets/insetlist.h

Re: LyX CVS compile error: insetlabel.C

Kayvan A. Sylvan wrote: Clean repository, Cygwin environment: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF .deps/insetlabel.Tpo

Re: LyX CVS compile error: insetlabel.C

Alfredo Braunstein wrote: There seems to be some kind of upper/lower case problem, src/insets/insetlabel.C should #include src/InsetList.h but it's wrongly including src/inset/insetlist.h in cwgwin. Why don't we (you) just remove this cruft from src/insets (insettheorem too). They no longer

Re: LyX CVS compile error: insetlabel.C

On Mon, Feb 16, 2004 at 10:45:11PM +, Angus Leeming wrote: Alfredo Braunstein wrote: There seems to be some kind of upper/lower case problem, src/insets/insetlabel.C should #include src/InsetList.h but it's wrongly including src/inset/insetlist.h in cwgwin. Why don't we (you) just

LyX CVS compile error: insetlabel.C

Clean repository, Cygwin environment: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF .deps/insetlabel.Tpo -c

Re: LyX CVS compile error: insetlabel.C

Kayvan A. Sylvan wrote: > Clean repository, Cygwin environment: Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you just remove them? -- Angus

Re: LyX CVS compile error: insetlabel.C

On Mon, Feb 16, 2004 at 07:31:05PM +, Angus Leeming wrote: > Kayvan A. Sylvan wrote: > > > Clean repository, Cygwin environment: > > Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you > just remove them? That worked! After removing it, doing ./autogen.sh and compiling.

Re: LyX CVS compile error: insetlabel.C

On Mon, Feb 16, 2004 at 12:56:41PM -0800, Kayvan A. Sylvan wrote: > On Mon, Feb 16, 2004 at 07:31:05PM +, Angus Leeming wrote: > > Kayvan A. Sylvan wrote: > > > > > Clean repository, Cygwin environment: > > > > Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you > > just

Re: LyX CVS compile error: insetlabel.C

On Monday 16 February 2004 9:24 pm, Kayvan A. Sylvan wrote: > If these are not used, them how come they show up anyway? Because Lars was playing with them a year or so ago? > [EMAIL PROTECTED] ~/src/lyx] cvs update -dP 2>&1 | grep -v 'cvs > server' U src/insets/insetlist.C > U

Re: LyX CVS compile error: insetlabel.C

Kayvan A. Sylvan wrote: > Clean repository, Cygwin environment: > > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src > -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include > -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF >

Re: LyX CVS compile error: insetlabel.C

Alfredo Braunstein wrote: > There seems to be some kind of upper/lower case problem, > src/insets/insetlabel.C should #include src/InsetList.h but it's > wrongly including src/inset/insetlist.h in cwgwin. Why don't we (you) just remove this cruft from src/insets (insettheorem too). They no

Re: LyX CVS compile error: insetlabel.C

On Mon, Feb 16, 2004 at 10:45:11PM +, Angus Leeming wrote: > Alfredo Braunstein wrote: > > There seems to be some kind of upper/lower case problem, > > src/insets/insetlabel.C should #include src/InsetList.h but it's > > wrongly including src/inset/insetlist.h in cwgwin. > > Why don't we

latest CVS: compile error

g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF .deps/insetlabel.Tpo -c ../../../lyx/src/insets/insetlabel.C In file included from

latest CVS: compile error

g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF .deps/insetlabel.Tpo -c ../../../lyx/src/insets/insetlabel.C In file included from

Re: Compile error

On Fri, Jan 30, 2004 at 01:54:37PM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | This intention of this 'nucleus/operator-' pair instead of the usual | 'nucleus/nucleus' pair was to be able to find the non-const accesses | with grep. [They are sort of 'unwanted'

Re: Compile error

On Fri, Jan 30, 2004 at 01:54:37PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | This intention of this 'nucleus/operator->' pair instead of the usual > | 'nucleus/nucleus' pair was to be able to find the non-const accesses > | with grep. [They are sort of

Re: Compile error

On Tue, Jan 27, 2004 at 10:09:12PM +0100, Georg Baum wrote: I get this error when compiling latest CVS with gcc 2.95 + stlport: g++ -DHAVE_CONFIG_H -I. -I../../src -I. -I../../boost -I/usr/include/stlport-I/usr/X11R6/include -DCXX_GLOBAL_CSTD -ftemplate-depth-30 -nostdinc++ -g -W

Re: Compile error

On Tue, Jan 27, 2004 at 09:58:19PM +, Angus Leeming wrote: Georg Baum wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) to if (t.operator-() != const_castInsetBase const *(anchor_[depth()].inset())) Is this

Re: Compile error

On Wed, Jan 28, 2004 at 12:10:48PM +0100, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Georg Baum wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) I wonder what has been smoked here to think this is a

Re: Compile error

On Wed, Jan 28, 2004 at 12:31:01PM +0100, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Angus Leeming [EMAIL PROTECTED] writes: | | Georg Baum wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset())

Re: Compile error

Andre Poenitz [EMAIL PROTECTED] writes: | This intention of this 'nucleus/operator-' pair instead of the usual | 'nucleus/nucleus' pair was to be able to find the non-const accesses | with grep. [They are sort of 'unwanted' in the light of potential | shared_ptr usage and each use should be

Re: Compile error

On Tue, Jan 27, 2004 at 10:09:12PM +0100, Georg Baum wrote: > I get this error when compiling latest CVS with gcc 2.95 + stlport: > > g++ -DHAVE_CONFIG_H -I. -I../../src -I. -I../../boost > -I/usr/include/stlport-I/usr/X11R6/include -DCXX_GLOBAL_CSTD > -ftemplate-depth-30 -nostdinc++ -g

Re: Compile error

On Tue, Jan 27, 2004 at 09:58:19PM +, Angus Leeming wrote: > Georg Baum wrote: > > It compiles if I change line 838 of src/Cursor.C from > > > > if (t.operator->() != anchor_[depth()].inset()) > > > > to > > > > if (t.operator->() != > > const_cast(anchor_[depth()].inset())) > > > > Is this

Re: Compile error

On Wed, Jan 28, 2004 at 12:10:48PM +0100, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Georg Baum wrote: > >> It compiles if I change line 838 of src/Cursor.C from > >> > >> if (t.operator->() != anchor_[depth()].inset()) > > I wonder what has been smoked here to

Re: Compile error

On Wed, Jan 28, 2004 at 12:31:01PM +0100, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > | Angus Leeming <[EMAIL PROTECTED]> writes: > > > | | Georg Baum wrote: > >>> It compiles if I change line 838 of src/Cursor.C from > >>> > >>> if (t.operator->() !=

Re: Compile error

Andre Poenitz <[EMAIL PROTECTED]> writes: | This intention of this 'nucleus/operator->' pair instead of the usual | 'nucleus/nucleus' pair was to be able to find the non-const accesses | with grep. [They are sort of 'unwanted' in the light of potential | shared_ptr usage and each use should be

Re: Compile error

Angus Leeming [EMAIL PROTECTED] writes: | Georg Baum wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) I wonder what has been smoked here to think this is a nice construct... -- Lgb

Re: Compile error

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Angus Leeming [EMAIL PROTECTED] writes: | | Georg Baum wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) | I wonder what has been smoked here to think this is a nice | construct...

Re: Compile error

Lars Gullik Bjønnes wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) | I wonder what has been smoked here to think this is a nice | construct... Agreed. What I'm confused about is why operator-() behaves differently. Can you shed

Re: Compile error

Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) | I wonder what has been smoked here to think this is a nice | construct... | Agreed. What I'm confused about is why

Re: Compile error

Lars Gullik Bjønnes wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) | I wonder what has been smoked here to think this is a nice | construct... | Agreed. What I'm confused about is why operator-() behaves | differently. Can you

Re: Compile error

Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) | I wonder what has been smoked here to think this is a nice | construct... | Agreed. What I'm confused about is why

Re: Compile error

Angus Leeming <[EMAIL PROTECTED]> writes: | Georg Baum wrote: >> It compiles if I change line 838 of src/Cursor.C from >> >> if (t.operator->() != anchor_[depth()].inset()) I wonder what has been smoked here to think this is a nice construct... -- Lgb

Re: Compile error

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Angus Leeming <[EMAIL PROTECTED]> writes: > | | Georg Baum wrote: >>> It compiles if I change line 838 of src/Cursor.C from >>> >>> if (t.operator->() != anchor_[depth()].inset()) > | I wonder what has been smoked here to think this is a nice |

Re: Compile error

Lars Gullik Bjønnes wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator->() != anchor_[depth()].inset()) >> > | I wonder what has been smoked here to think this is a nice > | construct... Agreed. What I'm confused about is why operator->() behaves differently.

Re: Compile error

Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > It compiles if I change line 838 of src/Cursor.C from > if (t.operator->() != anchor_[depth()].inset()) >>> >> | I wonder what has been smoked here to think this is a nice >> | construct... > | Agreed. What I'm

Re: Compile error

Lars Gullik Bjønnes wrote: >> It compiles if I change line 838 of src/Cursor.C from >> if (t.operator->() != anchor_[depth()].inset()) >>> | I wonder what has been smoked here to think this is a nice >>> | construct... >> > | Agreed. What I'm confused about is why operator->() behaves

Re: Compile error

Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >>> It compiles if I change line 838 of src/Cursor.C from >>> if (t.operator->() != anchor_[depth()].inset()) > | I wonder what has been smoked here to think this is a nice | construct... >>> >> | Agreed.

Compile error

I get this error when compiling latest CVS with gcc 2.95 + stlport: g++ -DHAVE_CONFIG_H -I. -I../../src -I. -I../../boost -I/usr/include/stlport-I/usr/X11R6/include -DCXX_GLOBAL_CSTD -ftemplate-depth-30 -nostdinc++ -g -W -Wall -c -o cursor.o `test -f '../../src/cursor.C' || echo

Re: Compile error

Georg Baum wrote: It compiles if I change line 838 of src/Cursor.C from if (t.operator-() != anchor_[depth()].inset()) to if (t.operator-() != const_castInsetBase const *(anchor_[depth()].inset())) Is this expected? Don't think so. The two functions in question are: MathInset

Compile error

I get this error when compiling latest CVS with gcc 2.95 + stlport: g++ -DHAVE_CONFIG_H -I. -I../../src -I. -I../../boost -I/usr/include/stlport-I/usr/X11R6/include -DCXX_GLOBAL_CSTD -ftemplate-depth-30 -nostdinc++ -g -W -Wall -c -o cursor.o `test -f '../../src/cursor.C' || echo

Re: Compile error

Georg Baum wrote: > It compiles if I change line 838 of src/Cursor.C from > > if (t.operator->() != anchor_[depth()].inset()) > > to > > if (t.operator->() != > const_cast(anchor_[depth()].inset())) > > Is this expected? Don't think so. The two functions in question are: MathInset

Re: lyx compile error

Kayvan A. Sylvan wrote: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT globbing.lo -MD -MP -MF .deps/globbing.Tpo -c

Re: lyx compile error

On Tue, Jan 06, 2004 at 09:31:41AM +, Angus Leeming wrote: Kayvan A. Sylvan wrote: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT

Re: lyx compile error

Kayvan A. Sylvan wrote: Hi Angus, Now I get: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT globbing.lo -MD -MP -MF .deps/globbing.Tpo -c

Re: lyx compile error

On Tue, Jan 06, 2004 at 05:30:48PM +, Angus Leeming wrote: Kayvan A. Sylvan wrote: Hi Angus, Now I get: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2

Re: lyx compile error

Kayvan A. Sylvan wrote: > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src > -I../../../lyx/src/support/../ -I../../../lyx/boost > -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W > -Wall -MT globbing.lo -MD -MP -MF .deps/globbing.Tpo -c >

Re: lyx compile error

On Tue, Jan 06, 2004 at 09:31:41AM +, Angus Leeming wrote: > Kayvan A. Sylvan wrote: > > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src > > -I../../../lyx/src/support/../ -I../../../lyx/boost > > -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W > > -Wall -MT

Re: lyx compile error

Kayvan A. Sylvan wrote: > Hi Angus, > > Now I get: > > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src > -I../../../lyx/src/support/../ -I../../../lyx/boost > -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W > -Wall -MT globbing.lo -MD -MP -MF .deps/globbing.Tpo

Re: lyx compile error

On Tue, Jan 06, 2004 at 05:30:48PM +, Angus Leeming wrote: > Kayvan A. Sylvan wrote: > > Hi Angus, > > > > Now I get: > > > > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src > > -I../../../lyx/src/support/../ -I../../../lyx/boost > > -I/u/ksylvan/include -I/usr/openwin/include

lyx compile error

Configuration Host type: sparc-sun-solaris2.8 Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (3.2.3) C++ Compiler

lyx compile error

Configuration Host type: sparc-sun-solaris2.8 Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (3.2.3) C++ Compiler

Compile error in cursor.C

I get this error: g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/X11R6/include -O -fno-exceptions -W -Wall -c -o cursor.o `test -f 'cursor.C' || echo './'`cursor.C cursor.C: In member function `DispatchResult Cursor::dispatch(const FuncRequest)': cursor.C:36: `update' undeclared (first

Re: Compile error in cursor.C

On Wed, Oct 29, 2003 at 01:49:51PM +0100, Lars Gullik Bjønnes wrote: I get this error: g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/X11R6/include -O -fno-exceptions -W -Wall -c -o cursor.o `test -f 'cursor.C' || echo './'`cursor.C cursor.C: In member function `DispatchResult

Re: Compile error in cursor.C

Andre Poenitz [EMAIL PROTECTED] writes: | Just removing that line should work. I currently can't reach aussie. I just commented it out. -- Lgb

Compile error in cursor.C

I get this error: g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/X11R6/include -O -fno-exceptions -W -Wall -c -o cursor.o `test -f 'cursor.C' || echo './'`cursor.C cursor.C: In member function `DispatchResult Cursor::dispatch(const FuncRequest&)': cursor.C:36: `update' undeclared (first

Re: Compile error in cursor.C

On Wed, Oct 29, 2003 at 01:49:51PM +0100, Lars Gullik Bjønnes wrote: > > I get this error: > > g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/usr/X11R6/include -O > -fno-exceptions -W -Wall -c -o cursor.o `test -f 'cursor.C' || echo './'`cursor.C > cursor.C: In member function `DispatchResult

Re: Compile error in cursor.C

Andre Poenitz <[EMAIL PROTECTED]> writes: | Just removing that line should work. I currently can't reach aussie. I just commented it out. -- Lgb

Latest CVS compile error

On Solaris: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT socktools.lo -MD -MP -MF .deps/socktools.Tpo -c ../../../lyx/src/support/socktools.C

Re: Latest CVS compile error

On Mon, 13 Oct 2003, Kayvan A. Sylvan wrote: On Solaris: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT socktools.lo -MD -MP -MF

Latest CVS compile error

On Solaris: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT socktools.lo -MD -MP -MF .deps/socktools.Tpo -c ../../../lyx/src/support/socktools.C

Re: Latest CVS compile error

On Mon, 13 Oct 2003, Kayvan A. Sylvan wrote: > On Solaris: > > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/support -I../../src > -I../../../lyx/src/support/../ -I../../../lyx/boost -I/u/ksylvan/include > -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT socktools.lo -MD -MP -MF >

Re: Latest CVS lyx compile error

On Mon, Sep 22, 2003 at 12:38:32AM +0200, Lars Gullik Bjønnes spake thusly: Angus Leeming [EMAIL PROTECTED] writes: | Kayvan A. Sylvan wrote: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include

Re: Latest CVS lyx compile error

Martin Vermeer [EMAIL PROTECTED] writes: | I couldn't care less. Talk to my compiler ;-) I think it is too old and grumpy. You should upgrade. -- Lgb

Re: Latest CVS lyx compile error

On Mon, Sep 22, 2003 at 08:58:54AM +0200, Lars Gullik Bjønnes spake thusly: Martin Vermeer [EMAIL PROTECTED] writes: | I couldn't care less. Talk to my compiler ;-) I think it is too old and grumpy. You should upgrade. -- Lgb Yeah yeah yeah. Carthago est delendam. Don't you

Re: Latest CVS lyx compile error

On Mon, Sep 22, 2003 at 08:58:54AM +0200, Lars Gullik Bjønnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: | I couldn't care less. Talk to my compiler ;-) I think it is too old and grumpy. You should upgrade. Btw when will Lgb 2.0 ship? The one we have now is certainly too old and

Re: Latest CVS lyx compile error

Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Sep 22, 2003 at 08:58:54AM +0200, Lars Gullik Bjønnes wrote: Martin Vermeer [EMAIL PROTECTED] writes: | I couldn't care less. Talk to my compiler ;-) I think it is too old and grumpy. You should upgrade. | Btw when will Lgb 2.0 ship? |

Re: Latest CVS lyx compile error

On Mon, Sep 22, 2003 at 12:38:32AM +0200, Lars Gullik Bjønnes spake thusly: > > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Kayvan A. Sylvan wrote: > > > >> g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src > >> -I../../../lyx/src/frontends/.. -I../../../lyx/boost

Re: Latest CVS lyx compile error

Martin Vermeer <[EMAIL PROTECTED]> writes: | I couldn't care less. Talk to my compiler ;-) I think it is too old and grumpy. You should upgrade. -- Lgb

Re: Latest CVS lyx compile error

On Mon, Sep 22, 2003 at 08:58:54AM +0200, Lars Gullik Bjønnes spake thusly: > > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > | I couldn't care less. Talk to my compiler ;-) > > I think it is too old and grumpy. You should upgrade. > > -- > Lgb Yeah yeah yeah. Carthago est

Re: Latest CVS lyx compile error

On Mon, Sep 22, 2003 at 08:58:54AM +0200, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > | I couldn't care less. Talk to my compiler ;-) > > I think it is too old and grumpy. You should upgrade. Btw when will Lgb 2.0 ship? The one we have now is certainly too

Re: Latest CVS lyx compile error

Andre Poenitz <[EMAIL PROTECTED]> writes: | On Mon, Sep 22, 2003 at 08:58:54AM +0200, Lars Gullik Bjønnes wrote: >> Martin Vermeer <[EMAIL PROTECTED]> writes: >> >> >> | I couldn't care less. Talk to my compiler ;-) >> >> I think it is too old and grumpy. You should upgrade. > | Btw when will

Latest CVS lyx compile error

g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT LyXView.lo -MD -MP -MF .deps/LyXView.Tpo -c ../../../lyx/src/frontends/LyXView.C

Re: Latest CVS lyx compile error

Kayvan A. Sylvan wrote: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT LyXView.lo -MD -MP -MF .deps/LyXView.Tpo -c

Re: Latest CVS lyx compile error

Angus Leeming [EMAIL PROTECTED] writes: | Kayvan A. Sylvan wrote: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT LyXView.lo -MD -MP -MF

Latest CVS lyx compile error

g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT LyXView.lo -MD -MP -MF .deps/LyXView.Tpo -c ../../../lyx/src/frontends/LyXView.C

Re: Latest CVS lyx compile error

Kayvan A. Sylvan wrote: > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src > -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include > -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT LyXView.lo -MD > -MP -MF .deps/LyXView.Tpo -c

Re: Latest CVS lyx compile error

Angus Leeming <[EMAIL PROTECTED]> writes: | Kayvan A. Sylvan wrote: > >> g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/frontends -I../../src >> -I../../../lyx/src/frontends/.. -I../../../lyx/boost -I/u/ksylvan/include >> -I/usr/openwin/include -O2 -fno-exceptions -W -Wall -MT LyXView.lo -MD >> -MP

Compile error (LOCALEDIR)

make distclean ; ./autogen.sh etc. messages.C: In function `const std::string unnamed::getLocaleDir()': messages.C:30: error: `LOCALEDIR' undeclared (first use this function) messages.C:30: error: (Each undeclared identifier is reported only once for each function it appears in.) Regards,

Compile error (LOCALEDIR)

make distclean ; ./autogen.sh etc. messages.C: In function `const std::string& ::getLocaleDir()': messages.C:30: error: `LOCALEDIR' undeclared (first use this function) messages.C:30: error: (Each undeclared identifier is reported only once for each function it appears in.) Regards, Juergen.

text2lyx compile error with gcc 3.4 cvs

/usr/local/gcc-cvs/bin/g++ -g -O -fno-exceptions -W -Wall -o tex2lyx texparser.o tex2lyx.o preamble.o math.o table.o text.o tex2lyx.o: In function `std::__simple_allocstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::__default_alloc_template(bool)1, (int)0

text2lyx compile error with gcc 3.4 cvs

/usr/local/gcc-cvs/bin/g++ -g -O -fno-exceptions -W -Wall -o tex2lyx texparser.o tex2lyx.o preamble.o math.o table.o text.o tex2lyx.o: In function `std::__simple_alloc, std::__default_alloc_template<(bool)1, (int)0>

Re: Compile error (CutAndPaste)

Kayvan A. Sylvan [EMAIL PROTECTED] writes: I don't know what the (ugly) workaround will be, perhaps use iterator instead of const_iterator, perhaps remove some const. Those of you seeing the error much figure it out, the code as-is is perfectly valid. -- Lgb

Re: Compile error (CutAndPaste)

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars I don't know what the (ugly) workaround will be, perhaps use | Lars iterator instead of const_iterator, perhaps remove some const. | | Here is one. I filed to see why this work

Re: Compile error (CutAndPaste)

"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: I don't know what the (ugly) workaround will be, perhaps use iterator instead of const_iterator, perhaps remove some const. Those of you seeing the error much figure it out, the code as-is is perfectly valid. -- Lgb

Re: Compile error (CutAndPaste)

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> I don't know what the (ugly) workaround will be, perhaps use | Lars> iterator instead of const_iterator, perhaps remove some const. | | Here is one. I filed to see why

Re: CVS compile error

Kayvan A. Sylvan wrote: gcc -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src -I../../../src/frontends -I../../../src/frontends/controllers -I../../../boost -I/u/ksylvan/include -isystem /usr/openwin/include -g -O2 -c freebrowser.c -Wp,-MD,.deps/freebrowser.TPlo

Re: CVS compile error

Kayvan A. Sylvan wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images > -I../../../src -I../../../src/frontends > -I../../../src/frontends/controllers -I../../../boost -I/u/ksylvan/include > -isystem /usr/openwin/include -g -O2 -c freebrowser.c > -Wp,-MD,.deps/freebrowser.TPlo

CVS compile error

gcc -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src -I../../../src/frontends -I../../../src/frontends/controllers -I../../../boost -I/u/ksylvan/include -isystem /usr/openwin/include -g -O2 -c freebrowser.c -Wp,-MD,.deps/freebrowser.TPlo freebrowser.c: In function

CVS compile error

gcc -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src -I../../../src/frontends -I../../../src/frontends/controllers -I../../../boost -I/u/ksylvan/include -isystem /usr/openwin/include -g -O2 -c freebrowser.c -Wp,-MD,.deps/freebrowser.TPlo freebrowser.c: In function

lyx-1.4.0cvs compile error (text.C)

gcc-2.95.3 on SunOS-2.5.1: make[3]: Entering directory `/remote/simian1/ksylvan/lyx/src' source='text.C' object='text.o' libtool=no \ depfile='.deps/text.Po' tmpdepfile='.deps/text.TPo' \ depmode=gcc /bin/ksh ../config/depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I. -I../boost -I/u/ksylvan/include

Re: lyx-1.4.0cvs compile error (text.C)

Kayvan A. Sylvan [EMAIL PROTECTED] writes: | gcc-2.95.3 on SunOS-2.5.1: | | text.C:911: prototype for `int LyXText::fill(Row , int)' does not match any in class `LyXText' | lyxtext.h:606: candidate is: int LyXText::fill(Row , int) const Try out the ninth and I'll help you. -- Lgb

Re: lyx-1.4.0cvs compile error (text.C)

Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | gcc-2.95.3 on SunOS-2.5.1: | | text.C:911: prototype for `int LyXText::fill(Row , int)' does not match | any in class `LyXText' lyxtext.h:606: candidate is: int | LyXText::fill(Row , int) const Try out the ninth

Re: lyx-1.4.0cvs compile error (text.C)

Alfredo Braunstein [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | | Kayvan A. Sylvan [EMAIL PROTECTED] writes: | | | gcc-2.95.3 on SunOS-2.5.1: | | | | text.C:911: prototype for `int LyXText::fill(Row , int)' does not match | | any in class `LyXText' lyxtext.h:606: candidate

Re: lyx-1.4.0cvs compile error (text.C)

On Mon, Mar 31, 2003 at 10:55:31PM +0200, Alfredo Braunstein wrote: Lars Gullik Bjønnes wrote: Kayvan A. Sylvan [EMAIL PROTECTED] writes: | gcc-2.95.3 on SunOS-2.5.1: | | text.C:911: prototype for `int LyXText::fill(Row , int)' does not match | any in class `LyXText'

<    1   2   3   4   5   6   7   8   9   10   >