On Sat, Mar 01, 2025 at 11:48:52AM +0100, Scott Kostyshak wrote:
> On Thu, Feb 27, 2025 at 10:06:42PM +0100, Scott Kostyshak wrote:
> > On Thu, Feb 27, 2025 at 09:59:06PM +0900, Koji Yokota wrote:
> > > > 2025/02/27 17:57、Kornel Benko のメール:
> > > >
> > > > after this commit, I get error compiling
On Thu, Feb 27, 2025 at 10:06:42PM +0100, Scott Kostyshak wrote:
> On Thu, Feb 27, 2025 at 09:59:06PM +0900, Koji Yokota wrote:
> > > 2025/02/27 17:57、Kornel Benko のメール:
> > >
> > > after this commit, I get error compiling with clang-15 ang QT 6.2.4.
> > >
> > > Kornel
> >
> >
> > Thank you,
> 2025/02/28 6:18、Jean-Marc Lasgouttes のメール:
>
> I have not been able to look at the code yet, but why do you have to create
> an explicit key sequence to create a shortcut to a widget? Isn't there a
> simpler Qt mechanism for that?
Actually, “placeholderText” of QCombobox which appears on the
Le 27/02/2025 à 13:59, Koji Yokota a écrit :
2025/02/27 17:57、Kornel Benko のメール:
after this commit, I get error compiling with clang-15 ang QT 6.2.4.
Kornel
Thank you, Kornel.
The operator “+” to combine keys is replaced by “|” as of Qt 6.0.
It is now fixed at 16d1133.
I have no
On Thu, Feb 27, 2025 at 09:59:06PM +0900, Koji Yokota wrote:
> > 2025/02/27 17:57、Kornel Benko のメール:
> >
> > after this commit, I get error compiling with clang-15 ang QT 6.2.4.
> >
> > Kornel
>
>
> Thank you, Kornel.
>
> The operator “+” to combine keys is replaced by “|” as of Qt 6.0.
>
Am Thu, 27 Feb 2025 21:59:06 +0900
schrieb Koji Yokota :
> > 2025/02/27 17:57、Kornel Benko のメール:
> >
> > after this commit, I get error compiling with clang-15 ang QT 6.2.4.
> >
> > Kornel
>
>
> Thank you, Kornel.
>
> The operator “+” to combine keys is replaced by “|” as of Qt 6.0.
>
> 2025/02/27 17:57、Kornel Benko のメール:
>
> after this commit, I get error compiling with clang-15 ang QT 6.2.4.
>
> Kornel
Thank you, Kornel.
The operator “+” to combine keys is replaced by “|” as of Qt 6.0.
It is now fixed at 16d1133.
Koji
--
lyx-devel mailing list
lyx-devel@lists.ly
On 09/28/2015 01:37 PM, Richard Heck wrote:
> Yes, just compiled with fresh build directory, and it was fine. Thanks.
I can confirm this, but! when I compile for qt5 the binary only gets
core dumped. These are the settings in run_cmake.sh
cmake ../lyx \
-G"Unix Makefiles" \
-DLYX_CPACK=OFF \
On 09/28/2015 11:13 AM, Jean-Marc Lasgouttes wrote:
Le 20/09/2015 17:51, Richard Heck a écrit :
The error message is below. I can't make much of it. I think the key
part must be:
../../../src/support/debug.cpp:205:39: required from here
/usr/include/c++/4.9.2/bits/stl_algobase.h:336:18: erro
Le 20/09/2015 17:51, Richard Heck a écrit :
The error message is below. I can't make much of it. I think the key
part must be:
../../../src/support/debug.cpp:205:39: required from here
/usr/include/c++/4.9.2/bits/stl_algobase.h:336:18: error: use of deleted
function ‘std::__detail::_StateSeq
I tried building also with --disable-cxx11, and in that case I do not
get the error above. But I do get the sort of error people are seeing on
OSX:
In file included from ../../../../src/frontends/qt4/Menus.cpp:56:0:
../../../../src/TocBackend.h: In instantiation of ‘void
__gnu_cxx::_SGIAssigna
Please ignore this. I forgot to run cmake...
Abdelrazak Younes wrote:
Hi,
Is this variable new?
4>..\..\..\trunk\src\support\Package.cpp(465) : error C2065:
'LYX_DIR_VER' : identificateur non déclaré
4>..\..\..\trunk\src\support\Package.cpp(468) : error C2065:
'LYX_DIR_VER' : identificateur
Abdelrazak Younes schrieb:
The problem persists and I can't find out the reason. Abdel, do you
see this too on Windows?
No but I can see why. I'll fix it.
Thanks for your fix, the problem is one.
regards Uwe
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
I nowadays get this compiler message:
D:\LyXSVN\lyx-devel\src\graphics\PreviewLoader.cpp(264) : warning
C4355: 'this'
: used in base member initializer list lib /nologo
/OUT:release\libs\graphics.lib release\src\graphics\GraphicsCache.obj
release\src\grap
Uwe Stöhr schrieb:
I nowadays get this compiler message:
D:\LyXSVN\lyx-devel\src\graphics\PreviewLoader.cpp(264) : warning C4355:
'this'
: used in base member initializer list lib /nologo /OUT:release\libs\graphics.lib
release\src\graphics\GraphicsCache.obj release\src\graphics\GraphicsCacheI
Uwe Stöhr wrote:
> Guys I guess someone is using Qt4.3 designer as the recently modified
ui files do not compile with > 4.2 anymore:
Oh shit! Yes it was me who "fixed" some layouts. I asumed that it
doesn't matter what designer version is used as the resulting file is
XML. But it seems that
> Guys I guess someone is using Qt4.3 designer as the recently modified ui files do not compile
with > 4.2 anymore:
Oh shit! Yes it was me who "fixed" some layouts. I asumed that it doesn't matter what designer
version is used as the resulting file is XML. But it seems that Qt's designer is not
Enrico Forestieri wrote:
On Wed, Sep 26, 2007 at 06:12:51PM +0200, Pavel Sanda wrote:
On a clean checkout of trunk, I get:
This is long known issue.
Enrico posted patch before few days, but nobody comited it.
Should be fixed now.
Confiremd, a fresh checkout compiled for me.
On Wed, Sep 26, 2007 at 06:12:51PM +0200, Pavel Sanda wrote:
> > On a clean checkout of trunk, I get:
>
> This is long known issue.
> Enrico posted patch before few days, but nobody comited it.
Should be fixed now.
--
Enrico
> On a clean checkout of trunk, I get:
This is long known issue.
Enrico posted patch before few days, but nobody comited it.
Pavel
On Mon, Sep 03, 2007 at 02:43:03PM +0200, Alfredo Braunstein wrote:
> José Matos wrote:
>
> > Hi,
> > I get this when compiling the latest trunk:
> > make[6]: Entering directory
> > `/home/jamatos/tmp/lyx-build/src/frontends/controllers'
> > /bin/sh ../../../libtool --tag=CXX --mode=compile
> >
> Go ahead...
i got rid of it instead
http://www.lyx.org/trac/changeset/20020
Leuven, E. wrote:
>> Should I revert r20017 until Bo comes back?
>
> or comment out that line...
Go ahead...
A/
> Should I revert r20017 until Bo comes back?
or comment out that line...
Index: src/frontends/controllers/ControlEmbeddedFiles.cpp
===
--- src/frontends/controllers/ControlEmbeddedFiles.cpp (revision 20019)
+++ src/frontends/control
José Matos wrote:
> Hi,
> I get this when compiling the latest trunk:
> make[6]: Entering directory
> `/home/jamatos/tmp/lyx-build/src/frontends/controllers'
> /bin/sh ../../../libtool --tag=CXX --mode=compile
> g++ -DHAVE_CONFIG_H -I. -I../../../src
> -I/home/jamatos/lyx/lyx-devel/src/frontends
Am Freitag, 6. Oktober 2006 22:57 schrieb Guillaume Pothier:
> Hi,
> The floatname method is declared in two files: insetfloat.C and
> insetwrap.C, causing a link error:
IIRC you have to configure with --disable-pch to solve this. Search the
list archives, this was already asked some time ago. T
Andre Poenitz wrote:
On Tue, Sep 19, 2006 at 10:40:46AM +0200, Abdelrazak Younes wrote:
Am I really the only one seeing the problem?
InsetMathXYArrow.C
..\..\..\..\src\mathed\InsetMathXYArrow.C(31) : error C2259:
'InsetMathXYArrow' : cannot instantiate abstract class
due to following
On Tue, Sep 19, 2006 at 10:40:46AM +0200, Abdelrazak Younes wrote:
> Am I really the only one seeing the problem?
>
> InsetMathXYArrow.C
> ..\..\..\..\src\mathed\InsetMathXYArrow.C(31) : error C2259:
> 'InsetMathXYArrow' : cannot instantiate abstract class
> due to following members:
>
On Tue, Sep 19, 2006 at 11:13:55AM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak> Am I really the only one seeing the problem?
>
> Could it be a problem of having two file names that differ only by
> casing?
Such problems usually occur with things checked in on Win* and checked
out on *nix. It'
Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Am I really the only one seeing the problem?
i think you might need the attached...
Ah...!! I thought CMake used exclusively the glob approach
Thanks, please commit.
it's in...
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Am I really the only one seeing the problem?
i think you might need the attached...
Ah...!! I thought CMake used exclusively the glob approach
Thanks, please commit.
Abdel.
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Andre Poenitz wrote:
>> On Sun, Sep 17, 2006 at 09:16:42PM +0200, Abdelrazak Younes wrote:
I still have compilation problems:
>>> Is anybody else seeing this? I am not sure of what the fix could
>>> be. Maybe you
Abdelrazak Younes wrote:
Am I really the only one seeing the problem?
i think you might need the attached...
Index: src/mathed/CMakeLists.txt
===
--- src/mathed/CMakeLists.txt (revision 15058)
+++ src/mathed/CMakeLists.txt (working
Andre Poenitz wrote:
On Sun, Sep 17, 2006 at 09:16:42PM +0200, Abdelrazak Younes wrote:
I still have compilation problems:
Is anybody else seeing this? I am not sure of what the fix could be.
Maybe you didn't commit everything Andre?
I commited everything under src/ as far as I can tell.
How
On Sun, Sep 17, 2006 at 09:16:42PM +0200, Abdelrazak Younes wrote:
> >I still have compilation problems:
>
> Is anybody else seeing this? I am not sure of what the fix could be.
> Maybe you didn't commit everything Andre?
I commited everything under src/ as far as I can tell.
However, the modem
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: poenitz
Date: Sun Sep 17 12:00:15 2006
New Revision: 15029
URL: http://www.lyx.org/trac/changeset/15029
Log:
cleanup after svn hang-up, #undef CursorShape. Should be compilable
ganin n=
ow.
I still have compilation problems:
Is any
On Mon, Jul 07, 2003 at 05:49:55PM +0200, Lars Gullik Bj?nnes wrote:
> | For example ? When the LyX code has some clients maybe, but until then
> | we have only to deal with the platform's namespace
>
> Note that lyx is also its own client.
This is true. But have we had any real namespace proble
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Jul 07, 2003 at 08:32:44AM +0200, Lars Gullik Bj?nnes wrote:
|
| > | On an ideal world, I don't see the point of the lyx:: namespace.
| >
| > except when used to protect against our own pollution of the global
| > namespace.
|
| For example ? Whe
On Mon, Jul 07, 2003 at 08:32:44AM +0200, Lars Gullik Bj?nnes wrote:
> | On an ideal world, I don't see the point of the lyx:: namespace.
>
> except when used to protect against our own pollution of the global
> namespace.
For example ? When the LyX code has some clients maybe, but until then
we
Andre Poenitz wrote:
> Ok. Didn't think of this.
>
> So in fact even the implementation might be wrapped in 'namespace lyx {
> ... }'...
This is exactly what I did in src/graphics/*.C. Eg GraphicsLoader.C
namespace grfx {
struct Loader::Impl : boost::signals::trackable {
...
};
Loader
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jun 25, 2003 at 10:43:50AM +0200, Lars Gullik Bjønnes wrote:
| > | Possibly.
| >
| > but it will not protect us from bad macros...
|
| Indeed.
|
| > | But before I agree on doing so I want 'using namespace lyx;' legalized
| > | within LyX .C s
Andre Poenitz wrote:
> On Wed, Jun 25, 2003 at 09:05:28AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > So just rename LyX 'ControlRef' to something else.
>>
>> More generally, should we not think of putting the whole of LyX inside
>> namespace lyx at some stage?
>
> Possibly.
>
> Bu
On Wed, Jun 25, 2003 at 10:43:50AM +0200, Lars Gullik Bjønnes wrote:
> | Possibly.
>
> but it will not protect us from bad macros...
Indeed.
> | But before I agree on doing so I want 'using namespace lyx;' legalized
> | within LyX .C source. I certainly won't start writing a few dozen 'using
> |
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jun 25, 2003 at 09:05:28AM +, Angus Leeming wrote:
| > Andre Poenitz wrote:
| > > So just rename LyX 'ControlRef' to something else.
| >
| > More generally, should we not think of putting the whole of LyX inside
| > namespace lyx at some st
On Wed, Jun 25, 2003 at 09:05:28AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > So just rename LyX 'ControlRef' to something else.
>
> More generally, should we not think of putting the whole of LyX inside
> namespace lyx at some stage?
Possibly.
But before I agree on doing so I want
Andre Poenitz wrote:
> So just rename LyX 'ControlRef' to something else.
More generally, should we not think of putting the whole of LyX inside
namespace lyx at some stage?
--
Angus
On Tue, Jun 24, 2003 at 03:47:16PM -0400, Ronald Florence wrote:
> I'd welcome further suggestions. Regards,
So just rename LyX 'ControlRef' to something else.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jeffe
The following message is a courtesy copy of an article
that has been posted to gmane.editors.lyx.general as well.
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> Juergen Spitzmueller wrote:
>
> > ControlRef. Does it help if you change LyX's ControlRef and all instances
> > to ControlLyXRef or s
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Thu, Apr 03, 2003 at 04:30:02PM +0200, Jean-Marc Lasgouttes
John> wrote:
>> but it had no effect.
John> Then I do not know what can be done.
OK, let's assume it is by construction, then. It feels a bit like java
apps (or mozilla pre
On Thu, Apr 03, 2003 at 04:30:02PM +0200, Jean-Marc Lasgouttes wrote:
> but it had no effect.
Then I do not know what can be done.
john
> "John" == John Levon <[EMAIL PROTECTED]> writes:
>> Sorry, I took a look but did not find the code where this would be
>> relevant. I'd be glad to have more hints.
John> inside switchPanel(). You might need to do
stack_-> setUpdatesEnabled(.. etc. too - not sure
I tried
void PanelStack:
On Wed, Apr 02, 2003 at 02:24:43PM +0200, Jean-Marc Lasgouttes wrote:
> John> It is literally impossible to remove it.
>
> Too bad... Can't you set height to 0?
It might be possible to find it via Qt's reflection stuff, it might not
... I'll experiment llater
> >> Also, there is a significant f
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Fri, Mar 28, 2003 at 07:05:01PM +0100, Jean-Marc Lasgouttes
John> wrote:
>> It compiles now. The panels seem to work as intended, although
>> there is an empty header bar at the top of the tree that does not
>> look right.
John> It i
On Fri, Mar 28, 2003 at 07:05:01PM +0100, Jean-Marc Lasgouttes wrote:
> It compiles now. The panels seem to work as intended, although there
> is an empty header bar at the top of the tree that does not look
> right.
It is literally impossible to remove it.
> Also, there is a significant flicker
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Fri, Mar 28, 2003 at 06:17:00PM +0100, Jean-Marc Lasgouttes
John> wrote:
>> ../../../../lyx-devel/src/frontends/qt2/panelstack.C: In method
>> `PanelStack::PanelStack (QWidget *,
John> Try again. IT would be good if you could check t
On Fri, Mar 28, 2003 at 06:17:00PM +0100, Jean-Marc Lasgouttes wrote:
> ../../../../lyx-devel/src/frontends/qt2/panelstack.C: In method
> `PanelStack::PanelStack (QWidget *,
Try again. IT would be good if you could check that the prefs / doc
dialog work as expected too
regards
john
On Wednesday 30 January 2002 12:19 pm, Pascal Francq wrote:
> Hi,
> I try to compile the actual cvs branch with qt2 as frontend, and I have the
following errors:
A known and temporary bug. A repair is in the pipe line.
Angus
On Tue, Sep 25, 2001 at 03:20:08PM -0700, Kayvan A. Sylvan wrote:
> You need at least gcc-2.95 to compile CVS lyx.
But the problem is only with the lyxsum.C file.
If you revert this file to revision 1.18, you will be compile lyx without
changing the compiler.
You need at least gcc-2.95 to compile CVS lyx.
---Kayvan
On Wed, Sep 26, 2001 at 12:36:46AM +0200, ben wrote:
> I try to compile from the current CVS lyx-devel, and it fails with the
> following error message:
>
> /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H
Juergen Vigna <[EMAIL PROTECTED]> writes:
| > We do not use C-style casts. Use C++ casts.
| >
| > static_cast(...)
|
| You surely meant cost_cast isn't it! Anyway I'll commit Andres fix for
| this now!
actually my comment was intended as a more general one.
--
Lgb
On 13-Jul-2001 Lars Gullik Bjønnes wrote:
>| -UpdatableInset * in = inset.getLockingInset();
>| +InsetText * in = (InsetText *) inset.getLockingInset();
>| if (&inset == in)
>| return const_cast(this);
>| return in;
>
> We do not use C-style casts. Use C++ casts.
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| UpdatableInset * InsetCollapsable::getLockingInset() const
| {
| - UpdatableInset * in = inset.getLockingInset();
| + InsetText * in = (InsetText *) inset.getLockingInset();
| if (&inset == in)
| return const_cast(this
> > Should I guess who did it? It's friday anyway...
>
> Well you know guessing is not enough you would have to "know"!
On Fridays just guessing is more than enough...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
On 13-Jul-2001 Andre Poenitz wrote:
> No, the method got a 'const' qualifier yesterday...
Hmm who did this change, I'm really wondering!
> Should I guess who did it? It's friday anyway...
Well you know guessing is not enough you would have to "know"!
Jürgen
--
-._-._-._-._-._-._-._-.
On Fri, Jul 13, 2001 at 09:46:10AM +0200, Andre Poenitz wrote:
> > Did you change your compiler recently? This code is in there I guess mostly
> > one year!
>
> No, the method got a 'const' qualifier yesterday...
Yes, that would explain it.
--
Kayvan A. Sylvan | Proud husband of
On Fri, Jul 13, 2001 at 09:39:03AM +0200, Juergen Vigna wrote:
>
> On 13-Jul-2001 Kayvan A. Sylvan wrote:
>
> > UpdatableInset * InsetCollapsable::getLockingInset() const
> > {
> > UpdatableInset * in = inset.getLockingInset();
> > error > if (&inset == in
> Did you change your compiler recently? This code is in there I guess mostly
> one year!
No, the method got a 'const' qualifier yesterday...
Should I guess who did it? It's friday anyway...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
On 13-Jul-2001 Kayvan A. Sylvan wrote:
> UpdatableInset * InsetCollapsable::getLockingInset() const
> {
> UpdatableInset * in = inset.getLockingInset();
> error > if (&inset == in)
> return const_cast(this);
> return in;
On Fri, Jul 13, 2001 at 02:05:38AM -0300, Garst R. Reese wrote:
> "Kayvan A. Sylvan" wrote:
> >
> > This is new. I haven't tracked it yet, but I don't think it's due to my
> > Literate patch. Any ideas?
> >
> I did not check that closely the msgs, but current cvs compiled for me.
> gcc-3.0
> xfo
"Kayvan A. Sylvan" wrote:
>
> This is new. I haven't tracked it yet, but I don't think it's due to my
> Literate patch. Any ideas?
>
I did not check that closely the msgs, but current cvs compiled for me.
gcc-3.0
xforms-.89-5
libc-2.2
linux PII
Garst
Dear Albert,
the problems with compiling LyX-1.1.6cvs refer to "SUN Solaris Forte C++ 6.0
Update 1" (which is CC version 5.2). This is the latest version of the product.
JMarc,
--
==
Michael Schmitt
On Tue, Jan 09, 2001 at 10:05:08AM +0100, Michael Schmitt wrote:
> Jean-Marc Lasgouttes wrote:
>
> > Note that it compiles with compaq cxx 6.2 in strict ansi mode, and is
> > one is pretty pedantic too.
>
> Well but how is it possible that, e.g., the following error message does not
> appear wit
Jean-Marc Lasgouttes wrote:
> Note that it compiles with compaq cxx 6.2 in strict ansi mode, and is
> one is pretty pedantic too.
Well but how is it possible that, e.g., the following error message does not
appear with other compilers?
"FormBase.C", line 214: Error: Could not find a match for S
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hello, as I was wondering why SUN CC complains about so many
Michael> problems but g++ doesn't, I tried to run g++ with options
Michael> '-ansi -pedantic'. Surprise, surprise! Compilation fails,
Michael> too!
Note that it co
Michael Schmitt <[EMAIL PROTECTED]> writes:
| Hello,
|
| as I was wondering why SUN CC complains about so many problems but g++ doesn't,
| I tried to run g++ with options '-ansi -pedantic'. Surprise, surprise!
| Compilation fails, too!
I don't expect it to work with those switches anyway so...
Duncan Simpson <[EMAIL PROTECTED]> writes:
| gcc 2.96 from CVS and glibc 2.1.2 compilation dies with
I often compile with gcc 2.96 (latest cvs) and glibc 2.1.2, but I am
using the libstdc++-v3 in the gcc 2.96 cvs checkout.
Note also that you are compiling with an experimantal compiler, with
som
> "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes:
Duncan> gcc 2.96 from CVS and glibc 2.1.2 compilation dies with snipped>
I'd be interested to see the stuff which got snipped. Which file were
you compiling?
Duncan> I know the standadr may say this behaviour is borken but in
Duncan
Duncan Simpson wrote:
>
> gcc 2.96 from CVS and glibc 2.1.2 compilation dies with
gcc 2.9.5.2 glibc 2.1.3 linux intel = no problem here with this
morning's CVS.
Garst
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: Wrong solution. Is I
Lars> said in t the changelog entry or was it perhaps in a mail to
Lars> cvslog... I probably added explicit in too many places, but most
Lars> of them should be there
Dekel Tsur <[EMAIL PROTECTED]> writes:
Wrong solution. Is I said in t the changelog entry or was it perhaps
in a mail to cvslog... I probably added explicit in too many places,
but most of them should be there.
The point with adding them is to avoid impicit conversions (so called
conversion con
Allan Rae <[EMAIL PROTECTED]> writes:
| On 18 Feb 2000, Lars Gullik Bjønnes wrote:
|
| > Allan Rae <[EMAIL PROTECTED]> writes:
| >
| > | On Thu, 17 Feb 2000, Ambrose Kofi Laing wrote:
| > | > I have a compilation problem getting lyx1.1.4 to work on Solaris2.7
| > | > There is a declaration> ext
On 18 Feb 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On Thu, 17 Feb 2000, Ambrose Kofi Laing wrote:
> | > I have a compilation problem getting lyx1.1.4 to work on Solaris2.7
> | > There is a declaration> extern GC fl_gc;> in the file screen.C,> which
> | > doe
Allan Rae <[EMAIL PROTECTED]> writes:
| On Thu, 17 Feb 2000, Ambrose Kofi Laing wrote:
| > I have a compilation problem getting lyx1.1.4 to work on Solaris2.7
| > There is a declaration> extern GC fl_gc;> in the file screen.C,> which
| > does not get resolved at link time.
| >
| > Anyone help?
On Thu, 17 Feb 2000, Ambrose Kofi Laing wrote:
> I have a compilation problem getting lyx1.1.4 to work on Solaris2.7
> There is a declaration> extern GC fl_gc;> in the file screen.C,> which
> does not get resolved at link time.
>
> Anyone help? Please respond to my email address.
This is fast b
Dekel Tsur <[EMAIL PROTECTED]> writes:
| Compiling the latest CVS version gives the following error
|
| TextCache.C: In function static void TextCache::show(class ostream &, const class
|LyXText *)':
| TextCache.C:79: no match for call to (show_text) (LyXText *)'
| TextCache.C:61: candidates ar
> "Jan" == Jan van der Lee <[EMAIL PROTECTED]> writes:
Jan> I just downloaded and compiled Lyx for my Solaris 2.5.1
Jan> box. There was a compilation error (I'm using egcs-1.0.3) for
Jan> file insetbib.C:
Jan> g++ -c -g -O2 -I. -I. -I../images -I/usr/openwin/include
Jan> insetbib.C insetbib.
86 matches
Mail list logo
