HDTenEightyP/NetNews huggingface dataset:
Followup-To: gnu.g++.lib.bug,gnu.g++.help,comp.sys.hp

I need some help to compile libg++-2.3 on Hp9000/720 HP-UX
I got the HP binaries of gcc-2.3.1 from jaguar.cs.utah.edu (including gas)

I run `configure hp9k720' them `make all'.
The compilation dies in libg++/src
	gcc -g -O -nostdinc++ -I.. -I. -I./../iostream   -c BitSet.cc
/usr/tmp/cca13777.s:unknown:FATAL:XXX symbol_value: scope=0, type=1073799168

I have the same error in many other files :
src/BitString.cc, src/Fix.cc, iostream/strstream.C, iostream/PlotFile
I got discouraged and stopped compiling at this point.


Here is a more verbose output of what is happening :

	gcc -v -g -O -nostdinc++ -I.. -I. -I./../iostream   -c BitSet.cc
Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/cpp -lang-c++ -nostdinc++ -v -I.. -I. -I./../iostream -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D_HPUX_SOURCE -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D___HPUX_SOURCE__ -D__hppa -D__hp9000s800 -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -D___HPUX_SOURCE -D__OPTIMIZE__ -g BitSet.cc /usr/tmp/cca14464.i
GNU CPP version 2.3.1 (hppa)
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/cc1plus /usr/tmp/cca14464.i -quiet -dumpbase BitSet.cc -g -O -version -o /usr/tmp/cca14464.s
GNU C++ version 2.3.1 (hppa) compiled by GNU C version 2.3.1.
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/as -o BitSet.o /usr/tmp/cca14464.s
/usr/tmp/cca14464.s:unknown:FATAL:XXX symbol_value: scope=0, type=1073799168


First, I thought that I didn't have the right version of gas but it is said
to be working equally well on 700 and 800 series.

Isn't this version of gcc supposed to be working on hp9k720 ? I only see
reference to hp9k8 on the compiler output, though the binaries are stored
in gcc-lib/hp700-hpux.

I saw quite a few patches for libg++2.2 on hp. Do I have to go through all
of them and try to figure out what is still to be applied on libg++2.3 ?

I would appreciate any help.
Thanks.

Gilles

Newsgroups: gnu.g++.lib.bug
From: probreak@matt.ksu.ksu.edu (James Michael Chacon)
Subject: _G_config.h gets values wrong
Organization: Kansas State University
Distribution: gnu
Date: Thu, 17 Dec 1992 15:17:07 GMT

When compiling libg++2.3 for the i386-linux I get error messages about
types being wrong for some function prototypes. I traced this down to
_G_config.h having the wrong declarations for the default system types.
Changing these to the correct values seemed to solve the problem, but
otherwise it won't compile.

The gcc version I am using is 2.3.2 (ss-921205).

James

Newsgroups: gnu.g++.lib.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: installation problem w/ libg++-2.3 on SS2, SunOS 4.1.1
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Mon, 14 Dec 1992 18:12:24 GMT

I know there's probably a quick and easy fix. I've looked everywhere I
could find in both gcc-2.3.2 and libg++-2.3, and on this and the gcc
newsgroups and couldn't find anything. I remember seeing something on
this a while ago, but the article(s) must have expired here.  Help is
greatly appreciated.

I'm installing libg++-2.3 on a SS2, SunOS4.1.1 where gcc-2.3.2 is
already installed, and yes, I did run "make install-fixincludes"
during gcc installation.  I'm getting the following errors when I try
to build libg++-2.3:

gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c Obstack.cc
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c builtin.cc
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c regex.cc
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c Regex.cc
gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c String.cc
In file included from String.cc:28:
/depot/gnu/plat/lib/gcc-lib/sun4/2.3.2/include/limits.h:11: syslimits.h: No such file or directory
*** Error code 1
make: Fatal error: Command failed for target `String.o'
Current working directory /auto/depot/gnu/src/libg++-2.3/libg++/src
*** Error code 1
make: Fatal error: Command failed for target `in-src'
Current working directory /auto/depot/gnu/src/libg++-2.3/libg++
*** Error code 1
make: Fatal error: Command failed for target `all-libg++'


Any ideas? Its gotta be something simple, right?
Thanks.

-Barry

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: out << flush v. out.flush()
Organization: Minimal
Distribution: gnu
Date: Mon, 14 Dec 1992 18:56:38 GMT

ostream& ostream::flush() and ostream& flush(ostream &) do different
things; the first one discards everything which hasn't been output, while
the second spits it all out.  Are both the correct behavior?

--
Jason Merrill					jason@jarthur.claremont.edu

Newsgroups: gnu.g++.lib.bug
From: epperly@osnome.che.wisc.edu (Tom Epperly)
Subject: Libg++ 2.3 tCurses fails on DECstation 3100
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 06:01:28 GMT

gcc version 2.3.2
DECstation 3100
Ultrix V4.2
Libg++ 2.3

When I run libg++2.3/libg++/tests/tCurses, after it prints the
boundary of the screen and the box in the center with the X in it, it
the starts to print text from the termcap file onto the screen.  The
termcap text gets mixed in with what's supposed to be there.  This
happened while I was logged in from a vt100 terminal.

I tried running tCurses again from an xterm, and it worked fine.  On a
hunch, I tried doing an 'eval "`resize`"' on the vt100.  After doing
the resize, tCurses worked fine.  I was able to repeat the error by
doing an 'unsetenv TERMCAP'.  The error also appeared on the xterm
after doing an 'unsetenv TERMCAP'.  It seems that tCurses only works
when TERMCAP is set to the specific termcap entry.

All other tests from 'make check' worked fine.  Thanks for the
library!

				Tom
--
-------------------------------------------------------------------------------
Tom Epperly	University of Wisconsin-Madison		Chemical Engineering
(608) 262-8264	epperly@osnome.che.wisc.edu		Graduate Student
Member of the League for Programming Freedom(fighting software monopolies)
	For more info contact me or lpf@uunet.uu.net.
If you feel you must flame, please send email rather than posting.
-------------------------------------------------------------------------------

Newsgroups: gnu.g++.lib.bug
From: videau@cabret.cica.fr (Pierre VIDEAU)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 16:43:43 GMT

I can't install libg++-2.3 on my NeXt V3R3 with gcc-2.3.2

cause of :   ___DTOR_LIST__    see below =>

gcc -o gperf new.o options.o iterator.o main.o gen-perf.o key-list.o list-node.o hash-table.o bool-array.o read-line.o std-err.o version.o  ../../libg++.a
ld: options.o symbol 317 (___DTOR_LIST__) has unknown n_type field (0x16)

Do you know this problem ?

Cheers,
PeV

Newsgroups: gnu.g++.lib.bug
From: eggert@bi.TWinsun.COM (Paul Eggert)
Subject: minor permissions problem in libg++ 2.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Dec 1992 02:10:15 GMT

Two files in libg++ 2.3 are distributed with the executable bit turned on,
even though they're not executable.  The following shell commands patch this:

	chmod a-x libg++/etc/PlotFile3D/PlotFile3D.info
	chmod a-x libg++/proto-kit/prototype.dependencies

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Patch for libg++-2.3 makefiles
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 16:45:58 GMT

Thanks for your suggestions.

> The first two patches make the C and C++ compilers for the target default
> to the same as those for the host, rather than to $(CC) and gcc.

Seems reasonable; I'll put it in if some other people agree.

> The next patch allows libg++ to be built in parallel

I put it in; it seems to work.  (Specifically, without causing libg++.a
to be re-built when everything is up-to-date.)

> The final patch makes the C++ compiler used for test-install the same as
> the one used for the build.

This one I disagree with.  The whole point is to test that the *installed*
compiler can find the librray we have just installed - i.e. that the
installed compiler and library are consistent and can work with each other.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: bug in g++ 2.3.2 or libg++ 2.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 05:21:45 GMT

> In file included from /usr/local/lib/g++-include/iostream.h:24, from /usr/local/ lib/g++-include/stream.h:7, from /usr/local/lib/g++-include/String.h:26, from t. cc:2:
> /usr/local/lib/g++-include/streambuf.h:94: `append' redeclared as different kind of symbol
> int.List.h:87: previous declaration of `class intList append (class intList&, class intList&)'

Since the former definition of append is non-standard, and only
defined in "compatibily-mode" for the old stream.h, I suggest replacing
#include <stream.h> by #include <iostream.h> in String.h (and
most other places).  I don't know what will break.  I'll find out
for the next release ...

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: Re: installation problem w/ libg++-2.3 on SS2, SunOS 4.1.1
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Wed, 16 Dec 1992 19:22:29 GMT

I found the included article which gives a solution.  Note that I had
to re-run configure before re-running 'make install-fixincludes', I
guess to regenerate the Makefile. gcc/libg++ is happy again...

-Barry

-------------------- snip snip --------------------
From: wilson@cygnus.com
Subject: gcc 2.3.2 syslimits.h problem
Date: Tue, 1 Dec 1992 18:36:34 GMT

This will make limits.h/syslimits.h work again.

Apply the patch, and then rerun `make install-fixincludes'.

Mon Nov 30 12:03:13 1992  Jim Wilson  (wilson@sphagnum.cygnus.com)

        * Makefile.in (INSTALLED_H): Add syslimits.h.

*** ../clean-gcc-2.3.2/Makefile.in      Wed Nov 25 20:43:52 1992
--- Makefile.in Mon Nov 30 11:56:19 1992
***************
*** 405,411 ****
      va-pa.h va-pyr.h va-sparc.h va-spur.h proto.h $(EXTRA_HEADERS)
  
  # All the header files that are installed for users from GCC itself.
! INSTALLED_H = float.h stddef.h stdarg.h varargs.h $(USER_H) limits.h
  
  # The files that "belong" in CONFIG_H are deliberately omitted
  # because having them there would not be useful in actual practice.
--- 405,412 ----
      va-pa.h va-pyr.h va-sparc.h va-spur.h proto.h $(EXTRA_HEADERS)
  
  # All the header files that are installed for users from GCC itself.
! INSTALLED_H = float.h stddef.h stdarg.h varargs.h $(USER_H) limits.h \
!     syslimits.h
  
  # The files that "belong" in CONFIG_H are deliberately omitted
  # because having them there would not be useful in actual practice.


Newsgroups: gnu.g++.lib.bug
From: atownley@mcs213k.cs.umr.edu
Subject: compile error for libg++2.3 on NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 02:30:42 GMT

I just downloaded the new version of libg++2.3 from the net and went
to install it on my NeXTcube running 2.1 Extended of NeXTSTEP (3.0
has yet to arrive) and it went along fine until the compiler got to
the template stuff in iomanip.h.  I am also using version 2.2.2 of
gcc to do all the compiling.

Here is the compile messages generated:
gcc -g -O -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c  outfloat.C
gcc -g -O -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c  iomanip.C
In file included from iomanip.C:23:
iomanip.h:61: parse error before `>'
iomanip.h:63: parse error before `>'
iomanip.h:141: semicolon missing after declaration of `smanip<int>'
iomanip.h: In function `int  setbase (int)':
iomanip.h:141: aggregate value used where an integer was expected
iomanip.h: In function `class smanip<int> setfill (int)':
iomanip.h:142: warning: dbx info for template class methods not yet supported
iomanip.h: At top level:
iomanip.h:61: parse error before `>'
iomanip.h:63: parse error before `>'
iomanip.h:146: semicolon missing after declaration of `smanip<long unsigned int>
'
iomanip.h: In function `int  resetiosflags (long unsigned int)':
iomanip.h:146: aggregate value used where an integer was expected
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.
Excalibur#

Does anyone have any idea what might be the problem?  I configured the
system with configure next and checked that it had the right specs.

Thanks in advance,

Andrew S. Townley
atownley@cs.umr.edu
NeXTmail welcome!

Newsgroups: gnu.g++.lib.bug
From: gilles@osf.ORG (Gilles Benati)
Subject: libg++-2.3 with gcc-2.3.1 on HP9000/720
Organization: Open Software Foundation
Distribution: gnu
Date: Fri, 11 Dec 1992 20:46:57 GMT

(repost)

I need some help to compile libg++-2.3 on Hp9000/720 HP-UX
I got the HP binaries of gcc-2.3.1 from jaguar.cs.utah.edu (including gas)

I run `configure hp9k720' them `make all'.
The compilation dies in libg++/src
	gcc -g -O -nostdinc++ -I.. -I. -I./../iostream   -c BitSet.cc
/usr/tmp/cca13777.s:unknown:FATAL:XXX symbol_value: scope=0, type=1073799168

I get the same error in many other files :
src/BitString.cc, src/Fix.cc, iostream/strstream.C, iostream/PlotFile
I got discouraged and stopped compiling at this point.


Here is a more verbose output of what is happening :

	gcc -v -g -O -nostdinc++ -I.. -I. -I./../iostream   -c BitSet.cc
Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/cpp -lang-c++ -nostdinc++ -v -I.. -I. -I./../iostream -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D_HPUX_SOURCE -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D___HPUX_SOURCE__ -D__hppa -D__hp9000s800 -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -D___HPUX_SOURCE -D__OPTIMIZE__ -g BitSet.cc /usr/tmp/cca14464.i
GNU CPP version 2.3.1 (hppa)
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/cc1plus /usr/tmp/cca14464.i -quiet -dumpbase BitSet.cc -g -O -version -o /usr/tmp/cca14464.s
GNU C++ version 2.3.1 (hppa) compiled by GNU C version 2.3.1.
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.1/as -o BitSet.o /usr/tmp/cca14464.s
/usr/tmp/cca14464.s:unknown:FATAL:XXX symbol_value: scope=0, type=1073799168


First, I thought that I didn't have the right version of gas but it is said
to be working equally well on 700 and 800 series.

Isn't this version of gcc supposed to be working on hp9k720 ? I only see
reference to hp9k8 on the compiler output, though the binaries are stored
in gcc-lib/hp700-hpux.

I saw quite a few patches for libg++2.2 on hp. Do I have to go through all
of them and try to figure out what is still to be needed on libg++2.3 ?

By the way, is it necessary to run fixinclude on hp ?

I would appreciate any help.
Thanks.

Gilles

Newsgroups: gnu.g++.lib.bug
From: mj@dfv.rwth-aachen.DE (Martin Junius)
Subject: Bug in libg++ 2.3
Organization: Communication Networks
Distribution: gnu
Date: Tue, 15 Dec 1992 16:23:22 GMT

One bug in the iostream part of libg++ I posted already for 
libg++ 2.2 is still there in version 2.3:

Using a iostream (or a derived) class for bidirectional I/O 
doesn't work properly because the flag _S_CURRENTLY_PUTTING isn't 
properly reset during a filebuf read after a write operation.

Here's the fix: (File libg++-2.3/libg++/iostream/filebuf.C)

*** filebuf.C-ORIG	Mon Nov 23 23:07:11 1992
--- filebuf.C	Mon Dec 14 13:05:09 1992
***************
*** 255,260 ****
--- 255,262 ----
  	if (do_flush()) return EOF;
  #endif
  
+     switch_to_get_mode();
+ 
      _G_ssize_t count = sys_read(base(), ebuf() - base());
      if (count <= 0) {
  	if (count == 0)

Martin
-- 
 _____ _____
|     |___  |   Martin Junius           FIDO:      2:242/6.1
| | | |   | |   Communication Networks  Internet:  mj@dfv.rwth-aachen.de
|_|_|_|@work|   Aachen U of Technology  Phone:     ++49-241-8790220 (voice)

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Patch for libg++-2.3 makefiles
Organization: Minimal
Distribution: gnu
Date: Sat, 12 Dec 1992 02:56:41 GMT

The first two patches make the C and C++ compilers for the target default
to the same as those for the host, rather than to $(CC) and gcc.

The next patch allows libg++ to be built in parallel (with the -j option to
GNU make); previously the dependencies were not indicated, so it would try
to compile stuff in src while it was creating _G_config.h, which didn't
work.

The final patch makes the C++ compiler used for test-install the same as
the one used for the build.

*** Makefile.in.orig	Thu Dec  3 21:56:05 1992
--- Makefile.in	Fri Dec 11 21:50:35 1992
***************
*** 89,95 ****
      echo $${rootme}/gcc/gcc -B$${rootme}/gcc/; \
    else \
      if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \
!       echo $(CC); \
      else \
        t='$(program_transform_name)'; echo gcc | sed -e '' $$t; \
      fi; \
--- 89,95 ----
      echo $${rootme}/gcc/gcc -B$${rootme}/gcc/; \
    else \
      if [ "$(host_canonical)" = "$(target_canonical)" ] ; then \
!       echo $(CC_FOR_BUILD); \
      else \
        t='$(program_transform_name)'; echo gcc | sed -e '' $$t; \
      fi; \
***************
*** 100,106 ****
      echo $${rootme}/gcc/gcc -B$${rootme}/gcc/; \
    else \
      if [ "$(host_cpu)-$(host_vendor)-$(host_os)" = "$(target_cpu)-$(target_vendor)-$(target_os)" ] ; then \
!       echo gcc; \
      else \
        t='$(program_transform_name)'; echo gcc | sed -e '' $$t; \
      fi; \
--- 100,106 ----
      echo $${rootme}/gcc/gcc -B$${rootme}/gcc/; \
    else \
      if [ "$(host_cpu)-$(host_vendor)-$(host_os)" = "$(target_cpu)-$(target_vendor)-$(target_os)" ] ; then \
!       echo $(CXX_FOR_BUILD); \
      else \
        t='$(program_transform_name)'; echo gcc | sed -e '' $$t; \
      fi; \
*** libg++/Makefile.in.orig	Wed Dec  9 17:38:32 1992
--- libg++/Makefile.in	Fri Dec 11 21:50:36 1992
***************
*** 192,202 ****
  	$(RANLIB) $(TARGETLIB)
  	@touch stamp-$(TARGETLIB)
  
! in-src:
  	@rootme=`pwd`/ ; export rootme ; cd src ; \
  		$(MAKE) $(FLAGS_TO_PASS)
  
! in-io:
  	@rootme=`pwd`/ ; export rootme ; cd $(IO_DIR) ; \
  		$(MAKE) $(FLAGS_TO_PASS) stamp
  
--- 192,204 ----
  	$(RANLIB) $(TARGETLIB)
  	@touch stamp-$(TARGETLIB)
  
! src/stamp: in-src ;
! in-src: _G_config.h
  	@rootme=`pwd`/ ; export rootme ; cd src ; \
  		$(MAKE) $(FLAGS_TO_PASS)
  
! $(IO_DIR)/stamp: in-io ;
! in-io: _G_config.h
  	@rootme=`pwd`/ ; export rootme ; cd $(IO_DIR) ; \
  		$(MAKE) $(FLAGS_TO_PASS) stamp
  
***************
*** 319,325 ****
  		fi ; \
  	done
  	cd test-install; $(MAKE) $(TEST_INSTALL) \
! 	    CXX=$(bindir)/gcc COMPILE_FLAGS="" LIBS=-lg++
  
  ###**######################################################################
  #
--- 321,327 ----
  		fi ; \
  	done
  	cd test-install; $(MAKE) $(TEST_INSTALL) \
! 	    "CXX=$(CXX)" COMPILE_FLAGS="" LIBS=-lg++
  
  ###**######################################################################
  #

Newsgroups: gnu.g++.lib.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: too-long filenames
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 10:42:43 GMT

The manual doesn't give a bug-reporting address.  (At least in 2.2, I
confess I didn't check 2.3.)

There are a number of files in the libg++ 2.3 distribution that are too
long for system V:

tar: Could not create file libg++-2.3/libg++/etc/PlotFile3D/PlotFile3D.info : Filename too long
tar: Could not create file libg++-2.3/libg++/gperf/tests/expected.ada-pred : Filename too long
tar: Could not create file libg++-2.3/libg++/gperf/tests/expected.ada-res : Filename too long
tar: Could not create file libg++-2.3/libg++/gperf/tests/expected.modula : Filename too long
tar: Could not create file libg++-2.3/libg++/gperf/tests/expected.pascal : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/file_types.hierarchy : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/file_types.includes.h : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/file_types.operation.h : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/file_types.type.h : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/genclass.extnsn : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/make-source-dependencies : Filename too long
tar: Could not create file libg++-2.3/libg++/proto-kit/prototype.dependencies : Filename too long
tar: Could not create file libg++-2.3/libg++/vms/GXX_MAIN_SHR.MAR : Filename too long
tar: Could not create file libg++-2.3/libg++/vms/VMS-BUILD-LIBGXX.COM : Filename too long
tar: Could not create file libg++-2.3/libg++/vms/VMS-INSTALL-LIBGXX.COM : Filename too long
tar: Could not create file libg++-2.3/libg++/vms/VMS-TEST-LIBGXX.COM : Filename too long
tar: Could not create file libg++-2.3/libg++/vms/VMS_FIXINCLUDES.TPU : Filename too long
tar: Could not create file libg++-2.3/etc/install-texi.in : Filename too long
tar: Could not create file libg++-2.3/etc/substitute-strings : Filename too long

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Problem with libg++ 2.3 build
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 09:24:44 GMT

> gen-params isn't compatible with the GNU nm from binutils-1.9

I'm understanding you to really mean "gen-params isn't compatible with my
personally modified version GNU nm from binutils-1.9."  In that case,
you're on your own.  (In my opinion, it's a mistake for nm to do
demangling by default, though it is fine if there is a flag to demangle.)

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: pap@moscom.COM (Patrick Palmer)
Subject: question about .nf
Organization: Moscom Corp., E. Rochester, NY
Distribution: gnu
Date: Wed, 16 Dec 1992 21:59:37 GMT

I am attempting to source in a file while no fill and the source'd
file is filled in anyways.   Let me demonstrate:

.nf
.so test.c
.fi

The test.c file is read in and it is filled.  What I am wondering is
this supposed to happen and why?

Patrick

-- 
Patrick Palmer, pap@moscom.com         Avast Ye Pirates, Prepare to be Boarded!
PO Box 23322, Rochester, NY 14692          - Oliver Jones on his Banana Jr 2000

Newsgroups: gnu.groff.bug
From: whalley@fork.cs.fsu.edu (David Whalley)
Subject: grefer
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 05:28:28 GMT

I am currently using grefer with groff.  Do you know of
any canned ways of changing the way grefer generates
references (both in the text and the list at the end)?
There are a few with bib (ex: spe, stdn, etc.).
If not, are there any examples of changing the style
for a specific journal or proceedings?

Thanks,
Dave Whalley

Newsgroups: gnu.groff.bug
From: long@vax.ox.ac.uk (Neil J. Long)
Subject: groff compilation on SGI
Organization: Materials Department, University of Oxford
Distribution: gnu
Date: Fri, 11 Dec 1992 20:56:43 GMT

Hi
I am having problems getting groff-1.06 to compile on a SGI R4000 running 
Irix 4.05F, gcc 2.3.2 (finally worked).
The problem file is matherr.c (that's where it is stuck so far) in the 
libgroff directory.
The compiler message is (same for gcc as MIPS cc) 
matherr.c:28: dereferencing pointer to incomplete type
*** Error code 1

boink
I tried it with the SGI cc compiler first, but then thuoght it may work with 
the GNU compiler - much later still same problem, any fixes please or 
tips for installing groff on sgi's.
Thanks
Neil
	

Newsgroups: gnu.ghostscript.bug