Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris]

[Arnd Hanses]

On Wed, 22 Dec 1999 12:59:28 +1000 (GMT+1000), Allan Rae wrote:

ven with 128MB of RAM and dual 400MHz processors it takes twice as long
to compile with SGI's string and _no_ exceptions as it does to compile lyx
with the lyx supplied string _and_ exceptions!  (12minutes vs 6minutes)
The only difference being which string implementation is used.  When
exceptions are used when compiling with SGI's string LyXAction.C takes
about 180MB!! to compile so swaps terribly and compile time is over
30minutes -- when I used to do this on my old P100 I'd let it compile
overnight since it took so long.

FYI the executable sizes with lyx's string:  1.3 - 10MB
 with SGI's string:  2.4 - 50MB

There isn't any particularly noticeable difference in performance between
the two although I haven't run any benchmarks -- like load times etc.

Okay, so this is just an arguement based on the painful compile times
experienced with just one string implementation.  However at least with
our own string implementation we can add a few extra asserts if we wish to
enforce stricter requirements and thus better checking than is required by
the standard.

Anyway, I've been wanting to share these numbers for a while since we also
had discussions about the use of exceptions by default.

When using aggressive optimizing on huge functions/classes with more
modern compilers (like egcs/pgcc) you are also very likely to receive
'virtual memory exhausted' errors. I've seen this various times even
with plain C functions, i.e. gcc  2.8.x claiming far more than 300 Mb
of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:


Optimize less (or dont't optimize at all), use only small
functions. 

Old stable LyX version seems to compile successfully and appears to run
stable, even with pgcc -O6. If I've time, I'll try to see whether the
recent cvs version compiles and optimizes (but this after Xmas).

Apropos exceptions. Here are some forwarded annotations by the pgcc for
OS/2 maintainer (Andrew Zabolotny, [EMAIL PROTECTED]) on this topic. His
pgcc page is linked from the GNU gcc site, if you are interested. It
seems, he's one of those people who use a compiler mainly for
compilation proper, i.e. to have some nice asm output for later reading
:-). 

Maybe it should be included into INSTALL.OS2? Moreover the generic
problems discussed here are not OS-specific.

Have nice days,

Arnd

---forwarded annotations-

"PGCC 1.1.3 and multithreaded exceptions! :-) However, I didn't
thoroughly
tested it (I'm leaving this as a exercise to the reader :-); this is
just the first
release. 

I've ported almost all binutils 2.9.1 to OS/2 including GAS! It is not
strictly
required if you just need a high-level language compiler such as C or
C++, but
you should consider downloading it if you: [...]

I'm waiting for your comments and bug reports (related to the OS/2 port
only,
of course). 

[...]

Tips and tricks

   1.By default PGCC for OS/2 uses frame-unwind-info exceptions. This
 mean that with -fexceptions (which is on by default) gcc will
partially
 generate debug info which is used then for frame unwinding during
 exceptions. Due to this fact files become larger (sometimes up to
~50%!)
 but this exception mechanism has the advantage of having almost no
 overhead at code execution time. That is, try {...} catch () {...}
 generates almost no code at all, so the programs runs as fast as
before.
 The disadvantage of this is executable size, of course. Nothing
comes
 from nothing. So, if you DO NOT use exceptions, you SHOULD turn
 them off (by using -fno-exceptions switch) - this will greatly
reduce
 your code size. 

  2.There is also a alternative method for handling exceptions. It is
called
 setjump/longjump method, and as you understand it uses
setjmp/longjmp
 instructions. When try {} is encountered, a setjmp() is executed,
and
 when a exception is thrown it longjumps to the last setjmp(). This
 method generates LOTS of messy code (most other PC C compilers
uses
 same method - I've took a look at Watcom and BCPP) which decreases
 execution time but occupies less space than frame-unwind-info. To
use
 this exception handling method you should use the
-fsjlj-exceptions
 switch. 

   3.Please do not mix code compiled with sjlj-exceptions and with
 frame-unwind-info exceptions! Exception won't cross the boundary
 between different-style exception handling code, so most likely
you will
 got a 'unhandled exception'. Actually this includes inability to
use
 pre-compiled libstdc++ with -fsjlj-exceptions (it was compiled
with
 frame-unwind-info exception handling). 

  4.In general, my opinion is that you better don't use exceptions at
all - the
 mechanism is neat but it costs too much; without hardware support
for
 exceptions it doesn't work good. If you like speed and code size,
forget
 exceptions; use 

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Allan Rae [EMAIL PROTECTED] writes:

| Not all string classes are created equal.  Take SGI's STL string for
| example.  It's implemented in such a way that there is a 3-5 fold increase
| in size in an unstripped executable with debugging enabled and a 2-3 fold
| increase in size in a stripped -O2 no-debugging executable!

This not true with the stdlibc++ for gcc that is beeing developed. I
see lonk compile times there as well and huge processes when doing so,
but the finished exe is smaller than with the stdlib delivered as
standard with gcc.

| FYI the executable sizes with lyx's string:  1.3 - 10MB
|  with SGI's string:  2.4 - 50MB
| 
| There isn't any particularly noticeable difference in performance between
| the two although I haven't run any benchmarks -- like load times etc.

I would gess the difference in speed to be very small. I benchmarked
lyxstring against bastring (the one provided with gcc) and lyxstring
win in some cases but bastring in most, especially with high
optimization.

| Anyway, I've been wanting to share these numbers for a while since we also
| had discussions about the use of exceptions by default.

As compilers,linkers and libraries mature compile time, exe size will
go drastically down (just remeber the post a couple of days ago where
a new inliner where added to gcc improving compile speed of template
code a lot)

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Allan Rae]

On 22 Dec 1999, Lars Gullik Bjønnes wrote:

 Allan Rae [EMAIL PROTECTED] writes:
 
 | Not all string classes are created equal.  Take SGI's STL string for
 | example.  It's implemented in such a way that there is a 3-5 fold increase
 | in size in an unstripped executable with debugging enabled and a 2-3 fold
 | increase in size in a stripped -O2 no-debugging executable!
 
 This not true with the stdlibc++ for gcc that is beeing developed. I
 see lonk compile times there as well and huge processes when doing so,
 but the finished exe is smaller than with the stdlib delivered as
 standard with gcc.

This is certainly good to hear.

The biggest problem with SGI's implementation seems to be the use of
multiple templates or layers of templates to implement each standard
element (vector, string etc.).  This really taxes the current compilers
and hence the massive bloat in code size.

Allan. (ARRae)

Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris]

[Arnd Hanses]

On Wed, 22 Dec 1999 12:59:28 +1000 (GMT+1000), Allan Rae wrote:

>ven with 128MB of RAM and dual 400MHz processors it takes twice as long
>to compile with SGI's string and _no_ exceptions as it does to compile lyx
>with the lyx supplied string _and_ exceptions!  (12minutes vs 6minutes)
>The only difference being which string implementation is used.  When
>exceptions are used when compiling with SGI's string LyXAction.C takes
>about 180MB!! to compile so swaps terribly and compile time is over
>30minutes -- when I used to do this on my old P100 I'd let it compile
>overnight since it took so long.
>
>FYI the executable sizes with lyx's string:  1.3 - 10MB
> with SGI's string:  2.4 - 50MB
>
>There isn't any particularly noticeable difference in performance between
>the two although I haven't run any benchmarks -- like load times etc.
>
>Okay, so this is just an arguement based on the painful compile times
>experienced with just one string implementation.  However at least with
>our own string implementation we can add a few extra asserts if we wish to
>enforce stricter requirements and thus better checking than is required by
>the standard.
>
>Anyway, I've been wanting to share these numbers for a while since we also
>had discussions about the use of exceptions by default.

When using aggressive optimizing on huge functions/classes with more
modern compilers (like egcs/pgcc) you are also very likely to receive
'virtual memory exhausted' errors. I've seen this various times even
with plain C functions, i.e. gcc > 2.8.x claiming far more than 300 Mb
of virtual memory. The gcc/egcs faq has very 'helpful' recommendations:


Optimize less (or dont't optimize at all), use only small
functions. 

Old stable LyX version seems to compile successfully and appears to run
stable, even with pgcc -O6. If I've time, I'll try to see whether the
recent cvs version compiles and optimizes (but this after Xmas).

Apropos exceptions. Here are some forwarded annotations by the pgcc for
OS/2 maintainer (Andrew Zabolotny, <[EMAIL PROTECTED]>) on this topic. His
pgcc page is linked from the GNU gcc site, if you are interested. It
seems, he's one of those people who use a compiler mainly for
compilation proper, i.e. to have some nice asm output for later reading
:-). 

Maybe it should be included into INSTALL.OS2? Moreover the generic
problems discussed here are not OS-specific.

Have nice days,

Arnd

---forwarded annotations-

"PGCC 1.1.3 and multithreaded exceptions! :-) However, I didn't
thoroughly
tested it (I'm leaving this as a exercise to the reader :-); this is
just the first
release. 

I've ported almost all binutils 2.9.1 to OS/2 including GAS! It is not
strictly
required if you just need a high-level language compiler such as C or
C++, but
you should consider downloading it if you: [...]

I'm waiting for your comments and bug reports (related to the OS/2 port
only,
of course). 

[...]

Tips and tricks

   1.By default PGCC for OS/2 uses frame-unwind-info exceptions. This
 mean that with -fexceptions (which is on by default) gcc will
partially
 generate debug info which is used then for frame unwinding during
 exceptions. Due to this fact files become larger (sometimes up to
~50%!)
 but this exception mechanism has the advantage of having almost no
 overhead at code execution time. That is, try {...} catch () {...}
 generates almost no code at all, so the programs runs as fast as
before.
 The disadvantage of this is executable size, of course. Nothing
comes
 from nothing. So, if you DO NOT use exceptions, you SHOULD turn
 them off (by using -fno-exceptions switch) - this will greatly
reduce
 your code size. 

  2.There is also a alternative method for handling exceptions. It is
called
 setjump/longjump method, and as you understand it uses
setjmp/longjmp
 instructions. When try {} is encountered, a setjmp() is executed,
and
 when a exception is thrown it longjumps to the last setjmp(). This
 method generates LOTS of messy code (most other PC C compilers
uses
 same method - I've took a look at Watcom and BCPP) which decreases
 execution time but occupies less space than frame-unwind-info. To
use
 this exception handling method you should use the
-fsjlj-exceptions
 switch. 

   3.Please do not mix code compiled with sjlj-exceptions and with
 frame-unwind-info exceptions! Exception won't cross the boundary
 between different-style exception handling code, so most likely
you will
 got a 'unhandled exception'. Actually this includes inability to
use
 pre-compiled libstdc++ with -fsjlj-exceptions (it was compiled
with
 frame-unwind-info exception handling). 

  4.In general, my opinion is that you better don't use exceptions at
all - the
 mechanism is neat but it costs too much; without hardware support
for
 exceptions it doesn't work good. If you like speed and code size,

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Allan Rae <[EMAIL PROTECTED]> writes:

| Not all string classes are created equal.  Take SGI's STL string for
| example.  It's implemented in such a way that there is a 3-5 fold increase
| in size in an unstripped executable with debugging enabled and a 2-3 fold
| increase in size in a stripped -O2 no-debugging executable!

This not true with the stdlibc++ for gcc that is beeing developed. I
see lonk compile times there as well and huge processes when doing so,
but the finished exe is smaller than with the stdlib delivered as
standard with gcc.

| FYI the executable sizes with lyx's string:  1.3 - 10MB
|  with SGI's string:  2.4 - 50MB
| 
| There isn't any particularly noticeable difference in performance between
| the two although I haven't run any benchmarks -- like load times etc.

I would gess the difference in speed to be very small. I benchmarked
lyxstring against bastring (the one provided with gcc) and lyxstring
win in some cases but bastring in most, especially with high
optimization.

| Anyway, I've been wanting to share these numbers for a while since we also
| had discussions about the use of exceptions by default.

As compilers,linkers and libraries mature compile time, exe size will
go drastically down (just remeber the post a couple of days ago where
a new inliner where added to gcc improving compile speed of template
code a lot)

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Allan Rae]

On 22 Dec 1999, Lars Gullik Bjønnes wrote:

> Allan Rae <[EMAIL PROTECTED]> writes:
> 
> | Not all string classes are created equal.  Take SGI's STL string for
> | example.  It's implemented in such a way that there is a 3-5 fold increase
> | in size in an unstripped executable with debugging enabled and a 2-3 fold
> | increase in size in a stripped -O2 no-debugging executable!
> 
> This not true with the stdlibc++ for gcc that is beeing developed. I
> see lonk compile times there as well and huge processes when doing so,
> but the finished exe is smaller than with the stdlib delivered as
> standard with gcc.

This is certainly good to hear.

The biggest problem with SGI's implementation seems to be the use of
multiple templates or layers of templates to implement each standard
element (vector, string etc.).  This really taxes the current compilers
and hence the massive bloat in code size.

Allan. (ARRae)

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

 Michael In insets/figinset.C, change include statement in line 35:
 
 Michael#include "signal.h"
 
 Michael (seems like csignal does not declare kill but signal.h does)
 
 I find this one annoying... Are you sure kill is not in the std::
 namespace?

Yes, I checked all header files available in the Sun CC distribution.
'kill' is not included in 'csignal'! I discussed this problem with one
of my students and he was also wondering whether kill is included in the
C/C++ standard library at all.

Michael

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==
 S/MIME Cryptographic Signature

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

> Michael> In insets/figinset.C, change include statement in line 35:
> 
> Michael>#include "signal.h"
> 
> Michael> (seems like csignal does not declare kill but signal.h does)
> 
> I find this one annoying... Are you sure kill is not in the std::
> namespace?

Yes, I checked all header files available in the Sun CC distribution.
'kill' is not included in 'csignal'! I discussed this problem with one
of my students and he was also wondering whether kill is included in the
C/C++ standard library at all.

Michael

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==
 S/MIME Cryptographic Signature

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

| "insetinclude.h", line 132: Warning: InsetInclude::display hides the
| virtual function Inset::display(bool).
| "insetindex.h", line 77: Warning: InsetPrintIndex::display hides the
| virtual function Inset::display(bool).

These are a false warning from the compiler, it seems that it does not
understand overloading properly:

int display();
void display(int);

is perfectly fine.

| "BufferView.C", line 1257: Warning: work_area_width hides
| BufferView::work_area_width.

it seems that BufferView::work_area_with is not used, so I will just
remove it.

| "LaTeX.C", line 300: Warning: file hides LaTeX::file.

fixed.

| "LaTeX.C", line 373: Warning: file hides LaTeX::file.

fixed.

| "buffer.C", line 233: Warning: filename hides Buffer::filename.

fixed.

| "buffer.C", line 1178: Warning: filename hides Buffer::filename.

fixed

| "buffer.C", line 1246: Warning: filename hides Buffer::filename.

fixed

| "buffer.C", line 1571: Warning: filename hides Buffer::filename.

fixdd

| "buffer.C", line 2123: Warning: String literal converted to char* in
| initialization.

fixed

| "buffer.C", line 2144: Warning: filename hides Buffer::filename.

fixed

| "buffer.C", line 2727: Warning: filename hides Buffer::filename.

fixed

| "lyx_gui.C", line 76: Warning: String literal converted to char* in
| initialization.

these are not easy to fix. And strictly speaking this warning is only
partly true. It is true that in C++ string literals are of the type
char const *, but all C++ compilers are required to allow a string
literal to be assigned to a char *. I am not sure if a diagnostic is
required when this is done, and it should at least be possible to turn
it off.

| "text.C", line 709: Warning: paperwidth hides LyXText::paperwidth.

fixed.

| "text2.C", line 746: Warning: cursor hides LyXText::cursor.

fixed

| "text2.C", line 774: Warning: cursor hides LyXText::cursor.

fixed

| "text2.C", line 806: Warning: cursor hides LyXText::cursor.

fixed 

| "text2.C", line 3484: Warning: cursor hides LyXText::cursor.

fixed

| Eagerly awaiting the next LyX release,

Should not be too long too wait now...

| PS: Is it true that you provide your own string class? Which C++
| compiler supports "pair" and algorithms but does not provide "string"? I
| think you should take the string class for granted.

I think most or all C++ compilers today provides a string class,
however this string class is often not conforming to the C++ Standard.
Most notably it often lacks the basic_string::clear member, and often
the arguments to basic_string::replace are in the wrong order. 
| 
| ++
| 
| In mathed/math_symbol, add a cast in line 547:
| 
| char * sx = const_cast char * ( strstr(data[2], "") );
| ^^

What strange strstr do you have that returns a "char const *"??
AFAIK it should return "char *"

| In insets/figinset.C, change include statement in line 35:
| 
|#include "signal.h"
| 
| (seems like csignal does not declare kill but signal.h does)

What about std::kill then.


| In insets/insetlatexaccent.h move ACCENT_TYPES to the public part;
| otherwise the corresponding .C file will not compile
| ("insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES
| is not accessible from file level.)

I still think this is strange, but it is the correct fix.

| In support/filetools.C, add cast in line 336:
| 
| int retval = putenv(const_cast char * (new
| string(envstr)-c_str()));

Since most putenv's don't take a "char *", but a "char const *" this fix
is not good.

| In support/lstrings.C, line 195:
| 
| Error: Could not find a match for std::count(const char*, const
| char*, const char).
| 
| I have no idea how to fix this. Does anybody have an idea what may be
| wrong???

This is fixed in cvs _very_ soon, I have the fix in my own tree.

Basically your compiler has the wrong prototype for count. (it is not
standard conforming).

| In support/lyxsum.C, add in line 21:
| 
|   using namespace std;  // shouldn't you do so in general???

no. And I don't like this fix either. We should almost never pull
entire namespaces into action. Much better to use

using std::foo; 

for each funciton foo from namespace std that we need.

| In bmtable, add the following lines below the include statements:
| 
|using std::free;
|using std::calloc;

As I said somewhere else the correct fix here is to compile bmtable
with a C compiler since it is really a C file. This can probably be
done quite easy.

Ok, I did this and will put this in cvs.


| In file chset.h, add:
| 
| #include utility
| using std::pair;
| using std::make_pair;  // may also be put in chset.C

using declarations should always be made as local as possible.

| 1217: return make_pair(true, static_castunsigned(cit -
| classlist.begin()));
| 1219: return make_pair(false, 0u);
| 1245: return make_pair(true, static_case unsigned ( LYX_DUMMY_LAYOUT )
| );
| 1247: 

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| "insetinclude.h", line 132: Warning: InsetInclude::display hides the
| virtual function Inset::display(bool).
| "insetindex.h", line 77: Warning: InsetPrintIndex::display hides the
| virtual function Inset::display(bool).

These are a false warning from the compiler, it seems that it does not
understand overloading properly:

int display();
void display(int);

is perfectly fine.

| "BufferView.C", line 1257: Warning: work_area_width hides
| BufferView::work_area_width.

it seems that BufferView::work_area_with is not used, so I will just
remove it.

| "LaTeX.C", line 300: Warning: file hides LaTeX::file.

fixed.

| "LaTeX.C", line 373: Warning: file hides LaTeX::file.

fixed.

| "buffer.C", line 233: Warning: filename hides Buffer::filename.

fixed.

| "buffer.C", line 1178: Warning: filename hides Buffer::filename.

fixed

| "buffer.C", line 1246: Warning: filename hides Buffer::filename.

fixed

| "buffer.C", line 1571: Warning: filename hides Buffer::filename.

fixdd

| "buffer.C", line 2123: Warning: String literal converted to char* in
| initialization.

fixed

| "buffer.C", line 2144: Warning: filename hides Buffer::filename.

fixed

| "buffer.C", line 2727: Warning: filename hides Buffer::filename.

fixed

| "lyx_gui.C", line 76: Warning: String literal converted to char* in
| initialization.

these are not easy to fix. And strictly speaking this warning is only
partly true. It is true that in C++ string literals are of the type
char const *, but all C++ compilers are required to allow a string
literal to be assigned to a char *. I am not sure if a diagnostic is
required when this is done, and it should at least be possible to turn
it off.

| "text.C", line 709: Warning: paperwidth hides LyXText::paperwidth.

fixed.

| "text2.C", line 746: Warning: cursor hides LyXText::cursor.

fixed

| "text2.C", line 774: Warning: cursor hides LyXText::cursor.

fixed

| "text2.C", line 806: Warning: cursor hides LyXText::cursor.

fixed 

| "text2.C", line 3484: Warning: cursor hides LyXText::cursor.

fixed

| Eagerly awaiting the next LyX release,

Should not be too long too wait now...

| PS: Is it true that you provide your own string class? Which C++
| compiler supports "pair" and algorithms but does not provide "string"? I
| think you should take the string class for granted.

I think most or all C++ compilers today provides a string class,
however this string class is often not conforming to the C++ Standard.
Most notably it often lacks the basic_string::clear member, and often
the arguments to basic_string::replace are in the wrong order. 
| 
| ++
| 
| In mathed/math_symbol, add a cast in line 547:
| 
| char * sx = const_cast< char * >( strstr(data[2], "") );
| ^^

What strange strstr do you have that returns a "char const *"??
AFAIK it should return "char *"

| In insets/figinset.C, change include statement in line 35:
| 
|#include "signal.h"
| 
| (seems like csignal does not declare kill but signal.h does)

What about std::kill then.


| In insets/insetlatexaccent.h move ACCENT_TYPES to the public part;
| otherwise the corresponding .C file will not compile
| ("insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES
| is not accessible from file level.)

I still think this is strange, but it is the correct fix.

| In support/filetools.C, add cast in line 336:
| 
| int retval = putenv(const_cast< char * >(new
| string(envstr)->c_str()));

Since most putenv's don't take a "char *", but a "char const *" this fix
is not good.

| In support/lstrings.C, line 195:
| 
| Error: Could not find a match for std::count<>(const char*, const
| char*, const char).
| 
| I have no idea how to fix this. Does anybody have an idea what may be
| wrong???

This is fixed in cvs _very_ soon, I have the fix in my own tree.

Basically your compiler has the wrong prototype for count. (it is not
standard conforming).

| In support/lyxsum.C, add in line 21:
| 
|   using namespace std;  // shouldn't you do so in general???

no. And I don't like this fix either. We should almost never pull
entire namespaces into action. Much better to use

using std::foo; 

for each funciton foo from namespace std that we need.

| In bmtable, add the following lines below the include statements:
| 
|using std::free;
|using std::calloc;

As I said somewhere else the correct fix here is to compile bmtable
with a C compiler since it is really a C file. This can probably be
done quite easy.

Ok, I did this and will put this in cvs.


| In file chset.h, add:
| 
| #include 
| using std::pair;
| using std::make_pair;  // may also be put in chset.C

using declarations should always be made as local as possible.

| 1217: return make_pair(true, static_cast(cit -
| classlist.begin()));
| 1219: return make_pair(false, 0u);
| 1245: return make_pair(true, static_case< unsigned >( LYX_DUMMY_LAYOUT )
| );
| 1247: return 

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

 I just commited some fixes in cvs that should help. I'll comment on
 them below. BTW, what are the settings you used? Maximal fuss or
 normal operation? Somce warings are just CC complaining about its own
 C++ library, it seems...

Dear Jean-Marc,

today, I tried to recompile lyx-devel with SUN's Workshop C++ Compiler.
Here comes the latest status report. It would be very nice if you
checked in the patches (much) below in the cvs repository.

Besides, I still get the following warnings. I don't know whether they
indicate real problems but I get them even though I disabled even
standard warnings.

"figinset.C", line 2070: Warning: pflags hides InsetFig::pflags.
"insetinclude.h", line 132: Warning: InsetInclude::display hides the
virtual function Inset::display(bool).
"insetindex.h", line 77: Warning: InsetPrintIndex::display hides the
virtual function Inset::display(bool).
"insetloa.h", line 50: Warning: InsetLOA::display hides the virtual
function Inset::display(bool).
"insetlof.h", line 48: Warning: InsetLOF::display hides the virtual
function Inset::display(bool).
"insetlot.h", line 48: Warning: InsetLOT::display hides the virtual
function Inset::display(bool).
"insetref.h", line 78: Warning: InsetRef::display hides the virtual
function Inset::display(bool).
"insettoc.h", line 53: Warning: InsetTOC::display hides the virtual
function Inset::display(bool).
"inseturl.h", line 87: Warning: InsetUrl::display hides the virtual
function Inset::display(bool).
"insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
virtual function Inset::display(bool).
"BufferView.C", line 1257: Warning: work_area_width hides
BufferView::work_area_width.
"insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
virtual function Inset::display(bool).
"LaTeX.C", line 300: Warning: file hides LaTeX::file.
"LaTeX.C", line 373: Warning: file hides LaTeX::file.
"buffer.C", line 233: Warning: filename hides Buffer::filename.
"buffer.C", line 1178: Warning: filename hides Buffer::filename.
"buffer.C", line 1246: Warning: filename hides Buffer::filename.
"buffer.C", line 1571: Warning: filename hides Buffer::filename.
"buffer.C", line 2123: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2124: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2125: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2126: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2135: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2136: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2137: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2144: Warning: filename hides Buffer::filename.
"buffer.C", line 2727: Warning: filename hides Buffer::filename.
"lyx_gui.C", line 76: Warning: String literal converted to char* in
initialization.
"lyx_gui.C", line 77: Warning: String literal converted to char* in
initialization.
"lyx_gui.C", line 78: Warning: String literal converted to char* in
initialization.
...
"lyx_gui.C", line 95: Warning: String literal converted to char* in
initialization.
"text.C", line 709: Warning: paperwidth hides LyXText::paperwidth.
"text2.C", line 746: Warning: cursor hides LyXText::cursor.
"text2.C", line 774: Warning: cursor hides LyXText::cursor.
"text2.C", line 806: Warning: cursor hides LyXText::cursor.
"text2.C", line 3484: Warning: cursor hides LyXText::cursor.


Eagerly awaiting the next LyX release,

Michael

PS: Is it true that you provide your own string class? Which C++
compiler supports "pair" and algorithms but does not provide "string"? I
think you should take the string class for granted.

++

In mathed/math_symbol, add a cast in line 547:

char * sx = const_cast char * ( strstr(data[2], "") );
^ ^

++

In insets/figinset.C, change include statement in line 35:

   #include "signal.h"

(seems like csignal does not declare kill but signal.h does)

++

In insets/insetlatexaccent.h move ACCENT_TYPES to the public part;
otherwise the corresponding .C file will not compile
("insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES
is not accessible from file level.)

++

In support/filetools.C, add cast in line 336:

int retval = putenv(const_cast char * (new
string(envstr)-c_str()));

++

In support/lstrings.C, line 195:

Error: Could not find a match for std::count(const char*, const
char*, const char).

I have no idea how to fix this. Does anybody have an idea what may be
wrong???

THIS IS THE ONLY BUG I COULDN'T FIX ON MY OWN.

++

In support/lyxsum.C, add in line 21:

  using namespace std;  // shouldn't you do so in general???

++

In support/syscall.C, change include statement:

   #include 

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Hi,

our network had some problems right when I sent this email. I re-post
the message because it migh have gone lost.

Michael


Michael Schmitt wrote:
 
 Jean-Marc Lasgouttes wrote:
 
  I just commited some fixes in cvs that should help. I'll comment on
  them below. BTW, what are the settings you used? Maximal fuss or
  normal operation? Somce warings are just CC complaining about its own
  C++ library, it seems...
 
 Dear Jean-Marc,
 
 today, I tried to recompile lyx-devel with SUN's Workshop C++ Compiler.
 Here comes the latest status report. It would be very nice if you
 checked in the patches (much) below in the cvs repository.
 
 Besides, I still get the following warnings. I don't know whether they
 indicate real problems but I get them even though I disabled even
 standard warnings.
 
 "figinset.C", line 2070: Warning: pflags hides InsetFig::pflags.
 "insetinclude.h", line 132: Warning: InsetInclude::display hides the
 virtual function Inset::display(bool).
 "insetindex.h", line 77: Warning: InsetPrintIndex::display hides the
 virtual function Inset::display(bool).
 "insetloa.h", line 50: Warning: InsetLOA::display hides the virtual
 function Inset::display(bool).
 "insetlof.h", line 48: Warning: InsetLOF::display hides the virtual
 function Inset::display(bool).
 "insetlot.h", line 48: Warning: InsetLOT::display hides the virtual
 function Inset::display(bool).
 "insetref.h", line 78: Warning: InsetRef::display hides the virtual
 function Inset::display(bool).
 "insettoc.h", line 53: Warning: InsetTOC::display hides the virtual
 function Inset::display(bool).
 "inseturl.h", line 87: Warning: InsetUrl::display hides the virtual
 function Inset::display(bool).
 "insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
 virtual function Inset::display(bool).
 "BufferView.C", line 1257: Warning: work_area_width hides
 BufferView::work_area_width.
 "insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
 virtual function Inset::display(bool).
 "LaTeX.C", line 300: Warning: file hides LaTeX::file.
 "LaTeX.C", line 373: Warning: file hides LaTeX::file.
 "buffer.C", line 233: Warning: filename hides Buffer::filename.
 "buffer.C", line 1178: Warning: filename hides Buffer::filename.
 "buffer.C", line 1246: Warning: filename hides Buffer::filename.
 "buffer.C", line 1571: Warning: filename hides Buffer::filename.
 "buffer.C", line 2123: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2124: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2125: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2126: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2135: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2136: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2137: Warning: String literal converted to char* in
 initialization.
 "buffer.C", line 2144: Warning: filename hides Buffer::filename.
 "buffer.C", line 2727: Warning: filename hides Buffer::filename.
 "lyx_gui.C", line 76: Warning: String literal converted to char* in
 initialization.
 "lyx_gui.C", line 77: Warning: String literal converted to char* in
 initialization.
 "lyx_gui.C", line 78: Warning: String literal converted to char* in
 initialization.
 ...
 "lyx_gui.C", line 95: Warning: String literal converted to char* in
 initialization.
 "text.C", line 709: Warning: paperwidth hides LyXText::paperwidth.
 "text2.C", line 746: Warning: cursor hides LyXText::cursor.
 "text2.C", line 774: Warning: cursor hides LyXText::cursor.
 "text2.C", line 806: Warning: cursor hides LyXText::cursor.
 "text2.C", line 3484: Warning: cursor hides LyXText::cursor.
 
 Eagerly awaiting the next LyX release,
 
 Michael
 
 PS: Is it true that you provide your own string class? Which C++
 compiler supports "pair" and algorithms but does not provide "string"? I
 think you should take the string class for granted.
 
 ++
 
 In mathed/math_symbol, add a cast in line 547:
 
 char * sx = const_cast char * ( strstr(data[2], "") );
 ^ ^
 
 ++
 
 In insets/figinset.C, change include statement in line 35:
 
#include "signal.h"
 
 (seems like csignal does not declare kill but signal.h does)
 
 ++
 
 In insets/insetlatexaccent.h move ACCENT_TYPES to the public part;
 otherwise the corresponding .C file will not compile
 ("insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES
 is not accessible from file level.)
 
 ++
 
 In support/filetools.C, add cast in line 336:
 
 int retval = putenv(const_cast char * (new
 string(envstr)-c_str()));
 
 ++
 
 In support/lstrings.C, line 195:
 
 Error: Could not find a match for std::count(const char*, const
 char*, const char).
 
 I have no idea how to fix this. Does anybody have 

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

> I just commited some fixes in cvs that should help. I'll comment on
> them below. BTW, what are the settings you used? Maximal fuss or
> normal operation? Somce warings are just CC complaining about its own
> C++ library, it seems...

Dear Jean-Marc,

today, I tried to recompile lyx-devel with SUN's Workshop C++ Compiler.
Here comes the latest status report. It would be very nice if you
checked in the patches (much) below in the cvs repository.

Besides, I still get the following warnings. I don't know whether they
indicate real problems but I get them even though I disabled even
standard warnings.

"figinset.C", line 2070: Warning: pflags hides InsetFig::pflags.
"insetinclude.h", line 132: Warning: InsetInclude::display hides the
virtual function Inset::display(bool).
"insetindex.h", line 77: Warning: InsetPrintIndex::display hides the
virtual function Inset::display(bool).
"insetloa.h", line 50: Warning: InsetLOA::display hides the virtual
function Inset::display(bool).
"insetlof.h", line 48: Warning: InsetLOF::display hides the virtual
function Inset::display(bool).
"insetlot.h", line 48: Warning: InsetLOT::display hides the virtual
function Inset::display(bool).
"insetref.h", line 78: Warning: InsetRef::display hides the virtual
function Inset::display(bool).
"insettoc.h", line 53: Warning: InsetTOC::display hides the virtual
function Inset::display(bool).
"inseturl.h", line 87: Warning: InsetUrl::display hides the virtual
function Inset::display(bool).
"insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
virtual function Inset::display(bool).
"BufferView.C", line 1257: Warning: work_area_width hides
BufferView::work_area_width.
"insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
virtual function Inset::display(bool).
"LaTeX.C", line 300: Warning: file hides LaTeX::file.
"LaTeX.C", line 373: Warning: file hides LaTeX::file.
"buffer.C", line 233: Warning: filename hides Buffer::filename.
"buffer.C", line 1178: Warning: filename hides Buffer::filename.
"buffer.C", line 1246: Warning: filename hides Buffer::filename.
"buffer.C", line 1571: Warning: filename hides Buffer::filename.
"buffer.C", line 2123: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2124: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2125: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2126: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2135: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2136: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2137: Warning: String literal converted to char* in
initialization.
"buffer.C", line 2144: Warning: filename hides Buffer::filename.
"buffer.C", line 2727: Warning: filename hides Buffer::filename.
"lyx_gui.C", line 76: Warning: String literal converted to char* in
initialization.
"lyx_gui.C", line 77: Warning: String literal converted to char* in
initialization.
"lyx_gui.C", line 78: Warning: String literal converted to char* in
initialization.
...
"lyx_gui.C", line 95: Warning: String literal converted to char* in
initialization.
"text.C", line 709: Warning: paperwidth hides LyXText::paperwidth.
"text2.C", line 746: Warning: cursor hides LyXText::cursor.
"text2.C", line 774: Warning: cursor hides LyXText::cursor.
"text2.C", line 806: Warning: cursor hides LyXText::cursor.
"text2.C", line 3484: Warning: cursor hides LyXText::cursor.


Eagerly awaiting the next LyX release,

Michael

PS: Is it true that you provide your own string class? Which C++
compiler supports "pair" and algorithms but does not provide "string"? I
think you should take the string class for granted.

++

In mathed/math_symbol, add a cast in line 547:

char * sx = const_cast< char * >( strstr(data[2], "") );
^ ^

++

In insets/figinset.C, change include statement in line 35:

   #include "signal.h"

(seems like csignal does not declare kill but signal.h does)

++

In insets/insetlatexaccent.h move ACCENT_TYPES to the public part;
otherwise the corresponding .C file will not compile
("insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES
is not accessible from file level.)

++

In support/filetools.C, add cast in line 336:

int retval = putenv(const_cast< char * >(new
string(envstr)->c_str()));

++

In support/lstrings.C, line 195:

Error: Could not find a match for std::count<>(const char*, const
char*, const char).

I have no idea how to fix this. Does anybody have an idea what may be
wrong???

THIS IS THE ONLY BUG I COULDN'T FIX ON MY OWN.

++

In support/lyxsum.C, add in line 21:

  using namespace std;  // shouldn't you do so in general???

++

In support/syscall.C, change include statement:

  

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Hi,

our network had some problems right when I sent this email. I re-post
the message because it migh have gone lost.

Michael


Michael Schmitt wrote:
> 
> Jean-Marc Lasgouttes wrote:
> 
> > I just commited some fixes in cvs that should help. I'll comment on
> > them below. BTW, what are the settings you used? Maximal fuss or
> > normal operation? Somce warings are just CC complaining about its own
> > C++ library, it seems...
> 
> Dear Jean-Marc,
> 
> today, I tried to recompile lyx-devel with SUN's Workshop C++ Compiler.
> Here comes the latest status report. It would be very nice if you
> checked in the patches (much) below in the cvs repository.
> 
> Besides, I still get the following warnings. I don't know whether they
> indicate real problems but I get them even though I disabled even
> standard warnings.
> 
> "figinset.C", line 2070: Warning: pflags hides InsetFig::pflags.
> "insetinclude.h", line 132: Warning: InsetInclude::display hides the
> virtual function Inset::display(bool).
> "insetindex.h", line 77: Warning: InsetPrintIndex::display hides the
> virtual function Inset::display(bool).
> "insetloa.h", line 50: Warning: InsetLOA::display hides the virtual
> function Inset::display(bool).
> "insetlof.h", line 48: Warning: InsetLOF::display hides the virtual
> function Inset::display(bool).
> "insetlot.h", line 48: Warning: InsetLOT::display hides the virtual
> function Inset::display(bool).
> "insetref.h", line 78: Warning: InsetRef::display hides the virtual
> function Inset::display(bool).
> "insettoc.h", line 53: Warning: InsetTOC::display hides the virtual
> function Inset::display(bool).
> "inseturl.h", line 87: Warning: InsetUrl::display hides the virtual
> function Inset::display(bool).
> "insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
> virtual function Inset::display(bool).
> "BufferView.C", line 1257: Warning: work_area_width hides
> BufferView::work_area_width.
> "insets/insetbib.h", line 132: Warning: InsetBibtex::display hides the
> virtual function Inset::display(bool).
> "LaTeX.C", line 300: Warning: file hides LaTeX::file.
> "LaTeX.C", line 373: Warning: file hides LaTeX::file.
> "buffer.C", line 233: Warning: filename hides Buffer::filename.
> "buffer.C", line 1178: Warning: filename hides Buffer::filename.
> "buffer.C", line 1246: Warning: filename hides Buffer::filename.
> "buffer.C", line 1571: Warning: filename hides Buffer::filename.
> "buffer.C", line 2123: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2124: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2125: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2126: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2135: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2136: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2137: Warning: String literal converted to char* in
> initialization.
> "buffer.C", line 2144: Warning: filename hides Buffer::filename.
> "buffer.C", line 2727: Warning: filename hides Buffer::filename.
> "lyx_gui.C", line 76: Warning: String literal converted to char* in
> initialization.
> "lyx_gui.C", line 77: Warning: String literal converted to char* in
> initialization.
> "lyx_gui.C", line 78: Warning: String literal converted to char* in
> initialization.
> ...
> "lyx_gui.C", line 95: Warning: String literal converted to char* in
> initialization.
> "text.C", line 709: Warning: paperwidth hides LyXText::paperwidth.
> "text2.C", line 746: Warning: cursor hides LyXText::cursor.
> "text2.C", line 774: Warning: cursor hides LyXText::cursor.
> "text2.C", line 806: Warning: cursor hides LyXText::cursor.
> "text2.C", line 3484: Warning: cursor hides LyXText::cursor.
> 
> Eagerly awaiting the next LyX release,
> 
> Michael
> 
> PS: Is it true that you provide your own string class? Which C++
> compiler supports "pair" and algorithms but does not provide "string"? I
> think you should take the string class for granted.
> 
> ++
> 
> In mathed/math_symbol, add a cast in line 547:
> 
> char * sx = const_cast< char * >( strstr(data[2], "") );
> ^ ^
> 
> ++
> 
> In insets/figinset.C, change include statement in line 35:
> 
>#include "signal.h"
> 
> (seems like csignal does not declare kill but signal.h does)
> 
> ++
> 
> In insets/insetlatexaccent.h move ACCENT_TYPES to the public part;
> otherwise the corresponding .C file will not compile
> ("insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES
> is not accessible from file level.)
> 
> ++
> 
> In support/filetools.C, add cast in line 336:
> 
> int retval = putenv(const_cast< char * >(new
> string(envstr)->c_str()));
> 
> ++
> 
> In support/lstrings.C, line 195:
> 
> Error: 

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I
Lars already answered him to add a #include "support/LOstream.h" at
Lars the | beginning of debug.h. I think he is using STL string, and
Lars ostreams | are defined in lyxstring.h, so I did not see that I
Lars missed the header | in my last debug patch.

Lars I think iostream is required to includ ostream so I think
Lars LOstream.h is a bit wrong.

This error occurs _before_ DebugStream.h is included, so iostream has
not been read yet at this point. Have a look at debug.h and you'll see
what I mean (the two static members I added to Debug).

Lars I had some problems with L[IO]stream.h when trying out the gcu
Lars libstd++ libarary.

What kind of problems?

JMarc

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| Michael "insetlatexaccent.C", line 645: Error:
| Michael InsetLatexAccent::ACCENT_TYPES is not accessible from file
| Michael level.
| 
| This one is strange, as Lars said.

We can move the enum into public space.

| Michael "lstrings.C", line 178: Error: Could not find a match for
| Michael std::count(const char*, const char*, const char).
| 
| Don't know about that.

it is a wrong count in the C++ lib,

the correct one is

templateclass InputIterator, class T
typename iterator_traitsInputIterator::difference_type
  count(InputIterator first, InputIterator last, const T
value);

when the one used in this case is:

template class _InputIter, class _Tp, class _Size
void count(_InputIter __first, _InputIter __last, const _Tp __value, _Size __n);

perhaps we should have a check in configure for this?

| Michael "lyxsum.C", line 119: Error: "," expected instead of "*".
| Michael "lyxsum.C", line 120: Error: fp is not defined.
| 
| Maybe removing 'register' would help. Lars, why is this code so
| complicated? 

Complicated? (it is one of the simplest files we have.)
Ok, it got a bit more complicated when I added a standard c++ way of
doing it instead of using stdio.
the fstream disted with gcc does not have the needed readsome method.

| Michael "layout.C", line 1217: Error: Cannot use std::pairbool, int
| Michael to initialize std::pairbool, unsigned. "layout.C", line
| Michael 1219: Error: Cannot use std::pairbool, int to initialize
| Michael std::pairbool, unsigned.
| 
| Don't know.

This constructor prototype is missing from the C++ lib:

  template class _U1, class _U2
  pair(const pair_U1, _U2 __p) : first(__p.first),
  second(__p.second) {}

but we should be able to make the types in the pair be the same.

| Michael "spellchecker.C", line 340: Error: Using static_cast to
| Michael convert from char*[14] to char*const* not allowed.
| 
| Don't know. Maybe a const_cast instead of a static_cast?

Yes, const_cast looks more correct.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I
Lars> already answered him to add a #include "support/LOstream.h" at
Lars> the | beginning of debug.h. I think he is using STL string, and
Lars> ostreams | are defined in lyxstring.h, so I did not see that I
Lars> missed the header | in my last debug patch.

Lars> I think iostream is required to includ ostream so I think
Lars> LOstream.h is a bit wrong.

This error occurs _before_ DebugStream.h is included, so iostream has
not been read yet at this point. Have a look at debug.h and you'll see
what I mean (the two static members I added to Debug).

Lars> I had some problems with L[IO]stream.h when trying out the gcu
Lars> libstd++ libarary.

What kind of problems?

JMarc

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| Michael> "insetlatexaccent.C", line 645: Error:
| Michael> InsetLatexAccent::ACCENT_TYPES is not accessible from file
| Michael> level.
| 
| This one is strange, as Lars said.

We can move the enum into public space.

| Michael> "lstrings.C", line 178: Error: Could not find a match for
| Michael> std::count<>(const char*, const char*, const char).
| 
| Don't know about that.

it is a wrong count in the C++ lib,

the correct one is

template
typename iterator_traits::difference_type
  count(InputIterator first, InputIterator last, const T&
value);

when the one used in this case is:

template 
void count(_InputIter __first, _InputIter __last, const _Tp& __value, _Size& __n);

perhaps we should have a check in configure for this?

| Michael> "lyxsum.C", line 119: Error: "," expected instead of "*".
| Michael> "lyxsum.C", line 120: Error: fp is not defined.
| 
| Maybe removing 'register' would help. Lars, why is this code so
| complicated? 

Complicated? (it is one of the simplest files we have.)
Ok, it got a bit more complicated when I added a standard c++ way of
doing it instead of using stdio.
the fstream disted with gcc does not have the needed readsome method.

| Michael> "layout.C", line 1217: Error: Cannot use std::pair
| Michael> to initialize std::pair. "layout.C", line
| Michael> 1219: Error: Cannot use std::pair to initialize
| Michael> std::pair.
| 
| Don't know.

This constructor prototype is missing from the C++ lib:

  template 
  pair(const pair<_U1, _U2>& __p) : first(__p.first),
  second(__p.second) {}

but we should be able to make the types in the pair be the same.

| Michael> "spellchecker.C", line 340: Error: Using static_cast to
| Michael> convert from char*[14] to char*const* not allowed.
| 
| Don't know. Maybe a const_cast instead of a static_cast?

Yes, const_cast looks more correct.

Lgb

Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Hello,

today I tried to compile Lyx 1.1.3 with Sun's CC (C++ Workshop compiler
version 5.0) on Solaris 2.7. This compiler is said to comply to the ANSI
C++ standard. Unfortunately, I haven't been successful because of
several problems in the code. Could anybody please take a look at the
messages below? I only list the most important errors. There exists a
large number of warnings indicating, e.g. anachronisms in the C++ code.
If somebody is interested in a full listing of the compiler output
please do not hesitate to contact me.

Kind regards,

Michael

PS: Once I will be able to compile Lyx with Sun's Workshop compiler, I
will try to debug Lyx with the famous Purify run-time checker. One of my
students that has to write a long document with Lyx (I forced him to do
so :-) complains about a lot of crashes that seem to be related to the
usage of figures (especially subfigures) within a Lyx document. Purify
may help to detect the cause for these crashes (frankly speaking I am
not familiar with the Lyx nor do I have the time to fix bigger problems
on my own; I can only report problems)

+++

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/opt/local/include -I/usr/openwin/include +p
+w2 -compat=5 -g -c math_panel.C -o math_panel.o
"../../images/sqrt.xpm", line 2: Error: Multiple declaration for sqrt.
"math_panel.C", line 275: Error: Cannot return extern "C"
double(*)(double) from a function that should return char**.
"math_panel.C", line 301: Error: Formal argument 2 of type char** in
call to fl_set_pixmap_data(flobjs_*, char**) is being passed extern "C"
double(*)(double).

"figinset.C", line 257: Error: The function "kill" must have a
prototype.
"figinset.C", line 1727: Error: Unknown preprocessor directive."

"insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
not accessible from file level.

"filetools.C", line 325: Error: Formal argument 1 of type char* in call
to putenv(char*) is being passed const char*.

"lstrings.C", line 178: Error: Could not find a match for
std::count(const char*, const char*, const char).

"ImportNoweb.C", line 57: Error: Unknown preprocessor directive.

"LyXAction.C", line 614: Error: Unknown preprocessor directive.

"bmtable.C", line 46: Error: The function "calloc" must have a
prototype.
"bmtable.C", line 212: Error: The function "free" must have a prototype.

"support/lstrings.h", line 16: Error: Templates can only declare classes
or functions.
"support/lstrings.h", line 19: Error: size_t is not defined.
"support/lstrings.h", line 20: Error: "," expected instead of "const".
"support/lstrings.h", line 21: Error: A declaration was expected instead
of "while".
"support/lstrings.h", line 21: Error: ")" expected instead of "!=".
"support/lstrings.h", line 21: Error: Multiple declaration for count.
"support/lstrings.h", line 22: Error: A declaration was expected instead
of "return".
"support/lstrings.h", line 23: Error: A declaration was expected instead
of "}".

"layout.C", line 946: Error: Cannot use std::pairbool, int to
initialize std::pairbool, unsigned.

"lyx_cb.C", line 1116: Error: Unknown preprocessor directive.

"../src/lyx_main.C", line 139: Error: The function "signal" must have a
prototype.

"lyxfunc.C", line 391: Error: Unknown preprocessor directive.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

 Michael Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++
 Michael Workshop compiler version 5.0) on Solaris 2.7. This compiler
 Michael is said to comply to the ANSI C++ standard.
 
 Yes, we'd like to get LyX to compile there, but I do not have access to
 it.

Thank you very much for your quick response. I was afraid that you
consider my comments useless. If you like to I can recompile lyx from
time to time for you with Sun's CC. That's no big effort for me.

 First thing, could you get lyx 1.1.4pre1 and work from that? This
 would be much easier for us. Then send to the list the complete error
 log that you get.

OK, I downloaded this developer release. But certainly you won't like
the new compiler output. There seem to be many identical error messages,
mostly related to a missing ostream class (seems to be a namespace
problem (?)). Nevertheless, I attached the complete output to this mail.
I turned on all warnings and errors and requested full ANSI standard
conformance tests when running the compiler.

 I run purify on lyx from time to time, but since I do not know what to
 try, I do not find many things these days... Note that the figure code
 will be rewritten as soon as we can.

Nice to see that Purify is actually used to ensure software quality. I
wouldn't like to trust any piece of software that does not use a
run-time checker.

Happy bug fixing,

Michael

PS: Please contact me if I can do anything for you.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==
 compile_errors.gz

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/opt/local/include 
-I/usr/openwin/include +p +w2 -compat=5 -g -c formula.C -o formula.o
"../../src/debug.h", line 65: Error: ostream is not defined.
"../../src/debug.h", line 68: Error: ostream is not defined.  

Try to add 

using std::ostream; 

right after #include iostream in src/support/DebugStream.h

If that does not work I think your compiler is wrong.

Most of the other errors comes because of this.

Hard to the real problems in all the noise.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
Lars -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g
Lars -c formula.C -o formula.o "../../src/debug.h", line 65: Error:
Lars ostream is not defined. "../../src/debug.h", line 68: Error:
Lars ostream is not defined.

Lars Try to add

Lars using std::ostream;

Lars right after #include iostream in src/support/DebugStream.h

Lars If that does not work I think your compiler is wrong.

Lars Most of the other errors comes because of this.

I already answered him to add a #include "support/LOstream.h" at the
beginning of debug.h. I think he is using STL string, and ostreams
are defined in lyxstring.h, so I did not see that I missed the header
in my last debug patch.

JMarc

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

| "figinset.C", line 257: Error: The function "kill" must have a
| prototype.

In my docs "kill" is not an ANSI C function and should not really be
in namespace std, but it seems that CC has put it there.
Add a
using std::kill;
and file a bug report to SUN.

| "figinset.C", line 1727: Error: Unknown preprocessor directive."

I was pretty sure that unknown preprocessor directives should be
ignored, but since I cannot find a reference I might be wrong...
We should make sure to wrap all the #warning dircetives then.

| "insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
| not accessible from file level.

This is one error I don't really understand.
 
| "filetools.C", line 325: Error: Formal argument 1 of type char* in call
| to putenv(char*) is being passed const char*.

file a bug report to SUN.

| "lstrings.C", line 178: Error: Could not find a match for
| std::count(const char*, const char*, const char).

Missing prototype in CC's libraries.
Easy to work around.

| "bmtable.C", line 46: Error: The function "calloc" must have a
| prototype.
| "bmtable.C", line 212: Error: The function "free" must have a
| prototype.

bmtable should really be put in a _C_ library and compiled with a _C_
compilator.

| 
| "support/lstrings.h", line 16: Error: Templates can only declare classes
| or functions.
| "support/lstrings.h", line 19: Error: size_t is not defined.

using std::size_t;
should probably fix that.

| "layout.C", line 946: Error: Cannot use std::pairbool, int to
| initialize std::pairbool, unsigned.

missing prototype in CC's lib. file a buf report.
(we can fix this with a static_cast)

| "../src/lyx_main.C", line 139: Error: The function "signal" must have a
| prototype.

using std::signal;

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| I already answered him to add a #include "support/LOstream.h" at the
| beginning of debug.h. I think he is using STL string, and ostreams
| are defined in lyxstring.h, so I did not see that I missed the header
| in my last debug patch.

I think iostream is required to includ ostream so I think LOstream.h
is a bit wrong.

I had some problems with L[IO]stream.h when trying out the gcu
libstd++ libarary.

Lgb

Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Hello,

today I tried to compile Lyx 1.1.3 with Sun's CC (C++ Workshop compiler
version 5.0) on Solaris 2.7. This compiler is said to comply to the ANSI
C++ standard. Unfortunately, I haven't been successful because of
several problems in the code. Could anybody please take a look at the
messages below? I only list the most important errors. There exists a
large number of warnings indicating, e.g. anachronisms in the C++ code.
If somebody is interested in a full listing of the compiler output
please do not hesitate to contact me.

Kind regards,

Michael

PS: Once I will be able to compile Lyx with Sun's Workshop compiler, I
will try to debug Lyx with the famous Purify run-time checker. One of my
students that has to write a long document with Lyx (I forced him to do
so :-) complains about a lot of crashes that seem to be related to the
usage of figures (especially subfigures) within a Lyx document. Purify
may help to detect the cause for these crashes (frankly speaking I am
not familiar with the Lyx nor do I have the time to fix bigger problems
on my own; I can only report problems)

+++

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/opt/local/include -I/usr/openwin/include +p
+w2 -compat=5 -g -c math_panel.C -o math_panel.o
"../../images/sqrt.xpm", line 2: Error: Multiple declaration for sqrt.
"math_panel.C", line 275: Error: Cannot return extern "C"
double(*)(double) from a function that should return char**.
"math_panel.C", line 301: Error: Formal argument 2 of type char** in
call to fl_set_pixmap_data(flobjs_*, char**) is being passed extern "C"
double(*)(double).

"figinset.C", line 257: Error: The function "kill" must have a
prototype.
"figinset.C", line 1727: Error: Unknown preprocessor directive."

"insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
not accessible from file level.

"filetools.C", line 325: Error: Formal argument 1 of type char* in call
to putenv(char*) is being passed const char*.

"lstrings.C", line 178: Error: Could not find a match for
std::count<>(const char*, const char*, const char).

"ImportNoweb.C", line 57: Error: Unknown preprocessor directive.

"LyXAction.C", line 614: Error: Unknown preprocessor directive.

"bmtable.C", line 46: Error: The function "calloc" must have a
prototype.
"bmtable.C", line 212: Error: The function "free" must have a prototype.

"support/lstrings.h", line 16: Error: Templates can only declare classes
or functions.
"support/lstrings.h", line 19: Error: size_t is not defined.
"support/lstrings.h", line 20: Error: "," expected instead of "const".
"support/lstrings.h", line 21: Error: A declaration was expected instead
of "while".
"support/lstrings.h", line 21: Error: ")" expected instead of "!=".
"support/lstrings.h", line 21: Error: Multiple declaration for count.
"support/lstrings.h", line 22: Error: A declaration was expected instead
of "return".
"support/lstrings.h", line 23: Error: A declaration was expected instead
of "}".

"layout.C", line 946: Error: Cannot use std::pair to
initialize std::pair.

"lyx_cb.C", line 1116: Error: Unknown preprocessor directive.

"../src/lyx_main.C", line 139: Error: The function "signal" must have a
prototype.

"lyxfunc.C", line 391: Error: Unknown preprocessor directive.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Michael Schmitt]

Jean-Marc Lasgouttes wrote:

> Michael> Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++
> Michael> Workshop compiler version 5.0) on Solaris 2.7. This compiler
> Michael> is said to comply to the ANSI C++ standard.
> 
> Yes, we'd like to get LyX to compile there, but I do not have access to
> it.

Thank you very much for your quick response. I was afraid that you
consider my comments useless. If you like to I can recompile lyx from
time to time for you with Sun's CC. That's no big effort for me.

> First thing, could you get lyx 1.1.4pre1 and work from that? This
> would be much easier for us. Then send to the list the complete error
> log that you get.

OK, I downloaded this developer release. But certainly you won't like
the new compiler output. There seem to be many identical error messages,
mostly related to a missing ostream class (seems to be a namespace
problem (?)). Nevertheless, I attached the complete output to this mail.
I turned on all warnings and errors and requested full ANSI standard
conformance tests when running the compiler.

> I run purify on lyx from time to time, but since I do not know what to
> try, I do not find many things these days... Note that the figure code
> will be rewritten as soon as we can.

Nice to see that Purify is actually used to ensure software quality. I
wouldn't like to trust any piece of software that does not use a
run-time checker.

Happy bug fixing,

Michael

PS: Please contact me if I can do anything for you.

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==
 compile_errors.gz

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/opt/local/include 
-I/usr/openwin/include +p +w2 -compat=5 -g -c formula.C -o formula.o
"../../src/debug.h", line 65: Error: ostream is not defined.
"../../src/debug.h", line 68: Error: ostream is not defined.  

Try to add 

using std::ostream; 

right after #include  in src/support/DebugStream.h

If that does not work I think your compiler is wrong.

Most of the other errors comes because of this.

Hard to the real problems in all the noise.

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
Lars> -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g
Lars> -c formula.C -o formula.o "../../src/debug.h", line 65: Error:
Lars> ostream is not defined. "../../src/debug.h", line 68: Error:
Lars> ostream is not defined.

Lars> Try to add

Lars> using std::ostream;

Lars> right after #include  in src/support/DebugStream.h

Lars> If that does not work I think your compiler is wrong.

Lars> Most of the other errors comes because of this.

I already answered him to add a #include "support/LOstream.h" at the
beginning of debug.h. I think he is using STL string, and ostreams
are defined in lyxstring.h, so I did not see that I missed the header
in my last debug patch.

JMarc

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| "figinset.C", line 257: Error: The function "kill" must have a
| prototype.

In my docs "kill" is not an ANSI C function and should not really be
in namespace std, but it seems that CC has put it there.
Add a
using std::kill;
and file a bug report to SUN.

| "figinset.C", line 1727: Error: Unknown preprocessor directive."

I was pretty sure that unknown preprocessor directives should be
ignored, but since I cannot find a reference I might be wrong...
We should make sure to wrap all the #warning dircetives then.

| "insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is
| not accessible from file level.

This is one error I don't really understand.
 
| "filetools.C", line 325: Error: Formal argument 1 of type char* in call
| to putenv(char*) is being passed const char*.

file a bug report to SUN.

| "lstrings.C", line 178: Error: Could not find a match for
| std::count<>(const char*, const char*, const char).

Missing prototype in CC's libraries.
Easy to work around.

| "bmtable.C", line 46: Error: The function "calloc" must have a
| prototype.
| "bmtable.C", line 212: Error: The function "free" must have a
| prototype.

bmtable should really be put in a _C_ library and compiled with a _C_
compilator.

| 
| "support/lstrings.h", line 16: Error: Templates can only declare classes
| or functions.
| "support/lstrings.h", line 19: Error: size_t is not defined.

using std::size_t;
should probably fix that.

| "layout.C", line 946: Error: Cannot use std::pair to
| initialize std::pair.

missing prototype in CC's lib. file a buf report.
(we can fix this with a static_cast)

| "../src/lyx_main.C", line 139: Error: The function "signal" must have a
| prototype.

using std::signal;

Lgb

Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| I already answered him to add a #include "support/LOstream.h" at the
| beginning of debug.h. I think he is using STL string, and ostreams
| are defined in lyxstring.h, so I did not see that I missed the header
| in my last debug patch.

I think iostream is required to includ ostream so I think LOstream.h
is a bit wrong.

I had some problems with L[IO]stream.h when trying out the gcu
libstd++ libarary.

Lgb