🚀 go-pugleaf

>>jkh@meepmeep.pcs.com (Jordan K. Hubbard) writes:
>----^
>    sehr niedlicher Name !!

Danke, aber es ist nicht mein Fehler! Es ist auch Quatsch, weil unsere
Maschine nicht so schnell ist wie der Roadrunner. Mehr wie Wily (stuertzt
oefters ab).

>   Also zuerst einmal: Grossartig, Bravo , Toll, (endlich..)

Furtz.. Ruelps.. Kotz.. Ja ja.. :-)

>	Und genau da liegt das Problem: Sun-3 kompatibel bedeutet
>	ja wohl, dass die Object-Files im BSD-Format mit dbx-Debuggerinfos
>	vorliegen, der PCS-cc aber COFF erzeugt. Ergo sind die Objects nicht
>	miteinander verwendbar, so dass einige Libraries ebenfalls mit dem 

Stimmt. Aber, aechtz... Ok, Zeit fuer Englisch! 

Sun3 compatability was not the point of the exercise, though this was
an interesting side-effect. The main problem is that PCS cc has no assembler
whatsoever and goes directly to object code. This might have seemed like a
good idea at the time, but it forced us to use GAS which does not support COFF
directly. We solve the library problem by distributing all-new libraries
with the GCC compiler (I am sorry that we forgot to mention this important
fact in our original article). The R4 X Windows release will include GCC
libraries for all the X libs as well. This will actually be very easy for
us since we now use only gcc internally (supporting libaries for the original
cc may be a small problem, however.. :-).

>	aehnlich erzeugen? Weiter gefragt: Welche a.out-Format 
>	erzeugt der GNU-ld, ist es das alte V.2/07 von den 16bit-9200 
>	CADMUSsen oder ist es das ominoese 'encapsulated COFF' ?

Encapsulated COFF. This is not wonderful, but it does have a very large
advantage when using gdb on large executables. Gdb must load *all* symbols
from a COFF file before starting up which can take up to 5-10 minutes
for a really large (>3MB) executable like the X color server, or Kyoto Common
Lisp. With Encapsulated COFF, the symbol information is in DBX format
which can be loaded by gdb "incrementally" (e.g. as needed). This makes
startup time about 20 times faster. Our server developers would have gone
insane about 3 months ago if it hadn't been for this feature (some might
rightly point out that they're already insane, but this is beside the point).

>	Kurzum, zwei verschiedene Bibliothekssaetze auf dem Rechner zu haben
>	halte ich nicht fuer so ideal. Ich persoenlich kaempfe naemlich seit 
>	mehreren Wochen an einer Portierung von gcc und g++ auf eine 
>	Nixdorf Targon31 (gcc laeuft, g++ ist noch nicht perfekt). Da es

The solution is quite simple: Don't use the original cc at all and remove
all the old COFF libraries! This is what I have done on my home machine
and it works fine. I have yet to find a program (that isn't broken) that
won't compile under gcc but will under cc. I've also re-written all the
object-format-specific routines in GNU and KCL that need to directly read
or write object files (like KCL's fasload() and faslink() or GNU emacs's
unexec()) to use COFF encapsulation, so there's no problem there either.
About the only thing we have yet to compile under gcc is the UNIX kernel
itself, and we're working on that right now.

Right now, to sumarize it all, what you'll get from us on the GCC tape
is:

GCC 1.37.1
G++ 1.37.1 (new) + libg++ 1.37

GAS 1.35 + GLD and all the binutils (size, strip, ar, nm, etc..), with a few
bugs fixed, for Coff encapsulation.

GDB 3.5 for COFF Encapsulated binaries.

All new system libraries. Possibly all new X (R3) libraries as well, I have
to check what out licensing policy is with this. If it's not a problem,
we'll include them too.

Documentation in German (there's already plenty in English).

>				Weiter so, PCS !

We try...

			Viele Gruesse,

				Jordan Hubbard
--
			PCS Computer Systeme GmbH, Munich, West Germany
	UUCP:		pyramid!pcsbst!jkh jkh@meepmeep.pcs.com
	EUNET:		unido!pcsbst!jkh
	ARPA:		jkh@violet.berkeley.edu or hubbard@decwrl.dec.com