HDTenEightyP/NetNews huggingface dataset:
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: Gnu ld and collect
Date: 6 Jan 1993 20:43:13 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <klamer.726308465@mi.el.utwente.nl> klamer@mi.el.utwente.nl (Klamer Schutte) writes:
>I can see advantages in using both Gnu ld and collect for linking g++
>programs. (See FAQ for what reasons.) Is it possible to have both
>link systems available at the same time? (With a command line switch
>for g++, for example?)

This can be made to work on some platforms (where collect and Gnu ld both
work and accept the same format of object file).  Here is one very ugly
way to do it that I got to work.

Let's say, for example, that you have 2.3.3 installed on a sparc.
The compiler passes are then in (somewhere)/lib/gcc-lib/sparc/2.3.3
(the makefile variable "libsubdir" refers to this directory).

As a first step, install gcc with "--with-gnu-ld" and put Gnu ld
in the libsubdir directory.  Now, create a directory
(somewhere)/lib/gcc-lib/sparc/2.3.3-collect.  Do a symbolic link
to have everything in libsubdir appear in this directory as well.
Install collect in this directory.

Now, you can use collect by saying "gcc -V 2.3.3-collect".  Furthermore,
since only the link is different, you can omit the -V switch except
when you are linking.

Warning: on the sparc, the Gnu linker won't call constructors properly for
code compiled by a gcc binary that was configured without the
--with-gnu-ld switch (the stabs directives that gld needs will be
missing), but collect will not care if the stabs are present.  Since
having the stabs present when they are unneeded is harmless (and the space
required is tiny) I think they should always be generated on platforms
with a.out-style objects.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help,gnu.gcc.help
From: bashford@scripps.edu (Don &)
Subject: Anyone built gcc-2.3.3 and libg++-2.3 on DEC Alpha?
Organization: The Scripps Research Institute, La Jolla, CA, USA
Distribution: gnu
Date: Tue, 12 Jan 1993 05:54:55 GMT

I've been able to get gcc-2.3.3 built on the DEC Alpha and the C
part seems to work fine, but I can't even begin to compile libg++-2.3
with it.  (I've already submitted bug reports on specific problems.)

Has anyone been able to do this?  Does anyone know the status of
the C++ side of gcc on the Alpha?

Thanks,
Don Bashford
bashford@scripps.edu
Newsgroups: gnu.g++.help,comp.lang.c++
From: DataCom_Systems@3mail.3com.COM
Subject: GNU C++ for Aviion and AIXV3.2
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Date: Tue, 5 Jan 1993 21:07:00 GMT

I will be adapting an application from a Sun OS 4.x platform that uses 
the GNU C++ compiler and class libraries to both a Data General AViion 
DG/UX and IBM AIX V3.2 systems.  Are the compiler and class libraries 
available for both platforms?  What are the costs and delivery lead 
times.

Thank you,

Richard Shortz
DataCom Systems, Inc.
Mountain View, CA
415/962-0940
From: rrp@cfm.brown.edu (Bob Petrocelli)
Newsgroups: gnu.g++.help
Subject: Help building libg++2.3 (please)
Date: 12 Jan 1993 19:33:33 GMT
Organization: Brown University Center for Fluid Mechanics
Distribution: usa
NNTP-Posting-Host: dam.brown.edu
Originator: rrp@rufus


I have sucessfully built gcc-2.3.3 and now wish to
build libg++-2.3. I am having some serious problems with
include file conflicts and would rejoice if given any help:

make CC=gcc yields the following:

gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include -c
AllocRing.cc
In file included from ./../g++-include/sys/types.h:15, from
/usr/include/unistd.h:72, from ./../g++-include/unistd.h:25, from ./std.h:28,
from AllocRing.cc:22:
/usr/include/sys/types.h:24: conflicting types for 'wchar_t'
./../g++-include/stddef.h:11: previous declaration of 'wchar_t'
*** Error code 1
make: Fatal error: Command failed for target 'AllocRing.o'
Current working directory /usr2/rrp/temp/c++/libg++-2.3/libg++/src
*** Error code 1
make: Fatal error: Command failed for target 'in-src'


BTW this is being done on a Sun4 running SunOS 4.1.2

Thanks,

Bob Petrocelli
From: archmage@cs.mcgill.ca (Patrick Marcoux)
Newsgroups: gnu.g++.help
Subject: Inline: the missing link
Date: 12 Jan 93 20:33:28 GMT
Organization: Forgive the Moose campaign international

I have a problem porting 'textbook' code from an HP-UX C++ (cfront) compiler
to a GNU g++ one.

The problem involves the use of inlining.

The cfront accepts 2.1, and to my experience conforms to it or explicitly
states otherwise in it's error messages.  It's on an HP 9000/360 running
HP-UX 7.x

The  GNU is version 2.3.1, for sparc-sun-sunos4.1.  I have used it with
and without the -ansi, -pedantic, -Wall flags.

The code compiles without errors or warnings.
I package my object files into a library (ar rv libtk.a *.o; ranlib libtk.a).
No prob.  But when I try to link it with some test code and make executables,
the linker returns symbol not found errors.  All the symbols are in function/
method label format.

The problem occurs when I try to link with a compilation unit whose header
contains one or more of:
	A) Automatically inlined friend functions
		(used as per Stroustup's C++ reference manual, AT&T,
		 chap. 11.4 paragraph 6)
		
	B) (Automatically) inlined methods that call private methods
	
	C) Another as yet unidentified circumstance, which I believe to be
	   similar

In the first case, the symbols not found are those of the friend fn names
themselves. By swapping code around and making things explicit, these errors
disappear.  I'm still diagnosing the other cases.

All this code, the make files, everything was debugged & running smooth on
the HP.

I'll try to whip up a quick & simplified example to post.  In the meantime,
if this is a known and/or documented problem, or if you have ideas about
what's wrong, please let me know.

P.S. Please reply by e-mail AS WELL AS post.  Thanks. 
-- 
===============================================================================
	Every program has at least one bug and can be shortened by at least
	one instruction -- from which, by induction, one can deduce that
	every program can be reduced to one instruction which doesn't work.
From: walter@cithe501.cithep.caltech.edu (Chris Walter)
Newsgroups: gnu.g++.help
Subject: Problem using gdb4.7 on g++ programs on RS6000.
Date: 8 Jan 1993 02:10:06 GMT
Organization: California Institute of Technology, Pasadena
Distribution: gnu
NNTP-Posting-Host: cithe303.cithep.caltech.edu
Originator: walter@cithe303.cithep.caltech.edu

Hi Folks,

First off I am running AIX3.2 on an RS6000.
I am using gcc 2.3.2/libg++ 2.3

I am having problems debugging c++ programs with gdb4.7.
gdb seems to work OK on small C programs compiled with gcc but I am
having problems debugging C++ code compiled(-g of course) with g++.

I should mention that my sys-op says the RS6000 assembly patch has
been applied.  Here is an example of what happens when I try to load a
executable:
------------------------------------------------------------------------
cithe502:wfd > gdb 
GDB is free software and you are welcome to
distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.7, Copyright 1992 Free Software Foundation, Inc.
(gdb) file monte
Reading symbols from monte...GDB Error: `.bf' not found.
GDB Error: `.bf' not found.
done.
(gdb)
------------------------------------------------------------------------

And here is the same thing for what is a simpler program:

------------------------------------------------------------------------
cithe502:flux > gdb
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.7, Copyright 1992 Free Software Foundation, Inc.
(gdb) file flux
Reading symbols from flux...GDB Error: `.bf' not found.
GDB Error: `.bf' not found.

Catastrophe in realloc: invalid storage ptr
IOT trap (core dumped)
cithe502:flux > 
------------------------------------------------------------------------

In addition, the first program, which it allows me to load, starts in the
middle of the routine if I tell it to "break main".  It sets the
breakpoint something like halfway down routine.

Any suggestions happily accepted!

-Chris Walter
From: scottr@atherton.com (Scott F. Rasmussen)
Newsgroups: gnu.g++.help
Subject: trouble building libg++2.2 with gcc 2.3.1
Keywords: libg++, gcc, wchar_t, conflicting definitions
Date: 7 Jan 93 21:55:27 GMT
Followup-To: scottr@atherton.com
Organization: Atherton Technology, Inc.


I am trying to build libg++2.2 with gcc 2.3.1 and get the following  
error. I used the config sun-sparc-sunos4 for my sparc mp running 4.1.2.
Any help is appreciated.  I am in the process of getting libg++2.3 but I  
thought this might not be related to that.
Here's the error...

gcc -v -I.. -I. -I./../iostream -I./../g++-include -c AllocRing.cc
Reading specs from /usr/local/lib/gcc-lib/sparc/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc/2.3.1/cpp -lang-c++ -nostdinc++ -v -I..  
-I. -I./../iostream -I./../g++-include -undef -D__GNUC__=2 -D__GNUG__=2  
-D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__  
-D__sparc -D__sun -D__unix AllocRing.cc /usr/tmp/cca15048.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc/2.3.1/cc1plus /usr/tmp/cca15048.i -quiet  
-dumpbase AllocRing.cc -version -o /usr/tmp/cca15048.s
GNU C++ version 2.3.1 (sparc) compiled by CC.
In file included from ./../g++-include/sys/types.h:15, from  
/usr/include/unistd.h:72, from ./../g++-include/unistd.h:25, from  
/std.h:28, from AllocRing.cc:22:
/usr/include/sys/types.h:24: conflicting types for `wchar_t'
/../g++-include/stddef.h:11: previous declaration of `wchar_t'

from the output of gcc -E here are the conflicting definitions...

# 41 "/usr/local/lib/gcc-lib/sparc/2.3.1/include/stddef.h" 3
...
typedef __wchar_t wchar_t;

# 1 "/usr/include/sys/stdtypes.h" 1 3
.
typedef unsigned short  wchar_t;

Thanks for any help...
--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=
Scott Rasmussen                              scottr@atherton.com
Atherton Technology                     {sun|decwrl}!athertn.com
Newsgroups: gnu.g++.help,gnu.g++
From: amos@sol.acs.unt.edu (Amos A. Gouaux)
Subject: CursesWindow in libg++-2.3 using gcc-2.3.3
Organization: University of North Texas
Date: Sun, 10 Jan 1993 18:16:18 GMT


machine: solbourne series 5e/902 (sun sparc compatible)
system: os/mp 4.1A.3 (based on sunos4.1.1)

i was able to build gcc-2.3.3 without any problems.  i was also able
to build libg++-2.3 equally error free.  all the libg++ tests seem to
have run just fine.  however, when i tried to run "tCurses" down in
the tests directory, i discovered that certain output was missing.
in particular, the format strings for the *print* methods were never
displayed, not in any form.  for example, the following text was
missing from the output.

     begx=0,maxx=79,begy=0,maxy=23,height=24,width=80
     printw test:13, A, Cstar, -1, 3.141593, 3.183099
     enter an int:
     number = 
     enter a char:
     char = 

yet "123" and "a" _did_ appear.  most peculiar.  with gcc-2.2.2 and
libg++-2.2, i was able to produce this output from the very same source
file, which i have included below.  this source file is merely a simplified
version of tCurses.cc.

can someone tell me the reason for the above behavior?  is there
something that i'm doing wrong?  is this a bug with one of the packages?

amos


//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <CursesW.h>

// a simple test/demo for CursesWindow.  with gcc-2.3.3 and libg++-2.3,
// none of the lines ending with "//**" produce the desired output strings.

int main
(void)
{
CursesWindow big(23, 79, 0, 0);

int i;
char c='A';

big.box('B','B');

big.refresh();

big.mvprintw(0,0,"begx=%d,maxx=%d,begy=%d,maxy=%d,height=%d,width=%d", //**
             big.begx(), big.maxx(), big.begy(), big.maxy(),
             big.height(), big.width());
big.refresh();

i=13;
const char * cptr = "Cstar";

long l = 0xffffffff;
double d= 3.1415926;
float f= 10.0/d;

big.mvprintw(2,2,"printw test:%d, %c, %s, %ld, %lf, %f\n",i,c,cptr,l,d,f); //**
big.refresh();

big.mvprintw(5,20,"enter an int:"); //**
big.refresh();
big.scanw("%d",&i);
big.move(6,20);
big.printw("number = %d\n",i); //**
big.refresh();

big.mvprintw(20,20,"enter a char:"); //**
big.refresh();
big.scanw("%c",&c);
big.move(21,20);
big.printw("char = %c\n",c); //**
big.refresh();
}

//_____________________________________________________________________________
-- 
amos@unt.edu                   Amos A. Gouaux                   (817) 565-4161
-= Academic Computing Services, University of North Texas, Denton, TX, USA. =-
From: heiniw@eebsun1.eeb.ele.tue.nl (Heini Withagen)
Newsgroups: gnu.g++.help
Subject: Problems with gcc/g++ and profiling
Date: 11 Jan 93 11:59:01 GMT
Organization: Electronic Circuit Design Group, Eindhoven University of Technology, The Netherlands



I am having trouble with gcc/g++ 2.2.2 compiling programs with -pg
options for profiling. I have been looking what g++ actually does
during compilation/linking (-v option) and compared this to 'cc' (on 
a SUN Sparc).

It seem that g++ is linking the wrong libraries which do not contain
the right function for profiling. When I try to make a seperate call
to the linker with the same libraries substituded as with 'cc', I get
a long list of 'Undefined' names which look like 'LBE??' and 'LBB??'.


Does anyone know the answer to my problems ?? Please help me, because
I am getting quite desperate.


Thanks very much in advance,

Heini Withagen
Department of Electrical Engineering EH 9.29
Eindhoven Technical University
P.O. Box 513
5600 MB Eindhoven
The Netherlands
Phone: 31-40472366
Fax:   31-40455674
E-mail: heiniw@eeb.ele.tue.nl
Xref: sparky gnu.g++.help:1642 comp.unix.sysv386:17689
From: traub@rtf.bt.co.uk (Michael Traub)
Newsgroups: gnu.g++.help,comp.unix.sysv386
Subject: Re: libg++ include file problems under SCO 3.2v4 (i386)
Date: 7 Jan 93 14:49:35 GMT
Organization: BT Customer Systems, Brighton, UK

In article <1993Jan6.191734.12565@wam.umd.edu> yml@wam.umd.edu (Yermo Manfred Lamers) writes:
>gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c CursesW.cc
>In file included from ./CursesW.h:26, from CursesW.cc:30:
>./../g++-include/curses.h:40: parse error before `_c3'

You need to #undef lines which was included from term.h. I did this
in tinfo.h as follows:

	#if __cplusplus
	#ifdef lines
	#undef lines
	#endif
	#endif

>gcc -g -O -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c  procbuf.C
>./../g++-include/signal.h:47: conflicting types for `int  kill (...)'
>./../g++-include/sys/wait.h:32: conflicting types for `short int  waitpid (...)'

You need to get the definitions to match. I altered the libg++ include files.


-- 
Michael Traub
BT Customer Systems, Brighton Systems Centre. traub@btcs.bt.co.uk

    JOE, taxi driver: Unemployment will rise and sooner or later the
    masses will revolt against it. There'll be civil disorder and the
    further breakdown of civil society. The end result I hope will be
    the triumph of the people over capitalism. I also wouldn't mind
    if a few more people used taxis this year - '92 was rotten.

(Taken from "Hopes and Fears" in The Guardian, December 31st 1992, a
section which looked at what people saw 1993 bringing)
Newsgroups: gnu.g++.help
From: cmlow@iti.gov.sg (Low Chee Meng (KSL))
Subject: Help: using GDB to debug G++-compiled programs
Keywords: gdb, g++
Organization: National Computer Board, Singapore
Date: Fri, 8 Jan 1993 14:29:36 GMT

Hi,

I'm using GDB for the first time to debug a C++ program (compiled with
-g flag with G++). One thing I couldn't figure out how to do is to
execute some method call inside GDB, eg:

gdb> print someObj.someMethod(someArgs....)

GDB would always return back something like "there's no component
named someMethod", even though someMethod is a valid method of
the class to which someObj belongs to.

Is there something I have to do make the above work?

I'm current using GDB 4.6 on Sun OS.

Thanks in advance for any help,

CheeMeng

-- 
---------------------------------------------------------------------
Chee-Meng Low (cmlow@iti.gov.sg) (fax: 65-777-3043)
Knowledge Systems Lab, Information Technology Institute, Singapore
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Newsgroups: gnu.g++.help
From: guy@wyrdrune.demon.co.uk (Guy Gascoigne-Piggford)
Subject: g++ -g isn't working
Reply-To: guy@wyrdrune.demon.co.uk
Organization: Wyrdrune
Date: Thu, 7 Jan 1993 22:41:48 GMT

gcc 2.3.3 : Dell SVR4 : i486

I can't get g++ to produce anything with any debug information in it.
Every file I try gives me undefined name errors from the assembler.

eg.

[159 /home/guy/src/work ] cat tt.C
#include <stream.h>
main()
{
        cout << "Hello World\n";
}

[160 /home/guy/src/work ] g++ -v tt.C -o tt -g
Reading specs from /usr/local/lib/gcc-lib/i486-sysv4/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/i486-sysv4/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Di386 -Dunix -D__svr4__ -D__i386__ -D__unix__ -D__svr4__ -D__i386 -D__unix -D__svr4__ -Asystem(unix) -Acpu(i386) -Amachine(i386) -g tt.C /var/tmp/cca000Bn.i
GNU CPP version 2.3.3 (i386 System V Release 4)
 /usr/local/lib/gcc-lib/i486-sysv4/2.3.3/cc1plus /var/tmp/cca000Bn.i -quiet -dumpbase tt.cc -g -version -o /var/tmp/cca000Bn.s
GNU C++ version 2.3.3 (i386 System V Release 4) compiled by GNU C version 2.3.2.
 /usr/ccs/bin/as -V -Qy -o /var/tmp/cca000Bn1.o /var/tmp/cca000Bn.s
as: Standard C Development Environment  (SCDE) 5.0  04/26/91
(EOF):undefined name: .L_T51

Any clues? Have I found a bug or just screwed up the build?

-- 
===============================================================================
Guy Gascoigne-Piggford                  | "... and then I said to myself, 'Why
guy@wyrdrune.demon.co.uk                |  should I split it two ways -'"
ggascoigne@cix.compulink.co.uk          |                          - G. MOUSER
From: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
Newsgroups: gnu.g++,gnu.g++.help
Subject: Re: Installing gcc 2.3.3 and libg++ 2.3
Date: 6 Jan 1993 14:32:13 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, br762@cleveland.Freenet.Edu (Tim Werner) says:

>
>In a previous article, louqun@cs.tamu.edu (Qun Lou) says:
>
>>I finally installed gcc 2.3.3 and libg++ 2.3 successfully 
>>The problems I mentioned in my previous email disappeared.
>>
>>I wish to share the experience with other people who
>>would be installing gcc or libg++ on HP or other computers.
>>
>>1. Before installing gcc 2.3.3, I deleted all the previous gcc stuff in 
>>/usr/local/lib/gcc-lib and in /usr/local/bin.
>>
>>2. Necessary files for successful installation:
>>
>>bison  in /usr/local/bin
>>gas    as emphasized in gcc 2.3.3 README, gas should be installed *before*
>>       installing gcc as '/usr/local/lib/gcc-lib/hp835-hpux/2.3.3/as'
>
>I am trying to build libg++ on a sun3 running SunOS, and getting the following:
>rootme=`pwd`/ ; export rootme; CC="cc "; export CC; CXX="gcc  "; export CXX; CON
>FIG_NM="nm"; export CONFIG_NM; ./utils/gen-params LIB_VERSION=2.3  >tmp-params.h
>nm: dummy.o: cannot open
>nm: dummy.o: cannot open
>nm failed to find FUNC in dummy.o!
>./utils/gen-params: -1: bad number
>make[1]: *** [_G_config.h] Error 1
>make: *** [all-libg++] Error 1
>
>I am trying to build these libs in a non-standard path. Although I set 'prefix'
>to the path for gcc (also non-standard), make isn't finding it, as you can see
>from the above (CC="cc "; export CC; CXX="gcc  ").
>
>Has anyone else had and solved this problem? Is bison and gas really the key?
>
>Everything has to be built in a non-standard path. I can't get the sys-admin
>to help with installation until everything is working.
>
>thanks
>tim
>werner@sparcserver.mc.ab.com
>-- 
>

I'm also experiencing the same problems under SunOS 4.1.3 on a SparcStation 1.
I have to maintain my original GCC 1.37 environment so I wish to build/test/
and release ( to a a select few at the start) GCC 2.3.2 and libg++2.3. I have
attempted to build under:

/usr/local/tmp

I have:

bin                     bison-1.19              lib                     
binutils-2.0            gcc-2.3.2               libg++-2.3
binutils-2.0.tar.Z      include                 libg++-2.3.tar.Z
binutils-2.0_OU         info                    man


After having run configure sun4 -prefix=/usr/local/tmp and make I see
error messages as reported by the other poster.

Do I need Gas, nm, ld and the binutils ? What sort of directory
structure should I use to compile libg++2.3. How can I get the
libg++2.3 gen use my new GCC 2.3.2 compiler ( to be found below 
/usr/local/tmp/bin ). Lots of questions, not a lot of answers...

If anyone reports a fix to this problem, let me know, thanks.

Steve.
Newsgroups: gnu.g++.help,gnu.gcc.help
From: br762@cleveland.Freenet.Edu (Tim Werner)
Newsgroups: gnu.g++.help
Subject: I can't make libg++-2.3 to save my life
Date: 8 Jan 1993 16:57:32 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: br762@cleveland.Freenet.Edu (Tim Werner)
NNTP-Posting-Host: hela.ins.cwru.edu


Please, anybody who has built libg++-2.3 in a non-standard path, can you tell
me what you did?

I used "config --target=sun3 --prefix=/usr/gnu/gcc-2.3.3 --nfp" prior to making
gcc. Then I used "config sun3 -prefix=/usr/gnu/gcc-2.3.3" prior to making
libg++-2.3. This was after several other unsuccessful attempts at building
the libs, by the way. I couldn't really find an explicit direction for what
prefix to use in any of the REAME's.

I also "set path = (/usr/gnu/gcc-2.3.3 $path)" before trying to make libg++.

Then I get all sort of mysterious errors. For instance:
   In file included from ./../iostream/streambuf.h:27,
      from ./../iostream/iostream.h:24, from ./../iostream/stream.h:7,
      from ./String.h:26, from String.cc:25:
   ./../g++-include/stdarg.h:2: stdarg.h: No such file or directory

I don't get it. File stdarg.h includes stdarg.h, with some comment about:
   #ifndef __GNUC__
   /* Use the system's macros with the system's compiler.
      This is relevant only when building GCC with some other compiler.  */
   #include <stdarg.h>

Since by this time in the process, I am building the libs, not GCC, why
would this be relevant.

By the way, the --nfp was something I only tried the last 2 times I built
gcc. Does anyone know how to tell whether their sun3 has the floating point
unit?


Anyway, if you have built the lib's in a non-standard path, can you tell me
what you did. There must be something I'm missing.

Thanks a lot if you can help.
tim werner
werner@sparcserver.mc.ab.com
--
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: g++ -g isn't working
Date: 7 Jan 93 22:54:54 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1993Jan7.224148.1392@wyrdrune.demon.co.uk> guy@wyrdrune.demon.co.uk writes:
>gcc 2.3.3 : Dell SVR4 : i486
>
>I can't get g++ to produce anything with any debug information in it.
>Every file I try gives me undefined name errors from the assembler.

See the FAQ.  -g doesn't work with g++ on SVR4 yet.  Maybe in 2.4.
Ron, do you know anything about this?



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.lib.bug