HDTenEightyP/NetNews huggingface dataset:
Date: Fri, 21 Aug 92 11:10:41 MDT
From: lee@bones.et.byu.edu (Bruce Lee)
Newsgroups: gnu.g++.help
Distribution: world
Organization: Brigham Young University, Provo UT USA
Subject: gcc/g++-2.2.2 on HP9000/400 w/HPUX8.0



Has anyone successfully built gcc-2.2.2 on an HP 9000/400
running HPUX 8.0x?.  I need the full set of GNU development
tools, GCC, G++, and GDB.  I read that with HPUX 8.0 the native 
libraries are causing problems.  Thanks.

-- 
Bruce Owen Lee				|"We will pay the price
Brigham Young University		| But we will not count the cost"
College of Engineering & Technology	|  
Email: lee@bones.et.byu.edu		|		-- RUSH -- 
Xref: sparky gnu.g++.help:1128 comp.lang.c++:12504
From: tiemann@cygnus.com
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: Re: funny behaviour with extern "C" (was: Calling C++ from C)
Date: 18 Aug 92 02:38:47 GMT
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu


   Return-Path: help-g++-request@prep.ai.mit.edu
   To: help-g++@prep.ai.mit.edu
   Date: Tue, 18 Aug 1992 17:02:00 GMT
   Organization: European Organization for Nuclear Research, CERN
   From: veitch@vxcrna.cern.ch (Liz Veitch)
   Sender: help-g++-request@prep.ai.mit.edu
   Subject: funny behaviour with extern "C" (was: Calling C++ from C) 
   
   HI,
   
   I have a problem with calling C functions from C++, despite using the 
   recommended syntax. If I have a test C++ program as follows: 
   
   // TEST.CC
   
   extern "C" {
   void foo0();
   void Foo1();
   void FOO2();
   }
   
   
   main ( int argc, char **argv ) {
   
   foo0();
   Foo1();
   FOO2();
   }
   
   
   then I find that the linker correctly starts looking for foo0 in the
   link list, but the functions with capital letters in the name are 
   treated as if I hadn't used extern "C" :
   
   %LINK-W-NUDFSYMS, 3 undefined symbols:
   %LINK-I-UDFSYM,         FOO0
   %LINK-I-UDFSYM,         FOO1_800000X
   %LINK-I-UDFSYM,         FOO2_E00000X
   
   
   Has anyone seen this behaviour/feature/bug before?  And does anyone know 
   how to make it behave properly?
   
   Help!  I'm really stuck, because what I really want to do is add some
   Motif stuff, and who ever heard of a Motif function without capitals in
   the name?  There must be some way to stop this happening. ( I'm using
   GNU 2.2.2 on VAX/VMS. ) 
   
   Thanks in advance,
   Liz Veitch
   
Some enterprising young hacker thought it would be a capital idea to
handle case insensitivity this way.

Michael
Newsgroups: gnu.g++.help,comp.lang.c++
From: bothner@cygnus.com
Subject: Re: libg++-2.2 using HP's CC
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 15:14:18 GMT

Thank you for your report.  Of course, our primary goal is to
support g++, but I accept changes reduce dependencies on g++-specific
features or extensions.  However, changes to work around bugs
in a specific vendor's C++ compiler are less likely to get accepted.

> o HP CC doesnt support or >? or <? operators.
>         I worked around this by either conditionally compiling for __GNUG__
>	   or removing the code altogether.

Seems to have already been fixed.

> o HP CC doesn't inline as many constructs as g++, especially inlines with
>	return statements followed by other code

I'm not going to change these.  However, I'll consider "simplifications".
I.e. if 'return A ? B : C' is preferable to 'if (A) return B; else return C;'
I'm willing to re-write to use the former form.

> o HP CC doesn't allow the same default arguments to be speficied more than
>	once,

I fixed these, since here HP CC follows the ARM.

> o HP CC doesn't allow scoped typedefs with a class (e.g. ios::fmtflags)

These changes I ignored.  HP CC is boggy/obsolete in this respect.

o HP CC can't statically initialise classes - you have to make them into
>	structs !
>        I conditionally compiled around this with HPCC_NO_CLASS_INIT

This was no longer applicable.

> o HP CC only allows the keyword virtual to appear in a class declaration

Fixed this.

> o You need HP CC specific code to initialise vtables in strstrbufs.cc
>         I conditionally compiled around this with HPCC_VTBL_DECLARATION

Why doesn't the generic cront version work?  Is __vtbl__7filebuf
the wrong type?  If so, what?

> o HP CC get's confused by externally declared functions followed by their
>         [inline] implementations

No longer applicable.

> o HP CC doesn't support implicit casts from void * via assignment:
>        char *s = malloc(2); // doesn't work
>        char *s = (char*)malloc(2);     // does

I think these have been fixed (as gcc is more finicky now).

>        similarly
>        char *s = NULL; // doesn't NULL is void * 0
>        char *s = (char*)NULL;  // does

These I don't want to change.  If your compiler does not recognize
(void*)0 as a NULL pointer, redefine NULL as 0 instead.

The g++-include changes I don't think I want to bother with.
I'm more include to suggest using Ron Guilmette's pupulate script,
which generates include stub files (with extern "C" { #include_next <XX.h> })
for system include file.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: casadei@verona.mit.edu (Stefano Casadei)
Subject: Simple bug in Vec.ccP
Keywords: Vec.ccP EQ ==
Organization: Massachusetts Institute of Technology
Distribution: gnu
Date: Thu, 20 Aug 1992 18:05:14 GMT

I have changed line 177 of file Vec.ccP. The original
version was comparing two <T> objects using operator ==
instead of the macro <T>EQ.

I hope I did it right.

Stefano


Newsgroups: gnu.g++.lib.bug
From: per@teknologi.agderforskning.NO (Per Sigmond)
Subject: Linker error on HP with libg++-2.2
Organization: Agderforskning
Distribution: gnu
Date: Fri, 14 Aug 1992 06:31:08 GMT

The loader cannot find the symbol _vt.filebuf. Error message:

	gcc -o tFile tFile.o ../../libg++.a
	ld: Unsatisfied symbols:
   	_vt.filebuf (data)

I use hppa with hpux 8.05 and gcc-2.2.2
The library compiler without errors or warnings (after some pathing og .h-files).

What's wrong?

-- 
Per Sigmond
Agderforskning Teknologi
Televeien 1
4890 Grimstad
Norway

Internet: Per.Sigmond@teknologi.agderforskning.no

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ installation problems on decstation 5000
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 14:22:58 GMT

You should also try setting CC explicitly:
	make CC=gcc

The next release will do things slightly differently.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Subject: Re: /usr/local/lib/g++-include installed with execute bit set.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 12:04:05 GMT

>> From:    bothner@com.cygnus
>> Subject: Re: /usr/local/lib/g++-include installed with execute bit set.
>> 
>> This is because $(INSTALL_DATA) is defined as install -c.
>> You can work around the problem using INSTALL=cp.
>> 
>> A fix requires changing the default definition for
>> INSTALL_DATA and/or INSTALL in the Makefiles,
>> something that means changing the GNU coding
>> standard.
>> 	--Per Bothner
>> Cygnus Support     bothner@cygnus.com

Needs must where the devil drives? Surely this could be done, to
alleviate this sort of problem?

Gordon,
____

Gordon Joly      Phone  +44 71 387 7050 ext 3703      FAX  +44 71 387 1397
Internet: G.Joly@cs.ucl.ac.uk        UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly
Computer Science, University College London, Gower Street, LONDON WC1E 6BT


Newsgroups: gnu.g++.lib.bug
From: chambers@wrist.sbp.dec.com (Mark Chambers)
Subject: Problem with libg++ make all - DECstaion 500/200
Reply-To: chambers@wrist.sbp.dec.com (Mark Chambers)
Organization: Digital Equipment Corporation
Distribution: gnu
Date: Wed, 19 Aug 1992 11:09:16 GMT

I am using a DECstation 500/200 ULTRIX 4.2 and have a problem
with libg++-2.2. I do 'configure decstation' then 'make all' and
the below happens.

I have no idea where to look or what to look at and any help is 
much appreciated. Thanks,
	Mark

# configure decstation
Created "Makefile" in /users/chambers/scr/kit using "config/mh-decstation"
# make all
echo "# !Automatically generated from ./functions.def" "- DO NOT EDIT!" >needed2
awk
grep '^DEFVAR(' < ./functions.def | sed -e '/DEFVAR/s|DEFVAR.\([^,]*\).*|/\1/ {
printf \"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' >>needed2.awk
grep '^DEFFUNC(' < ./functions.def | sed -e '/DEFFUNC/s|DEFFUNC.\([^,]*\).*|/\1/
 { printf \"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' >>needed2.awk
cc -Wf,-XNg1000 -c -g -I. -I./../include  ./dummy.c
(cc -Wf,-XNg1000  dummy.o  ) >errors 2>&1 || true
rm -f a.out dummy.o
echo "/* !Automatically generated from ./functions.def" "- DO NOT EDIT! */" >con
fig.h
awk -f needed2.awk <errors >>config.h
cc -Wf,-XNg1000 -c -g -I. -I./../include  basename.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  getopt.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  getopt1.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  obstack.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  spaces.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  concat.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  fdmatch.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  argv.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  strerror.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  strsignal.c
echo "# !Automatically generated from ./functions.def" "- DO NOT EDIT!" >needed.
awk
grep '^DEF(' < ./functions.def | sed -e '/DEF/s|DEF.\([^,]*\).*|/\1/ { printf \"
\1\.o " }|' >>needed.awk
awk -f needed.awk <errors >needed-list
echo  >>needed-list
cc -Wf,-XNg1000 -c -g -I. -I./../include  strdup.c
rm -rf libiberty.a
ar qc libiberty.a basename.o getopt.o getopt1.o obstack.o spaces.o concat.o fdma
tch.o argv.o strerror.o strsignal.o strdup.o
ranlib libiberty.a
make[1]: *** No way to make target `all'.  Stop.
make: *** [all-libg++] Error 1

--
Mark Chambers                      |     I didn't do it,
chambers@wrist.enet.dec.com        |     Nobody saw me do it,
#include "standard.disclaimer"     |     Can't prove I did it

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Problems compiling libg++ 2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 06:21:30 GMT

> Incidentally, the provided makefiles didn't execute 'touch stamp'
> correctly, so I had to create the stamp files myself

The question is "why not?".  It works in normal sequential
environments.  Since you're the one with the non-standard
parallel make, you're the one who has to figure out what the
problem is, and how to fix it.

> If I try to make _G_config.h, I get:
> 
> nm: dummy.o: cannot open
> nm: dummy.o: cannot open
> nm failed to find FUNC in dummy.o!
> ./utils/gen-params: -1: bad number

This might a a diferent (non-make) problem.  But note that:

> rootme=`pwd` ; export rootme; CC="`if [ -f ${rootme}/../gcc/gcc ] ; then echo
> ${rootme}/../gcc/gcc\\ -B${rootme}/../gcc/ ; else echo gcc ; fi` `if
> [ -f ${rootme}/../gcc/gcc ] ; then echo -I${rootme}/../gcc/include ; else
> echo ; fi`"; export CC; ./utils/gen-params  >tmp-params.h

is the first part of teh rule for making _G_config.h.  It's just
that the make is getting ahead of itself.  (I guess one could have
_G_config.h an explicit dependency of in-io and in-src.  Would
that help any?)

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: sheldon@kong.gsfc.nasa.gov (Roger Sheldon - AISS)
Subject: Re: Linker error on HP with libg++-2.2
Organization: Goddard Space Flight Center
Distribution: gnu
Date: Sun, 16 Aug 1992 23:33:57 GMT

In article <1992Aug14.063108.21613@ulrik.uio.no> per@teknologi.agderforskning.NO (Per Sigmond) writes:
>The loader cannot find the symbol _vt.filebuf. Error message:
>
>	gcc -o tFile tFile.o ../../libg++.a
>	ld: Unsatisfied symbols:
>   	_vt.filebuf (data)
>

I'm having a similar problem with gcc 2.1 and libg++ 2.0 under ISC 3.0
(a 386 Unix).

I successfully compiled libg++, but when I try to compile
a simple program like:
----
#include <iostream.h>
int main() { cout << "hello"; }
----
I get the following:

% g++ -v hello.c
Reading specs from /usr/local/lib/gcc-lib/i386-isc/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/i386-isc/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GN
UG__=2 -D__cplusplus -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 hello
.c /usr/tmp/cca03181.i
GNU CPP version 2.1 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386-isc/2.1/cc1plus /usr/tmp/cca03181.i -quiet -dumpbas
e hello.cc -version -o /usr/tmp/cca03181.s
GNU C++ version 2.1 (80386, ATT syntax) compiled by GNU C version 2.1.
 as -o hello.o /usr/tmp/cca03181.s
 ld /lib/crt1.o /usr/local/lib/gcc-lib/i386-isc/2.1/crtbegin.o -L/usr/local/lib/
gcc-lib/i386-isc/2.1/ -L/usr/local/lib/ hello.o -lg++ -lgcc -lc -lg -lgcc /usr/l
ocal/lib/gcc-lib/i386-isc/2.1/crtend.o /lib/crtn.o
undefined                       first referenced
 symbol                             in file
__vtbl__7filebuf                    /usr/local/lib/gcc-lib/i386-isc/2.1//libg++.
a
ld fatal: Symbol referencing errors. No output written to a.out



The problem is in iostream/stdstrbufs.C.  Here's an excerpt from
that file describing the problem:

-----
// To avoid problems depending on constructor order (and for
// efficiency) the standard streambufs (and streams) are
// constructed statically using C-style '{ ... }' initializers.
// Since you're not allowed to do this for structs that
// have virtuals, we define fake streambuf and stream classes
// that don't have any C++-isms, and initialize those.
// To initialize the vtable field of the standard filebufs,
// we use the expression 'vt_filebuf' which must evaluate to
// (the address of) the virtual function table for the
// filebuf class.
----

Thanks to anyone who can help us with this linking problem.

Roger

Newsgroups: gnu.g++.lib.bug
From: can@ansa.co.UK (Cosmos Nicolaou)
Subject: Re: libg++-2.2 using HP's CC
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 10:50:29 GMT

On Wed, 19 Aug 92 22:14:18 BST bothner@cygnus.com wrote:

>Thank you for your report.  Of course, our primary goal is to
>support g++, but I accept changes reduce dependencies on g++-specific
>features or extensions.  However, changes to work around bugs
>in a specific vendor's C++ compiler are less likely to get accepted.
seems a reasonable approach to me. However, it would be useful if there was a
README.nogcc file pointing out some of the likely problems.

>> o You need HP CC specific code to initialise vtables in strstrbufs.cc
>>         I conditionally compiled around this with HPCC_VTBL_DECLARATION
>
>Why doesn't the generic cront version work?  Is __vtbl__7filebuf
>the wrong type?  If so, what?

it's not the symbol that's the problem its the use of extern char vt_filebuf[1].

i.e. if you just refer to __vtbl__7filebut as a an extern char * then things seem
to work!

#if defined(HPCC_VTBL_DECLARATION)
// this may work on HP-UX using HP's CC
#define vt_filebuf (char*)__vtbl__7filebuf
#else
// This works for cfront.
#define vt_filebuf __vtbl__7filebuf
extern char vt_filebuf[1];
#endif

>>        similarly
>>        char *s = NULL; // doesn't NULL is void * 0
>>        char *s = (char*)NULL;  // does
>
>These I don't want to change.  If your compiler does not recognize
>(void*)0 as a NULL pointer, redefine NULL as 0 instead.
I soon realised that redefined NULL as 0 would have been the better fix to apply in
any case.

>The g++-include changes I don't think I want to bother with.
>I'm more include to suggest using Ron Guilmette's pupulate script,
>which generates include stub files (with extern "C" { #include_next <XX.h> })
>for system include file.
where can I get this script from?

I forgot to mention a couple of things:

i) all of the  tXX.C test programs need to explicitly return 0 when using HP CC.
I guess this is a side effect of the way that the initialisation is done. The HP
compiler detects main and when generating code inserats a call to _main as the
first thing in main. This differs from the normal practice of having a wrapper
which calls main and is the real entry point.

ii) the iostream/test tests don't work. In particular tFile and friends crash
before getting into main and the check-stdio tests don't work with I/O redirection
- i.e. they're output disappers when stdout/stderr are redirected, it doesn't go to
the screen and doesn't up in a file!

Also, what is the correct (ARM specified) behaviour wrt to enum names and top-level
functions? That is, are they allowed to clash or not?

enum a { b , c };
int b( char, char );

causes HP CC to complain. Is HP CC wrong here?

    	Cheers, Cos.

Cosmos Nicolaou

email:  can@ansa.co.uk (...uknet!ansa!can)      ANSA,
tel:    +44 223 323 010                         Poseidon House,
fax:    +44 223 359 779                         Castle Park,
                                                Cambridge,
                                                United Kingdom CB3 0RD
---

Newsgroups: gnu.g++.lib.bug
From: gunter@mayhem.berkeley.edu (Michial Gunter)
Subject: Minor ugliness in genclass Map && VHMap
Organization: /users/gunter/.organization
Distribution: gnu
Date: Sun, 16 Aug 1992 09:39:56 GMT

Why is the COUNT member of class Map declared "int".  It seems it
should be declared "unsigned int".  The SIZE member of the derived
VHMap class is declared "unsigned int".

They should be the same.  The reasonable choice seems to be "unsigned
int" (unless one of the other derived classes uses a negative value
for something.)



			mike

Newsgroups: gnu.g++.lib.bug
From: won@zanaga.cs.columbia.edu (Won Y. Kim)
Subject: libg++ install probs on amigaunix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 02:47:00 GMT

AS promised, this is the outfile from make runn after "configure
amigaunix) on the base libg++-2.2/ directory.

Any hints or suggestiona are greatly welcome!
gcc version on my home system is 1.40.5

	echo "# !Automatically generated from ./functions.def"\
	  "- DO NOT EDIT!" >needed2.awk
	grep '^DEFVAR(' < ./functions.def \
	 | sed -e '/DEFVAR/s|DEFVAR.\([^,]*\).*|/\1/ { printf
\"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' \
	 >>needed2.awk
	grep '^DEFFUNC(' < ./functions.def \
	 | sed -e '/DEFFUNC/s|DEFFUNC.\([^,]*\).*|/\1/ { printf
\"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' \
	 >>needed2.awk
	cc -c -g -I. -I./../include -DUSG -DUSGr4 ./dummy.c
	(cc  dummy.o  ) >errors 2>&1 || true
	rm -f a.out dummy.o
	echo "/* !Automatically generated from ./functions.def"\
	  "- DO NOT EDIT! */" >config.h
	awk -f needed2.awk <errors >>config.h
	cc -c -g -I. -I./../include -DUSG -DUSGr4 basename.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 getopt.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 getopt1.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 obstack.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 spaces.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 concat.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 fdmatch.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 argv.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 strerror.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 strsignal.c
	echo "# !Automatically generated from ./functions.def"\
	  "- DO NOT EDIT!" >needed.awk
	grep '^DEF(' < ./functions.def \
	    | sed -e '/DEF/s|DEF.\([^,]*\).*|/\1/ { printf \"\1\.o "
}|' \
	    >>needed.awk
	awk -f needed.awk <errors >needed-list
	echo  >>needed-list
	cc -c -g -I. -I./../include -DUSG -DUSGr4 index.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 sigsetmask.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 alloca.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 getpagesize.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 bcmp.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 bzero.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 bcopy.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 random.c
	cc -c -g -I. -I./../include -DUSG -DUSGr4 rindex.c
	rm -rf libiberty.a
	ar cq libiberty.a \
	  basename.o getopt.o getopt1.o obstack.o spaces.o concat.o
fdmatch.o argv.o strerror.o strsignal.o index.o sigsetmask.o alloca.o
getpagesize.o bcmp.o bzero.o bcopy.o random.o index.o rindex.o 
	true libiberty.a
	rootme=`pwd` ; export rootme; CC="cc `if [ -f
${rootme}/../gcc/gcc ] ; \
	then echo -I${rootme}/../gcc/include ; \
	else echo ; fi`"; export CC; \
	./utils/gen-params  >tmp-params.h
*** Error code 1 (bu21)
*** Error code 1 (bu21)

It also gave these erors onn the console
gcc: dummy.C linker innput file not used linking not done.
then
nm failed to find FUNC in dummy.o!
./utils/gen=params -1 bad number

Thanks
WYK!

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Help on linking g++-2.2.2 with -Bstatic, iostream.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 04:35:01 GMT

> This looks like libg++-2.1 still does not have the setprecision member
> function for ostream.

setprecison is not a member function, it is an io manipulator.
libg++-2.1 *does* have ios::precision(int) which can be used instead.

libg++-2.3 will have setprecision, and a complete template-based
iomanip.h (assuming a suitable fixed g++ is released before then).

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: per@teknologi.agderforskning.NO (Per Sigmond)
Subject: HP-PA hackers: anyone got libg++-2.2 working?
Organization: Agderforskning
Distribution: gnu
Date: Thu, 13 Aug 1992 21:39:15 GMT

Has anyone got libg++-2.2 to work properly on HP-PA? I've tried this,
but I get a lot of warnings during compile and the tests fail.
Any patches?

Thanks in advance.
Per.

-- 
Per Sigmond
Agderforskning Teknologi
Televeien 1
4890 Grimstad
Norway

Internet: Per.Sigmond@teknologi.agderforskning.no

Newsgroups: gnu.g++.lib.bug