HDTenEightyP/NetNews huggingface dataset:
From: sm@cvedc.prime.com
Subject: problem in protoize, v2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 09:04:39 GMT

The following code can not be converted by protoize:

void constant(a, b)
int a;
char *b;
{
	return;
}

Newsgroups: gnu.gcc.bug
From: zoo@cygnus.com (david d `zoo' zuhn)
Subject: Re: HPUX and -g: when?
Organization: Cygnus Support -- +1 415 322 3816
Distribution: gnu
Date: Fri, 11 Sep 1992 05:00:17 GMT

Except that by saying HP9000, you haven't given us any useful information,
other than that it's an HP unix box, as opposed to the HP3000, which runs
the proprietary HP OS, whose name I can't recall.

The 9000/300's and /400's are 68k based.

The 9000/700's and /800's are HPPA based.

  david d 'zoo' zuhn |  
    cygnus support   |   I'm not lost, I just don't care where I'm going....
    zoo@cygnus.com   |       
 

Newsgroups: gnu.gcc.bug
From: tatsumi@elelab.nsc.co.JP (Tetsu Tatsumi)
Subject: g++ Internal compile error
Organization: Computer Systems Lab., Electronics Research Labs., Nippon Steel
Distribution: gnu
Date: Mon, 7 Sep 1992 08:47:56 GMT

  g++ 2.2.2 on SunOS 4.1.2 sais

    /usrx/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

for the file following (g++ -c file.c).
--------------------------------------------------------------------------
class A {
	int	i;	// not necessary
  public:
	static A	a1;
	A();
};

class	B {
	A	a2;
  public:
	B();
};

B::B()
{
	a2 = A::a1;
}
--------------------------------------------------------------------------

     /*------------------------------*--------------------------------/
    /   tatsumi@elelab.nsc.co.jp    /    Nippon Steel Corporation    /
   /-------------------------------*-------------------------------*/

Newsgroups: gnu.gcc.bug
From: fpb@ittc.wec.COM (Frank P. Bresz)
Subject: Possible Problem with -ansi vs -fno-builtin
Organization: Westinghouse, ITTC, Pgh, PA.
Distribution: gnu
Date: Tue, 8 Sep 1992 20:33:14 GMT

GCC version 2.2.2 just built from UUnet sources, On a Sun4 SunOS 4.1.1 I
noticed the following, minor problem, which is of course because sun has
old style <stdlib.h> but there does appear to be some problem with switches
that I am not good enough with gcc yet to figure out.

According to the man page

     -fno-builtin
          (Ignored for C++.) Don't  recognize  non-ANSI  built-in
          functions.   `-ansi'  also  has this effect. Currently,
          the only function affected is alloca.

	It would seem that it also affects abort and exit.

fpb(kkl)@ittc:libw_gp 374==>cat f.c
#include <stdlib.h>

fpb(kkl)@ittc:libw_gp 375==>gcc -c f.c
In file included from f.c:1:
/usr/include/stdlib.h:18: conflicting types for `abort'
<built-in>:0: previous declaration of `abort'
/usr/include/stdlib.h:26: conflicting types for `exit'
<built-in>:0: previous declaration of `exit'

fpb(kkl)@ittc:libw_gp 376==>gcc -ansi -c f.c
In file included from f.c:1:
/usr/include/stdlib.h:18: conflicting types for `abort'
<built-in>:0: previous declaration of `abort'
/usr/include/stdlib.h:26: conflicting types for `exit'
<built-in>:0: previous declaration of `exit'

fpb(kkl)@ittc:libw_gp 377==>gcc -fno-builtin -c f.c

	I care not that gcc without any switches complains about this (I
agree it should) since it points me at nonsensical (not doing anything ANSI
in the standard .h files) things Sun has done.  Nor do I mind that I needed
to type -fno-builtin to get it to work (I can live with this).  The only
minor problem I have is that it claims that -ansi should also have this
affect and as you can see from the above it doesn't.  No big deal just
thought I'd let you know.

					Frank P. Bresz }*{
					ITTC Network Administrator

Newsgroups: gnu.gcc.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Tautological assertion in cp-decl.c
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sat, 5 Sep 1992 23:47:35 GMT

When compiling gcc, I was warned that a test on line 10584 of cp-decl.c was
always 1 due to the range of the type.  The line is:

	assert (current_binding_level->n_incomplete >= 0);

And, indeed, the n_incomplete field of binding_level is of type unsigned
short, so this assertion doesn't do anything useful.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.gcc.bug
From: kewley@cns.caltech.edu (David T. Kewley)
Subject: fixincludes problem
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 04:21:24 GMT

When installing gcc 2.2.2, fixincludes did not fix sys/stdtypes.h.  (I found
this out after tracing back from a failure to compile main.c while installing
gdb 4.6.)  fixincludes should have put some #ifndef/#define/#endif around
definitions of size_t, ptrdiff_t, and wchar_t.  I believe that the following
sequence occurred when fixincludes tried to fix stdtypes.h:

1) it successfully copied it
2) it unsuccessfully tried to edit it (with ex)
3) it did a cmp, and found no differences (because ex made no changes, although
     it should have)
4) it removed the copy

I'm not familiar with ex, so don't know why it failed (if it did, as I believe).

I ended up editing a copy of stdtypes.h by hand, so I should be all set (I have
since successfully compiled gdb's main.c).  But I thought I'd pass this on in
case the powers that be want to check it out, or in case anyone else has seen
this.

(I'm running on a Sparc.)

David Kewley
kewley@cns.caltech.edu

P.S. If you reply, please send mail; I don't read the newsgroup.

Newsgroups: gnu.gcc.bug
From: axel@thor.informatik.uni-osnabrueck.de (Axel Schreiner)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 10:06:43 GMT

Subject: gcc-2.2.2 include/stddef.h for Mach/386

Mach/386 defines size_t in <sys/types.h> to be long. sorry.
The file is protected by _SYS_TYPES_H_ but size_t alone is not.

To fix, you need to conditionalize size_t with (e.g.) _GCC_SIZE_T
in <sys/types.h> and you need to fix gcc's stddef.h to define as long
ifdef MACH and i386.


Newsgroups: gnu.gcc.help
From: phil@news.ccutah.EDU (Phillip Neiswanger)
Subject: Newbie Question...
Organization: University of Utah Computer Center
Distribution: gnu
Date: Sat, 12 Sep 1992 06:27:43 GMT

Hi,

I don't think this is a bug so I'll post here.  I have installed gcc 2.2.2
on my sun system, but whenever my code includes stdlib.h gcc chokes on
'abort' and 'exit' functions.  Gcc reports "conflicting types for built-in
function 'abort'" for the function abort.  The same for the function exit.
After running 'install-fixincludes' the same bunch of errors come up.  I 
have configured the system with the command 'configure sun4'.

What I would like to know is how to get rid of this problem.  Do I actually
need to edit the system files in order to get gcc to quit griping?  Is there
some step I've missed?  For now I've hacked the c-decl.c and other files so
that abort and exit are int functions, but I'd like to return these files
to their original state.

Thanks for your time.

				CYA
				phil
				email:	phil@csulx.weber.edu
					phil@icarus.weber.edu

Newsgroups: gnu.gcc.help
From: tab@piis10.joanneum.ac.at (Behnam TABATABAI)
Subject: Prototypes for printf, ...
Organization: Joanneum Research, Graz, Austria
X-Newsreader: Tin 1.1 PL5
Date: Wed, 9 Sep 92 07:38:54 GMT

Hi gcc-users!

Using gcc, version 2.2.2 on VAX/VMS I am missing the prototypes for
printf, fprintf, sprintf, scanf, fscanf and sscanf. I looked for these
prototypes in GNU_CC_INCLUDE:[000000...]*.H, but couldn't find anything.

One of the reasons I'm using GCC is to check whether all functions are
prototyped and I get a lot of warnings for implicit declaration of
`printf', `fprintf', etc which should be defined in stdio.h.

Does anybody have an idea? Thanks in advance!
Behnam

--
Behnam Tabatabai                  | email: tab@piis10.joanneum.ac.at (internet)
Institute for Information Systems |        tabatabai@joanneum.ada.at (X.400)
Joanneum Research, Graz, Austria  | tel:   (++43/316) 8020 - 241
From: juan@noyles.pha.pa.us (Juan J. E. T. Noyles)
Newsgroups: gnu.gcc.help
Subject: GCC Docs: need clear text!
Distribution: world
Date: Sat, 05 Sep 92 18:43:18 GMT
Organization: The Noyles OS/2 Platform

Is there any place I can get the GCC docs in plain text?

Having to learn a whole new language just to read documentation or print it out is ...
unreasonable comes to mind...

--
Has anyone seen my sanity?				Juan@Noyles.pha.pa.us
From: fredr@raven.bu.edu (Fred Richardson)
Newsgroups: gnu.gcc.help
Subject: GNU C library
Date: 11 Sep 92 04:21:40 GMT
Distribution: gnu
Organization: I can do that too !!!

I was wondering if there are any liabilities using the GNU C library. I'm
currently linking to the standard C library available on a SPARC II.  The
software I'm developing requires a large amount of floating point
arithmatic.  I thought it would be nice to have a complete set of ANSI
headers and what not.

		FRED

Newsgroups: gnu.gcc.help
From: old@sunbim.be (Olivier Dubois)
Subject: C header on SunOS 4.1.1
Keywords: C header on Sun
Reply-To: old@sunbim.be
Organization: Sun Microsystems
Date: Mon, 7 Sep 92 10:57:36 GMT

Hello,

I'am far from happy of the status of C header files on SunOS 4.1.x. I know it is not 
GCC maintainer responsability but they are quite ugly, far from ansi C and POSIX
confirmant. I would like to ansify a quite big software (an X.400 X11 based UA, 
several hundred Klines). Protoize is quite helpfull while not suited to the handling of a
 software disributed in a set of directory. 

The problem is that with the -g option (create definition for implicitly called 
external functions) a lot of specifier for standard library function are created
even is the correct include files are specified. Unfortunately, the compilation choke 
on some of these extra declarations.

I came to my question: Does someone achieve to obtain a correct (POSIX and ANSI compliant )
set of files for gcc ? I tried fixinclude but it can't generate some of the information that should 
in standard include files. The Sun's unbundled C headers are also often violating
the standards.  Until this, we will have to stay with old C.

By the way GCC is a fabulous compiler.


Olivier Dubois,
old@sunbim.be
c=BE;A=RTT;P=BIM;O=HORIZON;S=Dubois;G=Olivier
From: hight@sri.com
Newsgroups: gnu.gcc.help
Subject: latest gcc version
Date: 11 Sep 92 23:03:43 GMT
Organization: SRI International, Menlo Park, CA


Anyone care to elaborate on what is the considered the latest
"reliable" gcc release?  I see in the README for 2.2.2 that it is
considered a beta test release, and I'm somewhat concerned with that.
We've been using 1.37.1 for quite a while on sparcs, and it's high
time to upgrade.

I'm also generally interested in the issue of linking Sun-cc compiled
(the free cc) files with gnu-cc compiled files.  I was under the
assumption that this is expected to work, and if it doesn't, it's a
bug.  Am I wrong?  Indeed, it is a problem with return-values with
mixing 1.37.1 with Sun-cc code that has prompted us to look into a
newer gcc version.
-- 
John Hight, SRI International	hight@sri.com	415-859-4279
Newsgroups: gnu.gcc.help,comp.os.msdos.programmer
From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
Subject: Re: djgpp 2.2.2 Q's: mouse/svga/assembler/bios
Organization: University of Illinois at Urbana
Distribution: gnu, comp
Date: Mon, 7 Sep 1992 18:24:08 GMT

     1. I think this is about the only place I've seen DJGPP problems.

     2. Why are you worrying about the palette? There are routines built
	in for setting the pallette in DJGPP.  GrSetColor or something.
	Check out the <graphics.h> file.

     3. Why are you worrying about the mouse support? There are routines
	built into for using the mouse in DJGPP.  Check out the file 
	<mouse.h>.

     4. Interrupts--- Who knows? I think you need to put them into the go32
	code-- not your program code.  I'm trying to re-write the keyboard
	interrupt as we speak, but right now I'm reading the Intel 386
	Programmer's Ref Manual trying to figure out the difference 
	between exceptions and interrupts, and why there's no code in
	exphndlr.c to handle int 9h. But, someday, I'll figure it out.

     5. The assembly notation: Here's one thing I found out:

               8(%esi)      <==>  [8+esi]
	       4(%esi,2)    <==>  [4+esi*2]    (I think)
	       7(%esi,%edi) <==>  [7+esi+edi]  (I think)



      I have to say this: I have 3 compilers on my computer-- MSC7, BC3,
      and DJGPP.  If you go by looks and packaging, MSC7 and BC3 are the
      better compilers.  If you go by performance, power, the source
      code to the libraries, the linear 1-meg SVGA memory, there is NOTHING
      that beats DJGPP... The compiler that made me realize why I bought a
      386 intead of a 286.  I actually only keep BC3 on my hard disk only to 
      recompile my attempts at adding keyboard interrupts to GO32 !!
      A good job by the author !!!!

-- 
------------------------------------------------------------------------
 John A. Slagel     "My old man used to tell me, before he left this
 j-slagel1@uiuc.edu  shitty world, never chase buses or women- you
                     always get left behind." -The Marlboro Man
From: as7l+@andrew.cmu.edu (Andrew B Stellman)
Newsgroups: gnu.gcc.help
Subject: Re: GCC for msdos
Date: 15 Sep 92 18:12:24 GMT
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

GCC for MSDOS can be download via anonymous FTP from these sights:

    wuarchive.wustl.edu
    garbo.uwasa.fi
    msdos.archive.umich.edu

and several others. It should be under a directory djgpp/ ...

Andy
<as7l@andrew.cmu.edu>
From: naraht@drycas.club.cc.cmu.edu (Randolph J. Finder)
Newsgroups: gnu.gcc.help
Subject: GCC for SCO needed
Date: 11 Sep 92 21:21:17 GMT
Organization: Carnegie Mellon Computer Club

I need gcc compiled for the "sco-*-386". I understand that it requires special functions and that simply running the install runs into problems with one of the functions just running forever.

Can someone either give me the FTP site for an already compiled copy of GCC
for the SCO or advice on comiling it there? (Prefereably the first)

Randy Finder

(naraht@drycas.club.cc.cmu.edu)	| Leadership,Friendship, and Service
(vri_rjfin@dmis.ha.osd.mil)	|          Alpha Phi Omega
(tnc!m0039@uunet.uu.net)	| National (Co-ed) Service Fraternity
"Service to others is the rent that we pay for living on the planet"(quote?)
Newsgroups: gnu.gcc.help
From: lisa@us-es.sel.de (Lisa Goulet)
Subject: Re: gcc-2.2.2 on HPUX
Followup-To: gcc-2.2.2 on HPUX
Organization: SEL-Alcatel LTS Dept. US/ES
Date: Wed, 9 Sep 92 09:16:30 GMT


-- 


   Thanks for all your help, owen, Ralf ... Much appreciated.




.. Lisa ..
Newsgroups: gnu.gcc.help
From: ctan%Solomon.Technet.sg (Tan Chee Weei)
Subject: Q: gcc 2 vs g++ 1.4
Organization: National University of Singapore
X-Newsreader: Tin 1.1 PL5
Distribution: all
Date: Mon, 7 Sep 1992 04:07:43 GMT

I had assumed that gcc 2, which incorporates C++ would be the compiler
to use for C++ and would make g++ obsolete. However, from the recent
announcement of g++ 1.41, it seems that g++ is still supported
separately. My question now is: Is there a difference in the implementations
of C++ in the two compilers? If so, is the gcc version more up to date
with the developments of the ANSI standard? Thanks.

CW
From: as7l+@andrew.cmu.edu (Andrew B Stellman)
Newsgroups: gnu.gcc.help
Subject: GCC2.2.2 for msdos won't run at all
Date: 12 Sep 92 09:22:12 GMT
Article-I.D.: andrew.AegWR4m00WBM02HVBo
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

I posted a similar message earlier, and was told to get a newer version.
I was using GCC 2.1.

I just installed GCC 2.2.2 for MSDOS. I've got the environment variables
set up, and the files in the correct directories. GCC should run.
However, when I try to compile a simple, one-line program, I get this:

C:\TEST> gcc program.c
Error: Couldn't find --> @C:/TMP/CC000053.GP

The other suggestion I was given was to use the -v flag. Here's what happened:

C:\TEST> gcc -v program.c
Reading specs from d:/lib/gcc/lib/specs
gcc version 2.2.2
 d:/lib/gcc/bin/cpp.exe -lang-c -v -undef -D__GNUC__=2 -Dunix -Di386
-D__unix__ -D__i386__ -D__unix -D__i386 -D__GO32__ -D__MSDOS__ -DGO32
-DMSDOS -noprecomp program.c c:/tmp/cc000053.i
GNU CPP version 2.2.2 (80386, BSD syntax)
 d:/lib/gcc/bin/cc1.exe c:/tmp/cc000053.i -quiet -dumpbase program.c
-version -o c:/tmp/cc000053.s
GNU C version 2.2.2 (80386, BSD syntax) compiled by GNU C version 2.2.2.
as -o program.o c:/tmp/cc000053.s 
Error: Couldn't find --> @C:/TMP/CC000053.GP
d:/lib/gcc/bin/gcc.exe: program.o: file not found


Can someone help me out? It won't compile anything. When I look in my
temp directory c:/tmp, I can see the relevant files were deleted, but
I'm not sure what I can do to solve this problem. 

Thanks in advance,
Andy <as7l@andrew.cmu.edu>
Newsgroups: gnu.gcc,gnu.gcc.help
From: marc@r-node.gts.org (Marc Fournier - Sys Admin)
Subject: help with gcc 2.1 on ISC
Organization: R-node Public Access UNIX System (416-249-5366) 24hrs.
Date: Sun, 13 Sep 1992 04:23:17 GMT

Hello folks...

	I've got gcc 2.1 installed on my system and am quite
discouraged and disappointed with it :(  I can't compile anything
that comes across the net with it without some massive hassles and
I usually give up with them and switch back to the 'stock' cc
on my system.

	Now, for example, I'm trying to get Taylor UUCP compiled.
If I use 'sh configure CC=gcc CFLAGS=-O -s', everything goes through
just fine.  As soon as I run 'gmake' (what I called Gnu Make 3.62(?))
I get the following errors:


gcc -O -c -g -I. -I. -DLIBDIR=\"/usr/local/lib/uucp\" -DNEWCONFIGLIB=\"/usr/local/conf/uucp\" -DOLDCONFIGLIB=\"/usr/lib/uucp\" -DOWNER=\"uucp\"  uucico.c
In file included from uucp.h:330, from uucico.c:304:
/usr/include/memory.h:12: warning: conflicting types for built-in function `memcpy'
In file included from uucp.h:338, from uucico.c:304:
/usr/include/string.h:21: conflicting types for `memcpy'
/usr/include/memory.h:12: previous declaration of `memcpy'
/usr/include/string.h:32: conflicting types for `memchr'
/usr/include/memory.h:11: previous declaration of `memchr'
/usr/include/string.h:40: conflicting types for `memset'
/usr/include/memory.h:13: previous declaration of `memset'
In file included from uucico.c:304:
uucp.h:1192: warning: conflicting types for built-in function `memcmp'
uucp.h:1201: conflicting types for `memcpy'
/usr/include/string.h:21: previous declaration of `memcpy'
In file included from sysdep.h:385, from port.h:71, from uucico.c:314:
/usr/include/sys/stat.h:95: parse error before `mode_t'
/usr/include/sys/stat.h:97: parse error before `mode_t'
/usr/include/sys/stat.h:98: parse error before `mode_t'
gmake: *** [uucico.o] Error 1

	This is using my 'stock' include files.  Anyone have any
ideas?  I would definitely like to start using gcc more often, but
I get these similar errors everytime I do :(

Any suggestions are appreciated...and will be tried out :)

Marc	
-- 
Marc G. Fournier      | R-node Public Access Unix running UnixBBS 1.03
Etobicoke, Ontario    | 416-249-5366   24hrs 7 days/week   network email
voice: 249-4230       | shell/feed accounts available   1800+ newsgroups
marc@r-node.pci.on.ca | Telebit T3000/SupraModem2400/Cardinal 2400  FREE
Newsgroups: gnu.gcc.help
From: deano@areyes.com (Dean Carpenter)
Subject: Help compiling 2.2.2 under ISC 3.0
Followup-To: deano@areyes.com
Summary: enquire.c locks up, why ?
Keywords: gcc 2.2.2 perl isc
Organization: Areyes, Inc.
Date: Wed, 9 Sep 1992 01:29:45 GMT

  I just got the gnu gcc-2.2.2 distribution from uunet and have been
having a couple of small problems compiling it.  Essentially, the enquire
program locks up after outputting  (from enquire -f)  :

  /* Minimum int x such that 10**x is a normalised float */
#define FLT_MIN_10_EXP (-37)

  I've tried all types of compiles for enquire.c, using the stock ISC 3.0
cc, gcc 2.1, various and sundry options, all to no avail.

  The system was configured with  "configure --target=i386-*-isc"
and a regular  "make LANGUAGES=c"  was run.  Everything ran fine until
the "enquire -f" line was run, then it just sat there.

  We don't have Bison installed, but the c-parse.? and cexp.? files are
dated thusly :

-rw-r--r--   1 deano    staff     123479 Jun 13 22:34 c-parse.c
-r--r--r--   1 deano    staff       1524 Jun 10 00:29 c-parse.gperf
-rw-r--r--   1 deano    staff       1129 Jun 13 22:34 c-parse.h
-rw-r--r--   1 deano    staff      76645 Sep  7 18:33 c-parse.o
-r--r--r--   1 deano    staff      49231 Jun 10 00:25 c-parse.y
-rw-r--r--   1 deano    staff      46446 Mar 28 15:38 cexp.c
-rw-r--r--   1 deano    staff      21213 Sep  7 18:33 cexp.o
-rw-r--r--   1 deano    staff      20138 Feb 13  1992 cexp.y

  I noticed a similar situation when compiling perl 4.035 (also from
uunet).  When running Configure, the "try.c" program that checks to see
if the C compiler can cast weird floats to unsigned would lock up the
same way.

  Does this sound familiar to anyone ?  Has anyone built gcc 2.2.2 (or
perl 4.035) under ISC 3.0 ?  We got perl compiled ok, and it seems to
work fine, passed the "make tests" run, but what's the deal with these
lockups ?

  Please mail me directly as we don't get this group regularly ... thanks
for any help in advance ...

-- 
Dean Carpenter		uunet!areyes!deano		(203) 847-6003
Areyes, Inc.		deano@areyes.com

"No matter where you go, there you are"  sayeth Buckaroo 								 across the Eighth Dimension
Newsgroups: gnu.gcc.help
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: HELP: GO_IF_LEGITIMATE_ADDRES
Date: Mon, 7 Sep 1992 22:58:27 GMT
Organization: TH-Darmstadt

In article <1992Sep7.124514.23362@newsserver.rrzn.uni-hannover.de> chris@cyber.mim.uni-hannover.de (Christoph Niessen) writes:


>   Hi,

>   i tried to compile gcc on an IRIS3030 (CYBER910/300). This machine
>   has an 68020 and special floating point hardware. The first problem
>   during compilation gcc-1.41 is in relaod.c (line 786):

>   compiler error: out of tree space; simplify expression

Condolence!

This is a common problem on 68020 using PCC (portable C compiler).
Its executable has been compiled with table sizes configured too small. 
ASK your friendly SR to fix this. Vendor needs to recompile a configuration 
file and relink the compiler, that's all.
 

>   The macro GO_IF_LEGITIMATE_ADDRESS seems to be too much complicated.
>   Please help via mail or this newsgroup.

Compiler is broken, the macro is o.k . There is no need to provide
fixed space for tables in a compiler, trees may grow dynamically ;->.

>   Chris

best adams

>   Please ignore all the mistakes, my first language is german!
So do I.
Newsgroups: gnu.gcc.help
From: voss@cs.uiuc.edu (Bill Voss)
Subject: gcc on <Tektronix - UTek Tek4319_R4.1> anyone?
Organization: Typed Smalltalk Group, Dept of Comp Sci, Univ of IL in Urbana.
Date: Sat, 5 Sep 1992 04:16:45 GMT

Has anyone ported gcc to UTek?

			thanks,
			Bill Voss <voss@cs.uiuc.edu>
From: mmc@iagu.itd.adelaide.edu.au (Matthew Moyle-Croft)
Newsgroups: gnu.gcc.help
Subject: Can't Compile gcc on DecStation with OSF/1
Date: 16 Sep 92 02:43:49 GMT
Organization: University of Adelaide, South Australia
NNTP-Posting-Host: iagu.itd.adelaide.edu.au

Hello,
      I've been trying to compile gcc 2.2.2 on a DecStation 5000.  The first
stage (stage1) works, but it stops somewhere in the second stage with an
assertion failing.  Someone said that it was assuming the wrong library
format.  Can anyone who has got it working please contact me in regards to
getting it working?

Thanks,

-- 
MatthewMC
--
Matthew Moyle-Croft    (mmc@iagu.itd.adelaide.edu.au) (Ph. +61-8-370-9501)
University of Adelaide (memoylec@cs.adelaide.edu.au)  (or  +61-8-271-9238)
Newsgroups: gnu.gcc.help