HDTenEightyP/NetNews huggingface dataset:
From: mrs@kithrup.COM (Mike Stump)
Subject: Re: G++ and 3.0
Reply-To: mrs@cygnus.com (Mike Stump)
Organization: Cygnus Support
Date: Thu, 23 Jul 1992 14:40:13 GMT

As one of the people that enhances g++ to more fully conform to the x3j16
working paper, let me suggest that it is more useful to me if you ask when
a particular feature will be implemented.  That way, I can have a sence of
what people would like to see first.

While cfront 3.0 is a nice target, I am more interested in ANSI C++, for
example, the next release of gcc will, in all probability, have wchar_t as
a distinct type, suitable for overloading.  cfront does not have this
feature.  One will be able to say cout << L"..." and get meaningful results.

In article <l6qpmdINN4mq@news.bbn.com> mbrinn@bbn.com (Marshall Brinn) writes:
>Does anyone know of current plans for a g++ release compatible with the 3.0
>or 3.1 language features?
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: ___builtin_delete not found??
Date: 24 Jul 92 22:32:52 GMT
Distribution: usa
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Jul24.220827.28092@jhunix.hcf.jhu.edu> camacs5@jhunix.hcf.jhu.edu (Sol Su) writes:
>i am trying to dynamically load compiled g++ code into
>S.  when the code is compiled with AT&T C++2.1 it loads
>without trouble; trying to get the g++-produced image
>into S yields "___builtin_delete" and "___builtin_new"
>undefined symbols.  in the libg++.a, indeed the ___builtin_delete
>symbol is U.  where is it resolved?

It's in -lgcc.  libgcc.a lives in the same place as the passes to
gcc, which you can find out by doing gcc -v.

It's not in libg++.a because libg++ is optional but support for new
and delete is required.  Also, libgcc routines can be included with
complete freedom in proprietary code (no GPL or even LGPL restrictions);
libg++ is subject to the LGPL.




--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help,comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Invalid cast and overload in g++
Organization: TauMetric Corporation
Distribution: na
Date: Fri, 31 Jul 1992 16:48:45 GMT

afriend@dew.Princeton.EDU (A. Friend) writes:

>Why does g++ choke on these two lines?

>> overload LogSolution();

The keyword 'overload' is obsolete (has been since 1990), and need
not be supported by current compilers.  Get rid of 'overload' keywords
in your code.


>>    istream in = istream(open(savefile, O_RDONLY));

This is not a good way to create a stream object.  Use initialization
by constructor instead:

	istream in(open(savefile, O_RDONLY));

Further, this method of creating an istream is obsolete (assuming you
are using iostreams, rather than the pre-1990 old-style streams).
Probably you should #include <fstream.h> and create an ifstream instead:

	ifstream in(savefile)

It may be that you are using very old code, or have an obsolete C++
textbook.  There are a number of good up-to-date books available.  I
recommend "C++ Primer", 2nd edition, by Stan Lippman, Addison-Wesley.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ichikawa@nb108.cp.nb.epson.co.jp (Tatsuya Ichikawa)
Newsgroups: gnu.g++.help
Subject: Internal compiler error:program cc1 got fatal signal 6  on i386-sysv4
Date: 24 Jul 92 02:44:53 GMT
Organization: SEIKO EPSON Corp.,Japan

I compile libg++-2.2.2 using gcc-2.2.2.
But below errors detected when compiling libg++/src/String.cc.
This error cannot appaare without -g option.

	gcc -g -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include -c String.cc
gcc: Internal compiler error: program cc1plus got fatal signal 6
*** Error code 1 (bu21)

make fatal error.


I don't understand What part of cc1plus do I correct.
Has anyone got same error ?
Please help me.
					Tatsuya Ichikawa(Japan)
					E-mail : ichikawa@nb.epson.co.jp
-------------------------------------------------------------------------------

-- 
			Name : Tatsuya Ichikawa --
			Corp : Seiko Epson Corp.--
			Addr : ichikawa@nb.epson.co.jp --
			
Newsgroups: gnu.g++.help
From: gene@ponder.csci.unt.edu (Gene De Lisa)
Subject: I need help building libg++ on sun4
Organization: University of North Texas, Denton
Date: Thu, 30 Jul 1992 15:55:38 GMT


I ran configure sun4 in the lib g++2.2 dir then typed make.
I got this:
mv tmp-params.h _G_config.h
gcc -g  -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
In file included from ./std.h:28, from AllocRing.cc:22:
./../g++-include/unistd.h:76: conflicting types for `void  encrypt (...)'
/usr3/gcc/lib/g++-include/unistd.h:39: previous declaration of `char * encrypt (char *, int)'
./../g++-include/unistd.h:92: conflicting types for `short unsigned int  geteuid (...)'
/usr3/gcc/lib/g++-include/unistd.h:56: previous declaration of `int  geteuid ()'
./../g++-include/unistd.h:93: conflicting types for `short unsigned int  getegid (...)'
/usr3/gcc/lib/g++-include/unistd.h:57: previous declaration of `int  getegid ()'
./../g++-include/unistd.h:94: conflicting types for `short unsigned int  getgid (...)'
/usr3/gcc/lib/g++-include/unistd.h:58: previous declaration of `int  getgid ()'
./../g++-include/unistd.h:102: conflicting types for `short unsigned int  getuid (...)'
/usr3/gcc/lib/g++-include/unistd.h:66: previous declaration of `unsigned int  getuid ()'
./../g++-include/unistd.h:109: conflicting types for `int  pause (...)'
/usr3/gcc/lib/g++-include/unistd.h:74: previous declaration of `void  pause ()'
./../g++-include/unistd.h:115: conflicting types for `int  syscall (...)'
./../g++-include/unistd.h:115: A parameter list with an ellipsis can't match
./../g++-include/unistd.h:115: an empty parameter name list declaration.
/usr3/gcc/lib/g++-include/unistd.h:83: previous declaration of `int  syscall (int, ...)'
*** Error code 1
make: Fatal error: Command failed for target `AllocRing.o'
Current working directory /usr/local/gnu/libg++-2.2/libg++/src
*** Error code 1
make: Fatal error: Command failed for target `in-src'
Current working directory /usr/local/gnu/libg++-2.2/libg++
*** Error code 1
make: Fatal error: Command failed for target `all-libg++'


Any suggestions?

Newsgroups: gnu.g++.lib.bug
From: jbuck@ohm.berkeley.edu (Joe Buck)
Subject: Re: libg++ 2.2 problem
Organization: U. C. Berkeley
Distribution: gnu
Date: Wed, 29 Jul 1992 01:06:22 GMT

In article <9207272047.AA14817@_devon.prepnet.com> you write:
>I built libg++ version 2.2 on a HP 9000/730 (running HP-UX 8.05)
>using GCC version 2.2.2.  Whenever I try to link libg++.a with
>any C++ program, no matter how trivial, I always get the following
>error from the linker:
>
>ld: Unsatisfied symbols:
>   _vt.filebuf (data)

There's a problem in configure for the HP; the following workaround
worked for me.  Ignore the threatening

/* AUTOMATICALLY GENERATED; DO NOT EDIT! */ 

warning and add the line

#define _G_DOLLAR_IN_LABEL 1

to _G_config.h in the src directory.



-- 
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.g++.lib.bug
From: SHN6921%TNTECH.BITNET@mitvma.mit.edu
Subject: Installation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 15:53:00 GMT

Sir/Madam
           I have successfully installed the gcc version 2.2.2 compiler
and the g++ which came with it. I am having a lot of problems when
trying to install the g++lib version 1.39.0. Can somebody tell me how to
install it.
            The changes I made in the Makefile are to the variables
PWD, prefix, OSFLAG=-DUSG, INSTALL=cp, PIPE_AS to none.

                                    Sriram Yeshwanth

Newsgroups: gnu.g++.lib.bug
From: niemira@rooney.fstrf.ORG (niemira.jim)
Subject: losing compile on DEC5000 w/ g++2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 13:06:58 GMT

Gentle Readers,

	While attempting to compile libg++-2.2 with gcc-2.2.2 on a 
DECstation 5000/240 (and DECstation 5000/125) running Ug^Hltrix4.2A, I came
across the following:

>Script started on Mon Jul 20 15:02:17 1992
>94 rooney>gmake
>gmake[1]: Nothing to be done for `all'.
>/local/sys/src/libg++-2.2/libg++/../gcc/gcc -B/local/sys/src/libg++-2.2/libg++/../gcc/ -g  -I. -I.. -I. -I./../src -I./../g++-include -c -I/local/sys/src/libg++-2.2/libg++/../gcc/include sbufvform.C
>sbufvform.C: In method `int  streambuf::vform (const char *, char *)':
>sbufvform.C:248: warning: implicit declaration of function `__builtin_alignof'
>sbufvform.C:248: parse error before `4'
>sbufvform.C:248: parse error before `4'
>sbufvform.C:248: parse error before `['
>#...
>#similarly for lines 260, 300, 309, 323,370, 380, 392, 398, 422, 427
>#...
>gmake[1]: *** [sbufvform.o] Error 1
>gmake: *** [in-io] Error 1
>95 rooney>^D
>script done on Mon Jul 20 15:02:27 1992

I have traced this to the macro expansion of va_arg in /usr/include/stdarg.h,
which looks like this:

>        /* va_arg aligns list and points past data */
>#define va_arg(list, mode) ((mode *)(list =\
> (va_list) ((((int)list + (__builtin_alignof(mode)<=4?3:7)) &\
> (__builtin_alignof(mode)<=4?-4:-8))+sizeof(mode))))[-1]

which results in line 248 of sbufvform.C being translated into:

>			if ((width =  ((int *)(ap = (va_list) ((((int)ap + (__builtin_alignof(int)<=4?3:7)) & (__builtin_alignof(int)<=4?-4:-8))+sizeof(int))))[-1]) >= 0)

The implicit declaration error is (I believe) because the 'ccom' part of DEC's
C compiler contains '__builtin_alignof' (detected via a 'strings'), while
gcc/g++ does not.  The string appears in no other part of the compiler, nor
in any other file under /usr/include[/sys].

a) Am I doing anything wrong?
b) I expect the problem is the way DEC has their stdarg.h written (go figure).
   Is this inconsistent with other OS's stdarg.h's? (I have no other boxes
   to compare to)
c) Any clues?  Anyone?

|  . . ) /   | It breathes fire. -more-  | Jim Niemira
| (_(_/  |   | It breathes fire. -more-  | Senior SysOp, Frontier Sci
|    (   '   | You are not happy. -more- | niemira@karloff.fstrf.org

Newsgroups: gnu.g++.lib.bug
From: medin@cod.nosc.mil (Ted Medin)
Subject: HELP size_type failure with libg++-2.2
Keywords: size_type vax
Organization: Naval Ocean Systems Center, San Diego
Distribution: gnu
Date: Wed, 22 Jul 1992 17:26:00 GMT

 Im a bit confused about what "SIZE_TYPE" should be for our dec vax running
bsd unix.
 I gened gcc 2.2.2 using  "configure vax-dec-bsd".
 I gened libg++ 2.2 using "configure vax-dec-bsd".

but the libg++ fails because it thinks SIZE_TYPE should be:

long int           - while gcc built-in thinks SIZE_TYPE should be:

long unsigned int

 So which is right or where did i go wrong?????

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: make check in tests/, warnings from test_h.cc: should I be worried?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 08:27:53 GMT

> warning, Fix24_shift not found in original or external symbol tables, value defaults to 0

This is an error message from gcc/mips-tfile.c.  It should only affect
debugging.  I don't have time to look it it now.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: make check on NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 08:23:24 GMT

> ld: multiple definitions of symbol _strtod
>     ../libg++.a(dtoa.o) definition of _strtod in section (__TEXT,__text)
>     /lib/libsys_s.a(strtod.o) definition of absolute _strtod (value0x5003068)

I have renamed strtod() to _Xstrtod() to avoid this problem.
	
	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: srg@scvs5.CSelt.stet.IT
Subject: make check in tests/, warnings from test_h.cc: should I be worried?
Reply-To: Marco.Mesturino@cselt.stet.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 18:28:49 GMT

Hardware:	DECstation 3100
OS:		Ultrix 4.2
libg++ version:	2.2
gcc version:	2.2.2 (w/fixincludes installed)
configure parms:	dec3100 --prefix=/usr/local
(for both gcc and libg++)
----
DESCRIPTION.
When running "make check" I obtain some warnings:
----
cd /usr/users/srg/gnu/libg++-2.2/
make check CFLAGS="-g -O2" CC="gcc"
	(...)
cd tests ; make check ::: AR=ar  AR_FLAGS=qc  CC=gcc  CFLAGS=-g -O2  RANLIB=ranlib  LOADLIBES=  LDFLAGS=  MAKEINFO=makeinfo  XTRAFLAGS=
rm -f *.out
gcc -g -O2 -nostdinc++ -I. -I.. -I./../iostream  -I./../src -I./../g++-include  -c test_h.cc
warning, Fix24_shift not found in original or external symbol tables, value defaults to 0
	(...)
and then on for:
Fix24_fs Fix24_mult Fix24_div Fix24_max Fix24_min Fix24_msb Fix24_lsb
Fix24_m_max Fix24_m_min Fix48_fs Fix48_max Fix48_min Fix48_div_u 
Fix48_div_l Fix48_msb Fix48_lsb Fix48_m_max Fix48_m_min 
----
These seem not to be expected warnings, are they?
Let me know if other data are needed.

					Marco
----<Disclaimer: I work for my company, but I speak for myself ONLY>
Dr. Marco Mesturino,         |C.S.E.L.T.         |fax:+3911-228-6862
Marco.Mesturino@CSELT.STET.IT|v. Reiss-Romoli,274|pho:+3911-228-6785
      Mesturino@CSELT.STET.IT|10148 Torino  ITALY|tlx:220539        
-----

Newsgroups: gnu.g++.lib.bug
From: tietz@gmd.DE (Christoph Tietz)
Subject: Re: strange behavior of __outfloat
Organization: GMD, Sankt Augustin, Germany
Distribution: gnu
Date: Mon, 20 Jul 1992 15:35:57 GMT

Sorry. Nearly all the important information was left out of my report:
We use G++-2.2.2 and libg++2.2 on a SPARCstation4 with SunOS 4.1.2

Newsgroups: gnu.g++.lib.bug
From: niemira@karloff.fstrf.org (niemira.jim)
Subject: Re: losing compile ...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 13:29:53 GMT

	*Sigh*.  Perhaps if I included the gcc include files in the include
path, things would compile a little better... I hate when I'm stupid.
|  . . ) /   | It breathes fire. -more-  | Jim Niemira
| (_(_/  |   | It breathes fire. -more-  | Senior SysOp, Frontier Sci
|    (   '   | You are not happy. -more- | niemira@karloff.fstrf.org

Newsgroups: gnu.g++.lib.bug
From: pduncan@surya.CSc.ti.COM (Phil Duncan)
Subject: libg++ problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 15:40:09 GMT

  On page 23 of the libg++ documentation (first page of Chap. 6)
are directions for using void* coercion to create container classes
that share code.  I tried creating a container class using
this mechanism and am getting a compiler error.  Below is
the pertinent code and error message.

-------------------------------------------------------------------------

typedef Edge* EdgePtr;
typedef void* Ptr;

class PtrBag {          // created by "genclass Ptr val Bag"

public:
  virtual Ptr&          operator () (Pix i) = 0; // access item at i

};

class PtrSLBag : public PtrBag {      // created by "genclass Ptr val SLBag"

public:
  Ptr&          operator () (Pix i);

};

class EdgePtr_bag : public PtrSLBag {    // my derived class

  public:

    EdgePtr& operator()(Pix i) { return (EdgePtr&)PtrSLBag::operator()(i); }
};


---------------------------------------------------------------------------

EdgePtr_bag.h:12: conflicting return type specified for virtual function `class
Edge* EdgePtr_bag::operator () (void *)'

  Any help, insight, comments will be greatly appreciated.

					Thanks,
						Phil D.

-- 
Phillip J. Duncan
duncan@janet.ucla.edu               ...!(uunet,ucbvax)!janet.ucla.edu!duncan
UCLA EE Dept.  56-122 Engineering IV, Los Angeles,  CA 90024   (310)206-4465

Newsgroups: gnu.g++.lib.bug
From: terryh@unixhub.slac.stanford.edu (Terry Hung)
Subject: libg++-2.2 on NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 02:03:41 GMT

After typed "configure -v next" from top directory of libg++-2.2, I did a
"make all CC=gcc" from the same directory. Went into trouble in 
libg++/iostream:  

 gcc -g -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c  procbuf.C
 In method `int  procbuf::sys_close ()':
 incompatible pointer types for argument 0 of `int  wait (union wait*)' 

Maybe I missed some articles on gnu.g++.lib.bug regarding this, help will
be greatly appreciated! (maybe we can save a few month worth of news
items into a  tar file, e.g. libg++-2.2.news, to help users who may run into 
same traps, the idea of using a rotating news board is not very realistic,
it sure make me dizzy).

Xref: sparky gnu.g++.lib.bug:441 gnu.g++.bug:1214
From: lupine!segfault!rfg@uunet.uu.net (Ron Guilmette)
Newsgroups: gnu.g++.lib.bug,gnu.g++.bug
Subject: Re: patches for libg++-2.1 on i386 SVR4
Date: 21 Jul 92 06:34:57 GMT
Followup-To: gnu.g++.bug
Organization: Ron Guilmette Computing
To: vallone@grail.com
Cc: bug-g++@prep.ai.mit.edu, bug-libg++@prep.ai.mit.edu

In article <1992Jun26.120942.9011@grail.com> `vallone' wrote:
>Here are patches for getting libg++-2.1 to compile on an
>i386 running SVR4.
>
>I used gcc-2.2.2
>
>untar the sources, cd into libg++-2.1 and type
>
>./configure i386-sysv4
>
>cd ..
>
>patch -p < patchfile
>
>cd libg++-2.1
>
>make
>
>
>The main changes were to Makefiles.  I changed all -g to be -O
>this corrects the cc1plus dying from signal 6 (bugs in dwarfout.c)

The bug was not in dwarfout.c.  It was in the g++ front end, which
was incorrectly setting DECL_IGNORED_P.

-- 

// Ron ("Loose Cannon") Guilmette
// Internet: rfg@ncd.com      uucp: ...uunet!ncd.com!rfg
// New new motto:  Quality control is a state of mind.
Newsgroups: gnu.g++.lib.bug
From: terryh@unixhub.slac.stanford.edu (Terry Hung)
Subject: libg++ on NeXT
Keywords: libg++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 22 Jul 1992 16:33:37 GMT

I tried to build libg++-2.2 with gcc-2.2.2 on NeXT, and got the following:

gcc -g -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c  procbuf.C
procbuf.C: In method `int  procbuf::sys_close ()':
procbuf.C:91: incompatible pointer types for argument 0 of `int  wait (union wait*)'

Any suggestions?
-- 
Terry Hung
Stanford Linear Accelerator Center

terryh@unixhub.slac.stanford.edu

Newsgroups: gnu.g++.lib.bug
From: freeman@devon.prepnet.com (Jon Freeman)
Subject: libg++ 2.2 problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 20:47:24 GMT

I built libg++ version 2.2 on a HP 9000/730 (running HP-UX 8.05)
using GCC version 2.2.2.  Whenever I try to link libg++.a with
any C++ program, no matter how trivial, I always get the following
error from the linker:

ld: Unsatisfied symbols:
   _vt.filebuf (data)


For example, here's what happens when I try to install libg++-2.2:
-----------------------------------------------
...
        cd test-install; make test-90S  \
            CC=/usr/local/bin/gcc COMPILE_FLAGS="" LIBS=-lg++
        ./foo_main.run > foo_main.out
        diff ./expected.out foo_main.out >foo_main.diff
        /usr/local/bin/gcc   -c a.cc
        /usr/local/bin/gcc -o a  a.o -lg++
ld: Unsatisfied symbols:
   _vt.filebuf (data)
collect: /bin/ld returned 1 exit status
*** Error code 1
 
Stop.
*** Error code 1
 
Stop.
*** Error code 1
 
Stop.
-----------------------------------------------

What is the cause of this error?
				Thanks,
				 Jon
				 (freeman@devon.prepnet.com)

Newsgroups: gnu.g++.lib.bug
From: tietz@gmd.DE (Christoph Tietz)
Subject: strange behavior of the __outfloat routine
Organization: GMD, Sankt Augustin, Germany
Distribution: gnu
Date: Mon, 20 Jul 1992 12:48:29 GMT

The following test program shows the different behavior of printf and
cout.form on the same numbers:

-------------------------------------------------------------------------------
// This may look like C code, but it is really -*- C++ -*-

#include <stream.h>
#include <stdio.h>

int main () {

  printf ("Output for the format %%5.0f :\n");
  printf	("printf   : <%5.0f>\n", 10.0);
  printf	("printf   : <%5.0f>\n", 600.0);
  printf	("printf   : <%5.0f>\n", 2010.0);
  printf	("printf   : <%5.0f>\n", 10000.0);
  cout << form	("cout.form: <%5.0f>\n", 10.0);
  cout << form	("cout.form: <%5.0f>\n", 600.0);
  cout << form	("cout.form: <%5.0f>\n", 2010.0);
  cout << form	("cout.form: <%5.0f>\n", 10000.0);
}
-------------------------------------------------------------------------------

The problem seems to come up around line 107 in outfloat.C, where the number
of trailing zeroes is calculated and used to decide, whether a decimal point
should be printed. It seems to be neglected, that the precision given with e,
E and f-Formats denotes the number of digits to appear after the decimal
point and NOT the total number of significant digits. It may be connected to
the behavior of the expression: precision-(useful_digits-decpt) that gives
strange results, if decpt is greater than useful_digits.
>From there on numbers get out of line quite soon. In line 121 the unpadded
width is calculated wrongly because show_dot was set erroneously, and in line
155 then the trailing digits that were printed correctly before the decimal
point are repeated after the decimal point, giving the following quite
bizarre results:

Output for the format %5.0f :
printf   : <   10>
printf   : <  600>
printf   : < 2010>
printf   : <10000>
cout.form: <  10.0>
cout.form: < 600.00>
cout.form: <2010.0>
cout.form: <10000.0000>

I could not find a simple patch that would work for all possible floating
point formats so I can regrettably only state the problem here. Perhaps
somebody already has a fix??

                                                       Christoph Tietz

Newsgroups: gnu.g++.lib.bug
From: srg@scvs5.CSelt.stet.IT
Subject: make check in etc/lf, ld error
Reply-To: Marco.Mesturino@cselt.stet.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 18:19:35 GMT

Hardware:	DECstation 3100
OS:		Ultrix 4.2
libg++ version:	2.2
gcc version:	2.2.2 (w/fixincludes installed)
configure parms:	dec3100 --prefix=/usr/local
(for both gcc and libg++)
----
DESCRIPTION.
When running "make check" it stops with an error from ld:
----
cd /usr/users/srg/gnu/libg++-2.2/
make check CFLAGS="-g -O2" CC="gcc"
	(...)
cd lf; make check ...
	(...)
gcc lf.o entry.o screen.o option.o  directory.o sort.o Dirent.o -o lf ../../libg++.a -ltermcap
__new_handler: both a large and small symbol (possible gp relocation errors may result)
ld:
entry.o: gp relocation out-of-range in .text section for relocation entry 22 for symbol: __new_handler
entry.o: above gp relocation entry for non .sdata or .sbss symbol
gp relocation out-of-range for small data or bss by,
              0 in the positive direction,
           3696 in the negative direction.
All data will fit into the global pointer area
Best -G num value to compile all -count'ed objects
creating lf with is 1024 (or greater)
Best -G num value calculation reliable only if all
-count'ed objects were compiled with -G num greater or
equal to maximum size of a literal pool item (8).
collect: /usr/bin/ld returned 1 exit status
*** Error code 1
-----
This is a short run with gdb 3.5 (4.6 not yet available):
-----
Current directory is /usr/users/srg/gnu/libg++-2.2/libg++/etc/lf/
Reading symbols from lf...done.
(gdb) run -h
Starting program: /usr/users/srg/gnu/libg++-2.2/libg++/etc/lf/lf -h
usage: /usr/users/srg/gnu/libg++-2.2/libg++/etc/lf/lf [-ahl] [directory]

Program exited with code 01.
(gdb) run .
Starting program: /usr/users/srg/gnu/libg++-2.2/libg++/etc/lf/lf .

Program received signal 5, Trace/BPT trap
0x4002c8 in Entry_Handler::print_entries (::t=0x7fffbd40, 
    class_name=0x100015c0 "Regular") at entry.cc:18
(gdb) where
#0  0x4002c8 in Entry_Handler::print_entries (::t=0x7fffbd40, 
    class_name=0x100015c0 "Regular") at entry.cc:18
#1  0x400b88 in Directory_Handler::print (::t=0x9) at directory.cc:88
#2  0x4001f4 in main (argc=2, argv=0x7fffbdb4) at lf.cc:21
(gdb) quit
The program is running.  Quit anyway? (y or n) y
-----
Let me know if other data are needed.

					Marco
----<Disclaimer: I work for my company, but I speak for myself ONLY>
Dr. Marco Mesturino,         |C.S.E.L.T.         |fax:+3911-228-6862
Marco.Mesturino@CSELT.STET.IT|v. Reiss-Romoli,274|pho:+3911-228-6785
      Mesturino@CSELT.STET.IT|10148 Torino  ITALY|tlx:220539        
-----

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: problem compiling libg++-2.2: gcc not specified!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 09:35:14 GMT

The defaults for CC (and CFLAGS) need re-thinking.
For now, I suggest just doing:
	make CC=gcc

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug