SCO experiences

SCO experiences

[Bill Walker]

This is just a report mentioning some experiences with SCO OSR 5.0.2 and 5.0.4
and the 970929 egcs compiler.  These experiences are good for anecdotes,
but little else.


Experience 0:

I had trouble compiling it at first, but with a suggestion from Robert it
compiled out of the box.  Thanks Robert!

Experience 1:

I used the new compiler to build emacs 20.1, just to see what would happen.
It compiled fine, but produced a code file (ELF) about 500K larger than
970907 does.  I don't know why, yet.

Experience 2:

I also used the new g77 to compile NEC, an antenna modeling program
which consists of about 10,000 lines (!) of FORTRAN.  That also works
fine, and produces output that is no different than several previous
compilers.  The output of such a FORTRAN program, under different compilers,
almost always produces some differences in the last few decimal places, but
that didn't happen here.  

Experience 3:

I found that the following (bad) usage of command line switches would dump
core:   (it was in a makefile)
 
	gcc -s -c file1.c
        gcc -s -c file2.c
        gcc -s file1.o file2.o  <-- dumps core here

When I remade the makefile to do this:

	gcc  -c file1.c
        gcc  -c file2.c
        gcc -s file1.o file2.o 

it worked fine.


Experience 4:

Under g++, I found something I think should work, but doesn't under any
compiler I have ever found, including this one.

Suppose I wish to create a template, say of an array:

	template.h <--- contains the template class definition
        template.cc <-- contains "generic" code 
        main.cc <-- "fills in the blank type" and instantiates the template

	main.cc #includes template.h, and template.cc #includes template.h

The compile will fail.  I really don't believe it should.  

	If I build another file like this:

		mess.cc:

                     #include "template.h"
                     #include "templace.cc"
                     #include "main.cc"

	and compile mess.cc with "g++ mess.cc", the thing works fine.

Not being enamoured with C++ as a language, I have not learned enough about
the nooks and cranies of the language  to say with authority that there
is something wrong here, but it clearly goes against the grain a bit.


Experience 5:

	The egcs project seems to be a useful one, and the dedicated folks
involved seem both pleasant and highly competent.  I am really glad to
see this kind of talent and interaction on such an important project.

	Heartfelt congratulations to the entire team, and I encourage you
to keep up the wonderful work you have begun.

73 de Bill W5GFE



-- 
Bill Walker Ph.D.
Chairman, Dept. of Computer Science
East Central University
Ada, Oklahoma 74820-6899

e-mail:  bw@cs.ecok.edu 
phone:   405 332 8000 ext. 594
FAX:     405 332 4616

Re: SCO experiences

[Robert Lipe]

> This is just a report mentioning some experiences with SCO OSR 5.0.2 and 5.0.4
> and the 970929 egcs compiler.  These experiences are good for anecdotes,

> I had trouble compiling it at first, but with a suggestion from Robert it
> compiled out of the box.  Thanks Robert!

You're welcome.

> I used the new compiler to build emacs 20.1, just to see what would happen.
> It compiled fine, but produced a code file (ELF) about 500K larger than
> 970907 does.  I don't know why, yet.

My money is on exceptions.   Compile with -fno-exceptions and see if 
it shrinks.

> I found that the following (bad) usage of command line switches would dump
> core:   (it was in a makefile)
>  
> 	gcc -s -c file1.c
>         gcc -s -c file2.c
>         gcc -s file1.o file2.o  <-- dumps core here
> 
> When I remade the makefile to do this:
> 
> 	gcc  -c file1.c
>         gcc  -c file2.c
>         gcc -s file1.o file2.o 
> 
> it worked fine.

Stripping .o's before handing them to the linker can't be a good plan.
It's not actually gcc that drops core.   It's ld/collect2.   Stick a 
debugger in it and see if you can give better hints.

Yes, I really need to go build a current gdb...

> 	The egcs project seems to be a useful one, and the dedicated folks
> involved seem both pleasant and highly competent.  I am really glad to
> see this kind of talent and interaction on such an important project.
> 
> 	Heartfelt congratulations to the entire team, and I encourage you
> to keep up the wonderful work you have begun.

I, too, am amazed at the speed things are moving on this list.

RJL

Re: SCO experiences

[Horst von Brand]

"Bill Walker" <bw@student.ecok.edu> said:
> Experience 1:
> 
> I used the new compiler to build emacs 20.1, just to see what would happen.
> It compiled fine, but produced a code file (ELF) about 500K larger than
> 970907 does.  I don't know why, yet.

Did you use -fno-exceptions? The (totally useless to C) exception handling
management makes executables _way_ bigger.

Try emacs-20.2 (20.1 gets zombies when trying to go to another MH folder;
20.2 cures that)

> Experience 5:
> 
> 	The egcs project seems to be a useful one, and the dedicated folks
> involved seem both pleasant and highly competent.  I am really glad to
> see this kind of talent and interaction on such an important project.
> 
> 	Heartfelt congratulations to the entire team, and I encourage you
> to keep up the wonderful work you have begun.

Seconded.
--
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: SCO experiences

[J. Kean Johnston]

On Fri, 3 Oct 1997, Bill Walker wrote:

> Experience 3:
> 
> I found that the following (bad) usage of command line switches would dump
> core:   (it was in a makefile)
>  
> 	gcc -s -c file1.c
>         gcc -s -c file2.c
>         gcc -s file1.o file2.o  <-- dumps core here
> 
> When I remade the makefile to do this:
> 
> 	gcc  -c file1.c
>         gcc  -c file2.c
>         gcc -s file1.o file2.o 
> 

If you tried this on 5.0.4, I am not surprised. It depends on the size of
file1.o and file2.o, but there is a known (but currently unfixed) problem
with the SCO linker which causes -s to make it dump core. It is sporadic,
which makes it a bitch to track down. If you have a repeatable, small test
case which exhibits the problem, I'd welcome it so that I can fix the
linker.

As to your comment about size of Emacs, what I suggest you do is this:

a) Compile with -fno-exceptions
b) after building temacs, do a :
   strip temacs; mcs -d temacs

Do this with both compilers. If 970929 is still 500K larger, we have a
real problem. If not ... its probably the exception handling code
that increased the size of your executable. Just a guess, but I'd be
interested in the outcome. I'd do it myself if real work didnt prevent
me from doing so :-)

JKJ

Re: SCO experiences

[J. Kean Johnston]

On Fri, 3 Oct 1997, Robert Lipe wrote:

> Stripping .o's before handing them to the linker can't be a good plan.
> It's not actually gcc that drops core.   It's ld/collect2.   Stick a 
> debugger in it and see if you can give better hints.
I believe this is incorrect. The SCO linker dumps core and collect2
simply reports the failure. If you use the GCC 2.8 snapshots (which
dont use collect2 on SCO) the same problem will occur. Even the native
compiler does a nasty like this sometimes. It is the linker at fault
not egcs.

JKJ

Re: SCO experiences

[Jason Merrill]

>>>>> Bill Walker <bw@student.ecok.edu> writes:

> Experience 4:

> Under g++, I found something I think should work, but doesn't under any
> compiler I have ever found, including this one.

> Suppose I wish to create a template, say of an array:

> 	template.h <--- contains the template class definition
>         template.cc <-- contains "generic" code 
>         main.cc <-- "fills in the blank type" and instantiates the template

> 	main.cc #includes template.h, and template.cc #includes template.h

> The compile will fail.  I really don't believe it should.  

g++ doesn't support separate compilation of templates.

Jason