> "Jochen" == Jochen Kmietsch <[EMAIL PROTECTED]> writes:
Jochen> patch < pa did work well, LyX 1.0.3 running fine over here in
Jochen> the computer center now.
Nice. Thanks for reporting these problems, since they could have
caused problems.
>> Concerning 1.1.x, it is cvs only, so you will
Hello again !
On 04-Jun-99 Jean-Marc Lasgouttes wrote (concerning Re: lyx-1.0.3 compile fails on
Solaris 2.6 with Sun CC 5.0):
> The error was right, there was some wrong function prototypes
> around. I append to this message a part of the changes I will soon do
Thank you for that.
&g
> "Jochen" == Jochen Kmietsch <[EMAIL PROTECTED]> writes:
>> Jochen, in the meantime, you can just delete the offening commands
>> (two lyxerr.debug() statements) since they are not important. Tell
>> us what happens then.
Jochen> It compiled that file ok. I am waiting for the rest right now
Hello again !
On 04-Jun-99 Jean-Marc Lasgouttes wrote (concerning Re: lyx-1.0.3 compile fails on
Solaris 2.6 with Sun CC 5.0):
> I think I'll wait for 1.1.x for that. We do not want to do much
> cleanup work on 1.0.x anyway...
Is 1.1.x in CVS only or can I get it as a tarball anyw
> "Jochen" == Jochen Kmietsch <[EMAIL PROTECTED]> writes:
Jochen> Nope, the error about the unresolved symbols remains. This
Jochen> was
Jochen> Undefined first referenced symbol in file void
Jochen> MenuRunChktex(Buffer*) lyxfunc.o void MenuRunLaTeX(Buffer*)
Jochen> lyxfunc.o int send_fax(
> Jochen> "../src/lyx_main.C", line 148: Warning (Anachronism): Formal
> Jochen> argument 2 of type extern "C" void(*)(int) in call to
> Jochen> signal(int, extern "C" void(*)(int)) is being passed
> Jochen> void(*)(int). [...] "lyxvc.C", line 337: Warning
> Jochen> (Anachronism): Formal argumen
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Jochen> "../src/lyx_main.C", line 148: Warning (Anachronism): Formal
Jochen> argument 2 of type extern "C" void(*)(int) in call to
Jochen> signal(int, extern "C" void(*)(int)) is being passed
Jochen> void(*)(int). [...] "lyxvc.C
> OK, I did not know that a C++ compiler could generate "C" linkage
> functions. I thought that it could only use them... Is this supposed
> to work everywhere?
I don't know.
Greets,
Asger
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> OK, I did not know that a C++ compiler could generate "C" linkage
>> functions. I thought that it could only use them... Is this
>> supposed to work everywhere?
Asger> I don't know.
The C++ FAQ lite suggests to do
extern "
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Judging from the warning text, it seems we are passing C++
Asger> functions as C functions. I suppose that might not work on
Asger> some platforms, so we should define C style linking for those
Asger> callback functions.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| It is indeed a bug. Lars, what is the right solution, casting to
| long?
The correct solution is to use the new debugstream in 1.1.x, but since
that will not happen in 1.0.x, use a cast:
long(...)
Lgb
Hello again !
On 03-Jun-99 Jean-Marc Lasgouttes wrote (concerning Re: lyx-1.0.3 compile fails on
Solaris 2.6 with Sun CC 5.0):
> Jochen> Hi Folks ! It's me again :) The VSPACE problem does not
> Jochen> appear anymore but now I get
> OK, One problem solved :)
Thanks again f
> "Jochen" == Jochen Kmietsch <[EMAIL PROTECTED]> writes:
Jochen> Hi Folks ! It's me again :) The VSPACE problem does not
Jochen> appear anymore but now I get
OK, One problem solved :)
Jochen> CC -c -O -I. -I. -I../images -I/usr/local/include
Jochen> -I/usr/openwin/include insetlatexaccent
Hi Folks !
It's me again :) The VSPACE problem does not appear anymore but now I get
CC -c -O -I. -I. -I../images -I/usr/local/include-I/usr/openwin/include
insetlatexaccent.C
"insetlatexaccent.C", line 227: Error: Overloading ambiguity between "operator+(const
LString&, const long&)" and
14 matches
Mail list logo
