Re: Compilation Failure in Master

On Fri, May 16, 2025 at 04:54:25PM +0200, Kornel Benko wrote: > Am Fri, 16 May 2025 16:20:04 +0200 > schrieb Scott Kostyshak : > > > On Fri, May 16, 2025 at 03:47:24PM +0200, Jean-Marc Lasgouttes wrote: > > > Le 16/05/2025 à 15:40, Scott Kostyshak a écrit : > > > > From what I understand, this

Re: Compilation Failure in Master

Am Fri, 16 May 2025 16:20:04 +0200 schrieb Scott Kostyshak : > On Fri, May 16, 2025 at 03:47:24PM +0200, Jean-Marc Lasgouttes wrote: > > Le 16/05/2025 à 15:40, Scott Kostyshak a écrit : > > > From what I understand, this would set BOOST, Z, DTL, HUNSPELL, and > > > ICONV to default to ON? > > >

Re: Compilation Failure in Master

Le 16/05/2025 à 16:31, Kornel Benko a écrit : External libs: Yes, it was anyway the default for prerelease|release build-types. While debugging the default was OFF for development|gprof build-types. Now the default would be always ON except for Windows. This was also done with autoconf when gcc

Re: Compilation Failure in Master

Am Fri, 16 May 2025 15:47:24 +0200 schrieb Jean-Marc Lasgouttes : > Le 16/05/2025 à 15:40, Scott Kostyshak a écrit : > > From what I understand, this would set BOOST, Z, DTL, HUNSPELL, and > > ICONV to default to ON? External libs: Yes, it was anyway the default for prerelease|release build-type

Re: Compilation Failure in Master

On Fri, May 16, 2025 at 03:47:24PM +0200, Jean-Marc Lasgouttes wrote: > Le 16/05/2025 à 15:40, Scott Kostyshak a écrit : > > From what I understand, this would set BOOST, Z, DTL, HUNSPELL, and > > ICONV to default to ON? > > > > I don't have any personal preference since it's easy for me to chang

Re: Compilation Failure in Master

Le 16/05/2025 à 15:40, Scott Kostyshak a écrit : From what I understand, this would set BOOST, Z, DTL, HUNSPELL, and ICONV to default to ON? I don't have any personal preference since it's easy for me to change my build script accordingly, but I don't know if JMarc's original argument of being

Re: Compilation Failure in Master

On Fri, May 16, 2025 at 02:50:43PM +0200, Kornel Benko wrote: > Am Fri, 16 May 2025 14:08:02 +0200 > schrieb Scott Kostyshak : > > > > Could you set LYX_EXTERNAL_ICONV to on by default, except for windows? > > > This > > > is a standard part of Unix. > > > > Kornel, any thoughts on this? > >

Re: Compilation Failure in Master

Am Fri, 16 May 2025 14:08:02 +0200 schrieb Scott Kostyshak : > > Could you set LYX_EXTERNAL_ICONV to on by default, except for windows? This > > is a standard part of Unix. > > Kornel, any thoughts on this? No problem. Maybe something like the attached. > Scott Kornel diff --git a/CM

Re: Compilation Failure in Master

On Fri, May 16, 2025 at 12:02:41PM +0200, Jean-Marc Lasgouttes wrote: > Le 16/05/2025 à 10:13, Kornel Benko a écrit : > > Am Thu, 15 May 2025 17:50:26 +0200 > > schrieb Scott Kostyshak : > > > > > Do you mean CMake should turn set LYX_EXTERNAL_ICONV passed on the > > > version of the compiler? > >

Re: Compilation Failure in Master

Le 16/05/2025 à 10:13, Kornel Benko a écrit : Am Thu, 15 May 2025 17:50:26 +0200 schrieb Scott Kostyshak : Do you mean CMake should turn set LYX_EXTERNAL_ICONV passed on the version of the compiler? I still don't know why it succeeds for me (with the default of LYX_EXTERNAL_ICONV=OFF) and not

Re: Compilation Failure in Master

On Fri, May 16, 2025 at 10:13:22AM +0200, Kornel Benko wrote: > Am Thu, 15 May 2025 17:50:26 +0200 > schrieb Scott Kostyshak : > > > Do you mean CMake should turn set LYX_EXTERNAL_ICONV passed on the > > version of the compiler? > > > > I still don't know why it succeeds for me (with the default

Re: Compilation Failure in Master

Am Thu, 15 May 2025 17:50:26 +0200 schrieb Scott Kostyshak : > Do you mean CMake should turn set LYX_EXTERNAL_ICONV passed on the > version of the compiler? > > I still don't know why it succeeds for me (with the default of > LYX_EXTERNAL_ICONV=OFF) and not for Riki. Could be different compiler >

Re: Compilation Failure in Master

On Thu, May 15, 2025 at 04:48:55PM +0200, Jean-Marc Lasgouttes wrote: > At this time, upgrading libiconv seems a lot of work for a dubious return. I agree, the right fix seems to be changing cmake defaults and mess with libiconv only if mingw folks deem it necessary. Pavel -- lyx-devel mailing l

Re: Compilation Failure in Master

On Thu, May 15, 2025 at 05:59:45PM +0200, Jean-Marc Lasgouttes wrote: > Le 15/05/2025 à 17:50, Scott Kostyshak a écrit : > > I still don't know why it succeeds for me (with the default of > > LYX_EXTERNAL_ICONV=OFF) and not for Riki. Could be different compiler > > versions or could be different ot

Re: Compilation Failure in Master

On 5/15/25 10:48 AM, Jean-Marc Lasgouttes wrote: My question is thus: Riki, do you _need_ this to work, or is it just that cmake is proposing the wrong defaults? I was just using the defaults. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org https://lists.lyx.org/mailman/listinfo/lyx-d

Re: Compilation Failure in Master

Le 15/05/2025 à 17:50, Scott Kostyshak a écrit : I still don't know why it succeeds for me (with the default of LYX_EXTERNAL_ICONV=OFF) and not for Riki. Could be different compiler versions or could be different othe CMake flags. Kornel does it compile successfully (although with warnings) for y

Re: Compilation Failure in Master

On Thu, May 15, 2025 at 04:48:55PM +0200, Jean-Marc Lasgouttes wrote: > Le 15/05/2025 à 12:31, Scott Kostyshak a écrit : > > On Thu, May 15, 2025 at 08:49:32AM +0200, Jean-Marc Lasgouttes wrote: > > > Le 15 mai 2025 01:46:37 GMT+02:00, Richard Kimberly Heck > > > a écrit : > > > > > > > > I was

Re: Compilation Failure in Master

Le 15/05/2025 à 12:31, Scott Kostyshak a écrit : On Thu, May 15, 2025 at 08:49:32AM +0200, Jean-Marc Lasgouttes wrote: Le 15 mai 2025 01:46:37 GMT+02:00, Richard Kimberly Heck a écrit : I was just using defaults: mkdir build cd buildcmake ..; and that's it. If I set LYX_EXTERNAL_ICONV to ON

Re: Compilation Failure in Master

On Thu, May 15, 2025 at 08:49:32AM +0200, Jean-Marc Lasgouttes wrote: > Le 15 mai 2025 01:46:37 GMT+02:00, Richard Kimberly Heck > a écrit : > > > >I was just using defaults: > > > >mkdir build > >cd buildcmake ..; and that's it. If I set LYX_EXTERNAL_ICONV to ON, then it > >builds. The error se

Re: Compilation Failure in Master

Le 15 mai 2025 01:46:37 GMT+02:00, Richard Kimberly Heck a écrit : > >I was just using defaults: > >mkdir build >cd buildcmake ..; and that's it. If I set LYX_EXTERNAL_ICONV to ON, then it >builds. The error seems to be in building iconv itself. > We ship libinconv 1.15. It might be that the la

Re: Compilation Failure in Master

On 5/14/25 4:41 PM, Scott Kostyshak wrote: On Wed, May 14, 2025 at 12:00:20PM -0400, Richard Kimberly Heck wrote: In file included from /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/loops.h:23, from /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/iconv.c:136: /cvs/lyx/lyx-devel/3r

Re: Compilation Failure in Master

On 5/14/25 4:41 PM, Scott Kostyshak wrote: On Wed, May 14, 2025 at 12:00:20PM -0400, Richard Kimberly Heck wrote: In file included from /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/loops.h:23, from /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/iconv.c:136: /cvs/lyx/lyx-devel/3r

Re: Compilation Failure in Master

On Wed, May 14, 2025 at 12:00:20PM -0400, Richard Kimberly Heck wrote: > > In file included from > /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/loops.h:23, > from > /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/iconv.c:136: > /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/loop_wcha

Compilation Failure in Master

In file included from /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/loops.h:23, from /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/iconv.c:136: /cvs/lyx/lyx-devel/3rdparty/libiconv/1.15/lib/loop_wchar.h:39:17:error: conflicting types fo r ‘mbrtowc’; have ‘size_t(void)’ {aka ‘l

Re: Compilation failure with c++11 (string_view)

On 1/4/23 21:39, Scott Kostyshak wrote: On Tue, Jan 03, 2023 at 10:30:27AM +0100, Jean-Marc Lasgouttes wrote: With master, I cannot compile in c++11 mode: ../../master/src/mathed/InsetMathDecoration.cpp:191:22: error: ‘string_view’ has not been declared 191 | Attributes(bool o, string_view

Re: Compilation failure with c++11 (string_view)

On Tue, Jan 03, 2023 at 10:30:27AM +0100, Jean-Marc Lasgouttes wrote: > With master, I cannot compile in c++11 mode: > > ../../master/src/mathed/InsetMathDecoration.cpp:191:22: error: ‘string_view’ > has not been declared > 191 | Attributes(bool o, string_view entity) > |

Compilation failure with c++11 (string_view)

With master, I cannot compile in c++11 mode: ../../master/src/mathed/InsetMathDecoration.cpp:191:22: error: ‘string_view’ has not been declared 191 | Attributes(bool o, string_view entity) | ^~~ Indeed, std::string_view is a c++17 thing. JMarc -- lyx-dev

Re: [LyX/master] Fix compilation failure

Le 15/05/2017 à 10:31, Jean-Marc Lasgouttes a écrit : commit 676ce147da9f5873b4177a0cc3dd706005dd0690 Author: Jean-Marc Lasgouttes Date: Mon May 15 10:29:09 2017 +0200 Fix compilation failure --- src/frontends/qt4/qt_helpers.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions

Re: Compilation failure un c++11 mode with gcc 4.6

Am Freitag, 29. Mai 2015 um 21:59:16, schrieb pdv > On 29/05/15 20:10, Kornel Benko wrote: > > Am Freitag, 29. Mai 2015 um 19:52:03, schrieb Jean-Marc Lasgouttes > > > >> Le 28/05/2015 23:23, pdv a écrit : > >>> Starting with commit b596330 lyx fails to compile with cmake/xcode. > >>> This seems

Re: Compilation failure un c++11 mode with gcc 4.6

Am Freitag, 29. Mai 2015 um 19:52:03, schrieb Jean-Marc Lasgouttes > Le 28/05/2015 23:23, pdv a écrit : > > Starting with commit b596330 lyx fails to compile with cmake/xcode. > > This seems to be due to "boost::next" having been replaced by "next" and > > this generates "ambiguous call to 'next'

Re: Compilation failure un c++11 mode with gcc 4.6

Le 28/05/2015 23:23, pdv a écrit : Starting with commit b596330 lyx fails to compile with cmake/xcode. This seems to be due to "boost::next" having been replaced by "next" and this generates "ambiguous call to 'next'" semantic issues, one of the 2 possibilities being the "next" in lyxalgo.h menti

Re: Compilation failure un c++11 mode with gcc 4.6

Am Donnerstag, 28. Mai 2015 um 23:23:07, schrieb pdv > On 19/05/15 11:25, Jean-Marc Lasgouttes wrote: > > Hi Georg, > > > > It is not possible currently to compile with gcc 4.6 in C++11 mode > > because lyxalgo.h declares its own next() method. This is because the > > code depends on __cplusplus >

Re: Compilation failure un c++11 mode with gcc 4.6

On 19/05/15 11:25, Jean-Marc Lasgouttes wrote: Hi Georg, It is not possible currently to compile with gcc 4.6 in C++11 mode because lyxalgo.h declares its own next() method. This is because the code depends on __cplusplus >= 201103L, which is not true for this version of the compiler. I would p

Re: Compilation failure un c++11 mode with gcc 4.6

Le 22/05/2015 08:58, Georg Baum a écrit : This is a misunderstanding: 199711L is the value for C++98 and C++03, therefore __cplusplus > 199711L tests for the a standard later than C++03, and the next one happens to be C++11. Therefore, this test is in practice the same test as the ones you hand

Re: Compilation failure un c++11 mode with gcc 4.6

Jean-Marc Lasgouttes wrote: > Le 19/05/2015 20:34, Georg Baum a écrit : >> >> Maybe some of them, but at least the one in tex2lyx should be converted >> to LYX_USE_CXX11. > > For me it tests against C++98, and I think this is a given these days. > But since I do not understand the subtleties of s

Re: Compilation failure un c++11 mode with gcc 4.6

Le 19/05/2015 20:34, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: Georg, would the following commit suit you? With it, I am able to compile with gcc 4.6 in C++11 mode. I would prefer testing for __cplusplus, since it is defined by the C++ standard. However, since this does not work I do n

Re: Compilation failure un c++11 mode with gcc 4.6

Jean-Marc Lasgouttes wrote: > Georg, would the following commit suit you? With it, I am able to > compile with gcc 4.6 in C++11 mode. I would prefer testing for __cplusplus, since it is defined by the C++ standard. However, since this does not work I do not know of a better way than you propose

Re: Compilation Failure

On 05/18/2015 05:13 AM, Jürgen Spitzmüller wrote: 2015-05-17 21:54 GMT+02:00 Richard Heck >: Commit is causing compilation to fail here: I have reverted the refactoring. Does it compile now? Yes, it's fine now. rh

Re: Compilation failure un c++11 mode with gcc 4.6

Le 19/05/2015 11:45, Jean-Marc Lasgouttes a écrit : Le 19/05/2015 11:25, Jean-Marc Lasgouttes a écrit : Hi Georg, It is not possible currently to compile with gcc 4.6 in C++11 mode because lyxalgo.h declares its own next() method. This is because the code depends on __cplusplus >= 201103L, whic

Re: Compilation failure un c++11 mode with gcc 4.6

Le 19/05/2015 11:25, Jean-Marc Lasgouttes a écrit : Hi Georg, It is not possible currently to compile with gcc 4.6 in C++11 mode because lyxalgo.h declares its own next() method. This is because the code depends on __cplusplus >= 201103L, which is not true for this version of the compiler. Mor

Compilation failure un c++11 mode with gcc 4.6

Hi Georg, It is not possible currently to compile with gcc 4.6 in C++11 mode because lyxalgo.h declares its own next() method. This is because the code depends on __cplusplus >= 201103L, which is not true for this version of the compiler. I would propose to replace this test with a test on w

Re: Compilation Failure

2015-05-17 21:54 GMT+02:00 Richard Heck : > > Commit is causing compilation to fail here: > I have reverted the refactoring. Does it compile now? Jürgen

Re: Compilation Failure

On 05/17/2015 04:25 PM, Jürgen Spitzmüller wrote: 2015-05-17 21:56 GMT+02:00 Richard Heck: Commit b7c53b6017a is causing compilation to fail here. This is Fedora 21, gcc 4.9.2. I think what it wants is the ability to add an int to an iterator? Does it help if you add #include "

Re: Compilation Failure

2015-05-17 21:56 GMT+02:00 Richard Heck: > > Commit b7c53b6017a is causing compilation to fail here. This is Fedora 21, > gcc 4.9.2. > > I think what it wants is the ability to add an int to an iterator? > Does it help if you add #include "Color.h" in qt_helpers.h? (I am a bit lost since it

Compilation Failure

Commit b7c53b6017a is causing compilation to fail here. This is Fedora 21, gcc 4.9.2. I think what it wants is the ability to add an int to an iterator? Richard In file included from /usr/include/c++/4.9.2/bits/concept_check.h:55:0, from /usr/include/c++/4.9.2/bits/move.h:

Compilation Failure

Commit is causing compilation to fail here:

Re: Compilation failure after r33370

On 02/09/2010 01:28 AM, Uwe Stöhr wrote: Since r33370 I get this compilation error: Creating library release\lyx.lib and object release\lyx.exp InsetFloat.obj : error LNK2019: unresolved external symbol "public: virtual __th iscall lyx::InsetFloat::~InsetFloat(void)" (??1insetfl...@lyx@@u...

Compilation failure after r33370

Since r33370 I get this compilation error: Creating library release\lyx.lib and object release\lyx.exp InsetFloat.obj : error LNK2019: unresolved external symbol "public: virtual __th iscall lyx::InsetFloat::~InsetFloat(void)" (??1insetfl...@lyx@@u...@xz) reference d in function "public: virt

Re: Compilation failure with qt 4.2

On Fri, Sep 25, 2009 at 12:13:06PM +0200, Jean-Marc Lasgouttes wrote: > Enrico Forestieri writes: > > I am going to commit a patch. > > It is perfect now. Thanks, Enrico! Curiously enough, with Qt 4.2 it now works even better than with Qt 4.5, as the dialog is able to shrink more before it start

Re: Compilation failure with qt 4.2

Enrico Forestieri writes: > I am going to commit a patch. It is perfect now. Thanks, Enrico! JMarc

Re: Compilation failure with qt 4.2

On Thu, Sep 24, 2009 at 02:37:03PM +0200, Enrico Forestieri wrote: > On Wed, Sep 23, 2009 at 11:52:12AM +0200, Enrico Forestieri wrote: > > On Wed, Sep 23, 2009 at 10:06:40AM +0200, Jean-Marc Lasgouttes wrote: > > > Enrico Forestieri writes: > > > > You're impossible to please, apparently :) but i

Re: Compilation failure with qt 4.2

On Wed, Sep 23, 2009 at 11:52:12AM +0200, Enrico Forestieri wrote: > On Wed, Sep 23, 2009 at 10:06:40AM +0200, Jean-Marc Lasgouttes wrote: > > Enrico Forestieri writes: > > > You're impossible to please, apparently :) but it has to suffice, as we > > > only support Qt >= 4.4, it seems: http://www.

Re: Compilation failure with qt 4.2

On Wed, Sep 23, 2009 at 10:06:40AM +0200, Jean-Marc Lasgouttes wrote: > Enrico Forestieri writes: > > You're impossible to please, apparently :) but it has to suffice, as we > > only support Qt >= 4.4, it seems: http://www.lyx.org/trac/changeset/30406 > > http://www.lyx.org/trac/changeset/30440

Re: Compilation failure with qt 4.2

Enrico Forestieri writes: > You're impossible to please, apparently :) but it has to suffice, as we > only support Qt >= 4.4, it seems: http://www.lyx.org/trac/changeset/30406 http://www.lyx.org/trac/changeset/30440 JMarc

Re: Compilation failure with qt 4.2

Enrico Forestieri schreef: On Tue, Sep 22, 2009 at 05:22:07PM +0200, Jean-Marc Lasgouttes wrote: Le 22/09/2009 16:41, Enrico Forestieri a �crit : This looks a bit like what I had after my "fix" :) Well, then you did a bit more than loading and saving the .ui file with an old

Re: Compilation failure with qt 4.2

On Tue, Sep 22, 2009 at 05:22:07PM +0200, Jean-Marc Lasgouttes wrote: > Le 22/09/2009 16:41, Enrico Forestieri a �crit : > >> This looks a bit like what I had after my "fix" :) > > > > Well, then you did a bit more than loading and saving the .ui file > > with an old designer :) After doing that,

Re: Compilation failure with qt 4.2

Le 22/09/2009 16:41, Enrico Forestieri a écrit : This looks a bit like what I had after my "fix" :) Well, then you did a bit more than loading and saving the .ui file with an old designer :) After doing that, I simply got a real mess, so I peformed some manual tweaks directly on the original...

Re: Compilation failure with qt 4.2

On Tue, Sep 22, 2009 at 03:40:15PM +0200, Jean-Marc Lasgouttes wrote: > Enrico Forestieri writes: > >> I tried to do that with 4.2, and it produced a dialog with a stupid UI. > >> Could somebody who knows about designer have a look at it? > > > > Note that with Qt 4.2 you have to manually resize

Re: Compilation failure with qt 4.2

Enrico Forestieri writes: >> I tried to do that with 4.2, and it produced a dialog with a stupid UI. >> Could somebody who knows about designer have a look at it? > > Note that with Qt 4.2 you have to manually resize the widget to see it > completely, most probably. Morever, it doesn't stretch whe

Re: Compilation failure with qt 4.2

On Mon, Sep 21, 2009 at 12:28:40PM +0200, Jean-Marc Lasgouttes wrote: > Pavel Sanda writes: > > > Richard Heck wrote: > >> Hmm. Compiling under Qt 4.5, I do not see that there at all. Is there some > >> kind of conflict involving the moc version? I also note, by the way, that > >> the ui file

Re: Compilation failure with qt 4.2

Pavel Sanda writes: > Richard Heck wrote: >> Hmm. Compiling under Qt 4.5, I do not see that there at all. Is there some >> kind of conflict involving the moc version? I also note, by the way, that >> the ui file in question has the xml line at the beginning, which might > > xml line in the beg

Re: Compilation failure with qt 4.2

Andre Poenitz wrote: > On Tue, Sep 15, 2009 at 01:47:21PM +0200, Pavel Sanda wrote: > > [...] > > greets from sicily! :) > > Did you jump on the wrong train again? they have really mess in Tegel; you never know where you'll be landed when trying to escape from Berlin :) pavel

Re: Compilation failure with qt 4.2

On Tue, Sep 15, 2009 at 01:47:21PM +0200, Pavel Sanda wrote: > [...] > greets from sicily! :) Did you jump on the wrong train again? Andre'

Re: Compilation failure with qt 4.2

Richard Heck wrote: > Hmm. Compiling under Qt 4.5, I do not see that there at all. Is there some > kind of conflict involving the moc version? I also note, by the way, that > the ui file in question has the xml line at the beginning, which might xml line in the beginning means using designer 4.

RE: Compilation failure with qt 4.2

>> ./ui_FindAndReplaceUi.h:129: error: 'class QGridLayout' >>has no member named >'setLeftMargin' >> ./ui_FindAndReplaceUi.h:130: error: 'class QGridLayout' >>has no member named 'setTopMargin' >> >> >Hmm. Compiling under Qt 4.5, I do not see that there at all. > void QLayout::setContentsMar

Re: Compilation failure with qt 4.2

On 09/14/2009 05:13 AM, Jean-Marc Lasgouttes wrote: Hello, I am back to regular schedule, and find that FindAdReplace dialog in trunk does not compile with Qt 4.2 anymore. Could somebody have a look at it? JMarc if g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 -I../../..

Compilation failure with qt 4.2

Hello, I am back to regular schedule, and find that FindAdReplace dialog in trunk does not compile with Qt 4.2 anymore. Could somebody have a look at it? JMarc if g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 -I../../.. -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_NO_CAST_TO_ASCII -D

Re: Compilation failure

On 22/11/2008 17:21, Jean-Marc Lasgouttes wrote: Trunk does not compile right now. Abdel, this is with qt 4.3.0. Sorry, I forgot to commit the ui file. Fixed now. Abdel.

Re: Compilation failure

Le 22 nov. 08 à 18:01, Abdelrazak Younes a écrit : On 22/11/2008 17:21, Jean-Marc Lasgouttes wrote: Trunk does not compile right now. Abdel, this is with qt 4.3.0. That's weird, FindAndReplaceUi should use EmbeddedWorkArea now, are you sure that it was uic'd? In the ui file I see:

Re: Compilation failure

On 22/11/2008 17:21, Jean-Marc Lasgouttes wrote: Trunk does not compile right now. Abdel, this is with qt 4.3.0. That's weird, FindAndReplaceUi should use EmbeddedWorkArea now, are you sure that it was uic'd? JMarc g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 -I../..

Compilation failure

Trunk does not compile right now. Abdel, this is with qt 4.3.0. JMarc g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 - I../../.. -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_NO_CAST_TO_ASCII - DQT_NO_STL -I../../../../lyx-devel/src -I../../../../lyx-devel/src/ frontends -I../../../..

Re: FW: lyx 1.6.0 compilation failure, error: forward declaration

On Wed, Nov 12, 2008 at 08:40:51PM +0100, Vincent van Ravesteijn - TNW wrote: > >>> C++ Compiler: g++ (3.3.4) > > > > >Thanks, I installed gcc-4.3.2 locally and ... LyX compiled > >successfully (even without re-compiling Qt beforehand). > > > >If the error was due to the old comp

FW: lyx 1.6.0 compilation failure, error: forward declaration

>>> C++ Compiler: g++ (3.3.4) > >Thanks, I installed gcc-4.3.2 locally and ... LyX compiled successfully >(even without re-compiling Qt beforehand). > >If the error was due to the old compiler, I suggest modifying the LyX >.INSTALL file where it says: > >"First of all, you will a

Re: convert.cpp compilation failure.

> mac Intel > OSX 10.5.2 > > make 1.6svn at revision 23963: > > convert.cpp: In function 'Target lyx::convert(Source) [with Target = int, > Source = std::string]': > convert.cpp:121: error: 'strtol' was not declared in this scope does this patch help? pavel diff --git a/src/support/convert.cpp b/

convert.cpp compilation failure.

mac Intel OSX 10.5.2 make 1.6svn at revision 23963: convert.cpp: In function 'Target lyx::convert(Source) [with Target = int, Source = std::string]': convert.cpp:121: error: 'strtol' was not declared in this scope convert.cpp: In function 'Target lyx::convert(Source) [with Target = int, Sou

Compilation failure

Hello, I cannot compile the latest lyx 1.4 source. My configuration flags are ./configure \ --with-frontend=qt \ --with-qt-includes=/usr/include/qt3/ \ --with-qt-libraries=/usr/lib/qt3/ \ --with-qt-dir=/usr/share/qt3/ \ --with-version-suffix=-1.4cvs \

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> My mental picture of the way forward is to disable the choice Angus> of template until the user attempts to select a file (either Angus> types it in or uses "Browse..."). Yes. Angus> Thereafter, we'd activate the chooser but use

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Adding ... Angus> Fixes things for me. I guess that all the 'insets-with-dialogs' Angus> need to be added to this block. Seems reasonable. >> I guess it should default to the first one, or something. Angus> See my ques

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Jean-Marc Lasgouttes wrote: >>> It cures the crash, but there is still a problem: template popup >>> shows an empty entry, but the help text is the chess one. >>> >>> We have to find out why the po

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Jean-Marc Lasgouttes wrote: >>> It cures the crash, but there is still a problem: template popup >>> shows an empty entry, but the help text is the chess one. >>> >>> We have to find out why the po

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: >> It cures the crash, but there is still a problem: template popup >> shows an empty entry, but the help text is the chess one. >> >> We have to find out why the popup is not initialized correctly, >> i

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

Jean-Marc Lasgouttes wrote: > It cures the crash, but there is still a problem: template popup > shows an empty entry, but the help text is the chess one. > > We have to find out why the popup is not initialized correctly, > instead of trying to workaround bad values. Sure. I thought you wanted t

Re: Compilation failure in checkedwidgets.C with qt 2.3.0

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: >> The problem now is that with lyx-qt, I get a crash as soon as I try >> to create an external inset. The relevant part of the backtrace is Angus> Does the attached cure it? It cures the crash, but the

Re: Compilation failure in checkedwodgets.C with qt 2.3.0

Jean-Marc Lasgouttes wrote: > The problem now is that with lyx-qt, I get a crash as soon as I try > to create an external inset. The relevant part of the backtrace is Does the attached cure it? -- AngusIndex: src/frontends/qt2/QExternal.C =

Re: Compilation failure in checkedwodgets.C with qt 2.3.0

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> I get the following error when compiling: Angus' fix allowed me to go further, and then I needed the patch below (already committed) to finish. The problem now is that with lyx-qt, I get a crash as soon as I try to

Re: Compilation failure in checkedwodgets.C with qt 2.3.0

Jean-Marc Lasgouttes wrote: > Angus, qt 2.3.0 does not have this setPaletteForegroundColor thing. Shame! Ahhh well. It's just a bit of fun and not vital to the use of the class. I'll wrap the contents of setWidget up inside some 3ifdef magic for now. -- Angus

Compilation failure in checkedwodgets.C with qt 2.3.0

I get the following error when compiling: stlport -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt2 -I../../../src -I../../../../lyx-devel/src/ -I../../../../lyx-devel/src/frontends/ -I../../../../lyx-devel/images -I/usr/lib/qt-2.3.0//include -I../../../../lyx-devel/boost -I../../.

Re: Compilation failure with gcc 2.96

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I'd prefere the nested one. Lars> And 2.96 should have no problem... it is used all over boost. It works now. Thanks. JMarc

Re: Compilation failure with gcc 2.96

Andre Poenitz <[EMAIL PROTECTED]> writes: | On Tue, Jul 01, 2003 at 04:06:00PM +0200, Jean-Marc Lasgouttes wrote: | > I believe you :) This is probably a problem related to gcc 2.95/2.96 | > with nested namespaces. | > | > Is using lyx::support:: really better than a plain lyx::? | | It's a ques

Re: Compilation failure with gcc 2.96

On Tue, Jul 01, 2003 at 04:06:00PM +0200, Jean-Marc Lasgouttes wrote: > I believe you :) This is probably a problem related to gcc 2.95/2.96 > with nested namespaces. > > Is using lyx::support:: really better than a plain lyx::? It's a question of taste Personally I am already back from my "

Re: Compilation failure with gcc 2.96

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Assert is in namespace lyx::support. Yes, and all seems reasonable in the code. Lars> I compiled all (xforms/qt/with-included-string) right before I Lars> committed the lyx::support, so I do not really understand this. I beli

Re: Compilation failure with gcc 2.96

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I get: | | g++-2.96 -pg -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/support -I../../src -I../../../lyx-devel/src/support/../ -I../../../lyx-devel/boost -I/usr/X11R6/include -g -O2 -fno-exceptions -ftemplate-depth-30 -Wno-non-template-friend -W

Compilation failure with gcc 2.96

I get: g++-2.96 -pg -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/support -I../../src -I../../../lyx-devel/src/support/../ -I../../../lyx-devel/boost -I/usr/X11R6/include -g -O2 -fno-exceptions -ftemplate-depth-30 -Wno-non-template-friend -W -Wall -c ../../../lyx-devel/src/support/lstrings.C -M

Re: Compilation failure

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Lars> Where have you found old-fashioned included statemens now? Lars> | | I would guess that X headers contain some of these... Lars> Ok... so we should probably move X

Re: Compilation failure

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Where have you found old-fashioned included statemens now? | | I would guess that X headers contain some of these... Ok... so we should probably move Xcalls out into supportwrapper functions then. Lgb

Re: Compilation failure

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | What does this mean for Lyx? First all, everything is fine. Lars> (Sun | expected you to write code in that manner) However, if Lars> you want to make | Lyx a modern C++ program you should change Lars> any old-fashioned inclu

Re: Compilation failure

Michael Schmitt <[EMAIL PROTECTED]> writes: | Once again the question raises whether this is a Sun CC specific feature | or whether this is a behaviour clearly stated in the ANSI standard. I | guess that Sun CC is right. Sun CC is not right, but the above is often used as an iterim solution when

Re: [Fwd: Compilation failure]

Michael Schmitt <[EMAIL PROTECTED]> writes: | Well, the big question is: Does ANSI C++ interpret "signed int" and | "unsigned int" as different data types when used in a template such as | pair? I think the question whether Sun CC is faulty or all other | compilers are just a little bit to genero

Re: Compilation failure

Jean-Marc Lasgouttes wrote: > Michael> On 12 Jan 2000, Jean-Marc Lasgouttes wrote: > >> This is normal, since I need a using std::abort(); here. However, I > >> am surprised that this is not mentionned in your messages. Does it > >> mean that CC 5.0 does not put _everything_ in std? I am a bit >

[Fwd: Compilation failure]

Jean-Marc Lasgouttes wrote: > Michael> The putenv() problem is also fixed. There are are still some > Michael> other error messages (e.g. the signed/unsigned problem with > Michael> 'pair'). However, meanwhile I am skilled in patching the code > Michael> and since no new problems have raised

  1   2   >