HDTenEightyP/NetNews huggingface dataset:
From: bjornw@colargol.ai.mit.EDU (Bjoern Wennberg)
Subject: Question about path name expansion
Organization: Colargol, Trondheim College of Engineering
Distribution: gnu
Date: Fri, 20 Nov 1992 10:56:05 GMT

When I hit <TAB> as the first character typed, bash 'almost' hangs forever
trying to figure out which command I was trying to invoke. 

Is there a way to make bash recognise that a tab was the first character typed
and just do nothing ?

bjornw>

Bjoern.Wennberg@colargol.edb.tih.no

--
The sooner all the animals are dead, the sooner we'll find all their money.

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: problem with bash on hpux
Reply-To: chet@po.cwru.edu
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 08:51:24 GMT

> Program: bash 1.12.1
> OS: hpux 8.07
> Machine: HP 9000/730
> Compiler: HP C A.08.71
> ----------------------------------------------------------------------
> Problem: I do the following...
> 
> 	kobra> cd ~d91ali<Here I make TAB for completion>
> 			 <I break the competion with C-c>
> 	kobra> cd ~d91ali
> 	free: Called with already freed block argument
> 
> 	Tell root@kobra to fix this someday.
> 	Stopping myself...ABORT instruction (core dumped)

This is the famous Sun YP library problem.  Here's a message I sent a while
back explaining it.

Date: Mon, 27 Jul 1992 14:29:55 -0400
From: Chet Ramey <chet@odin.INS.CWRU.Edu>
To: stud7b43@x400gate.bnr.ca
Subject: Re: Bug in Bash 1.12.1

> I seem to have found a bug in Bash.
> 
> How to cause the bug to appear:
> 1) Start a long username-completion, e.g.
>       cat ~user<TAB>
>    Let it run for a while (don't know exactly how long...)
>    Before it's finished, hit ^C (or whatever the break character
>    is set to)
> 2) As the next command, run a filename completion with a username in it, eg.
>       cat ~username/.log<TAB>
> 
> Error message:  "free: Called with already freed block argument

This is a bug in the Sun YP code that everyone seems to have picked up.

Sun keeps static state in the YP library code -- a pointer into the
data returned from the server.  When YP initializes itself (setpwent),
it looks at this pointer and calls free on it if it's non-null.  So far,
so good.

If one of the YP functions is interrupted during getpwent (the exact function
is interpretwithsave()), and returns NULL, the pointer is freed without being
reset to NULL, and the function returns.  The next time getpwent is called,
it sees that this pointer is non-null, calls free, and the Gnu free()
blows up because it's being asked to free freed memory.

The traditional Unix mallocs allow memory to be freed multiple times; that's
probably why this has never been fixed.  You can probably stop it by adding
an #undef USE_GNU_MALLOC to the appropriate machine description in machines.h.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: aoki@physics.ucla.edu (Ken-ichiro Aoki)
Subject: bash-1.12 on NeXTSTEP3.0: rlogin does not open tty
Summary: rlogin does not open tty
Keywords: not again!
Organization: UCLA Department of Physics
Distribution: gnu
Date: Sun, 22 Nov 1992 00:42:16 GMT

version: bash-1.12.1
machine: NeXTstation (68040 @ 25MHz) running NeXTstep3.0

tty is not opened. To reproduce, rlogin and say 

bash$ echo hi > /dev/tty
/dev/tty: No such device or address

I reported this problem with a previous version of bash
on NeXTstep2.x and it was subsequently *fixed*.
The problem was with NS2.x rlogind.
The current version of bash does contain (in particular
in shell.c) a fix to get around the problem in NS2.x and 
now it is broken *again*... sigh. I suspect the problem
is with NS3.0 rlogind.

Thank you for your time and effort in releasing and
maintaining our favorite shell.
-- 
                        ___Kenichiro Aoki. (aoki@physics.ucla.edu)

Newsgroups: gnu.bash.bug
From: dbarker@spang.camosun.bc.ca (Deryk Barker)
Subject: FTP and bash as login shell
Organization: Camosun College, Victoria B.C, Canada
Distribution: gnu
Date: Mon, 23 Nov 1992 17:27:00 GMT

This system is a 486/50 running Esix System 5 release 4.0 version 4.
Since getting bash installed in the passwd file as my login shell I am
unable to ftp login to my account, when I try I get the message
	use dbarker access denied
when the systems guy changes my login shell back to csh everything is
OK (except that bash is no longer my login shell :-().

As bash is accessable to the entire system, access permissions would
not appear to  be the problem. Can anyone shed any light on this?

Deryk Barker, Computer Science Dept., Camosun College, Victoria B.C.

Newsgroups: gnu.bash.bug
From: kaveh@taarna.UUCP (Kaveh Kardan)
Subject: bash problem on SGI Indigo
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 06:20:24 GMT

I have set bash to be my login shell on an SGI Indigo running IRIX 4.0.5.

When I type in the first character of a command, bash inserts a linefeed
after it.  This does not happen if I launch bash from inside an existing
shell.

Please email.

Thanks,

Kaveh

Kaveh Kardan                                  Systeme Taarna
kaveh@taarna.UUCP                             Montreal, Quebec, Canada
uunet.uu.net!taarna!kaveh                     (514)844-8448

Newsgroups: gnu.bash.bug
From: barr@stein.u.washington.edu (David Barr)
Subject: filename completion and "special characters"
Organization: University of Washington
Distribution: gnu
Date: Fri, 20 Nov 1992 23:18:30 GMT

Is there a way to make bash escape special characters in filenames
when doing filename completion?  Are there any plans to add this feature?

David

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: bash-1.12 on NeXTSTEP3.0: rlogin does not open tty
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 05:37:50 GMT

> version: bash-1.12.1
> machine: NeXTstation (68040 @ 25MHz) running NeXTstep3.0
> 
> tty is not opened. To reproduce, rlogin and say 
> 
> bash$ echo hi > /dev/tty
> /dev/tty: No such device or address
> 
> I reported this problem with a previous version of bash
> on NeXTstep2.x and it was subsequently *fixed*.

The problem is with the NS 3.0 rlogind.  It appears that they are still
compiling it -DDEBUG.  Why, I can't say.  The fix in shell.c depends on
`NeXT' being defined.  What are the constants pre-defined by the NS 3.0
compiler?

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: smiley@akasha.eng.hou.COMpaq.COM (Colin Smiley)
Subject: Bash, SCO and SCO's lousy POSIX compliance...
Organization: Compaq Computer Corporation
Distribution: gnu
Date: Tue, 17 Nov 1992 14:07:10 GMT

I just recently got porting duties for a bunch of SCO-3.2.4 boxes, and
being an avid bash user, want to get bash working on them.  As luck
would have it, I eventually got bash to compile with only minor
changes to the machines.h file (diffs available for gcc compiles if
you want them...They aren't much good right now).  The only problem is
that bash hangs after every command, and sometimes cores when it is
through.  My milage varies according to what compiler I use.  I am
currently trying to get bash to work with GCC-2.3.1.  No luck yet.  I
have tried cc, and rcc both to no avail.

If anyone has gotten bash to work with or without POSIX job control on
a SCO-3.2.4 box, I would be most appreciative if you could send me
some help on how you did it.  I will try looking more into this myself as
soon as I can get GDB ported :-).


Thanks...

Colin


--
-------------------------------------------------------------------------
Colin Smiley, Compaq Computer Corporation, Houston, Texas 77269-2000
e-mail: smiley@compaq.com                           Phone: (713) 378-8426
-------------------------------------------------------------------------
Disclaimer:  Any opinions expressed here do not reflect the opinions of
Compaq Computer Corp.  They make computers.  I make noise.


Newsgroups: gnu.bash.bug
From: dall@hfrd.dsto.gov.au (Ian Dall)
Subject: Re: problem with bash + xon + sunos ...
Organization: Defence Science and Technology Organisation
Distribution: gnu
Date: Tue, 17 Nov 1992 03:37:36 GMT


In article <9211051448.AA24758.SM@odin.INS.CWRU.Edu>, chet@odin.ins.cwru.edu (Chet Ramey) writes:
> This is a bug alright, but it's a bug with rshd that's not fixed until
> 4.3-reno.
> 
> rshd sets up a pipe (int pv[2]; if you have the source to the tahoe rshd)
> to the process it executes and uses it to manage error and control output
> from over the net.  In the child process, it does a dup2(pv[1], 2), but
> never calls close(pv[1]).  Adding that code to the 4.3-tahoe rshd makes it
> (and the Xemacs script) work right.
> 
> I don't know how to solve this cleanly in bash.  Doing a blanket close of
> all open file descriptors > 2, < 20 is a no-no, especially when we're not
> interactive.  csh `works' because it does the blanket close on startup, but
> csh can get away with doing that because it doesn't let you manipulate
> arbitrary file descriptors.

At least on this machine the problem appears to be more that just one
with rsh. For years I have been using the exec n>&- trick to fix the
rsh problem. (Where n is the problem file desciptor). With the
current version of bash, that doesn't seem to work.

I have a program called "nfiledes" which figures out what file desciptors
are open:

    cronus:-dall $ bash
    cronus:-dall $ exec nfiledes
    File descriptor 5 open.
    File descriptor 2 open.
    File descriptor 1 open.
    File descriptor 0 open.
    4 file descriptors open across execs.
    cronus:-dall $ bash
    cronus:-dall $ exec nfiledes 5>&-
    File descriptor 10 open.
    File descriptor 2 open.
    File descriptor 1 open.
    File descriptor 0 open.
    4 file descriptors open across execs.


Note that as soon as I try and close file desciptor 5, something (and
I can't think how it could be anything except bash) opens a new file
descriptor (10). (And if I close 10 it opens 11).


This is
    BASH_VERSION=1.12.1

on a DECstation 5000 (mips R3000) running Ultrix 4.2.

Here is the source for nfiledes.c

/* Count the number of file descriptors currently open */
#include <stdio.h>
#include <fcntl.h>
main ()
{
  int ret, i, n = 0;
  for ( i = _NFILE; i--;)
    if ( (ret = fcntl(i, F_GETFD, 0)) != -1)
      {
	printf("File descriptor %d open.\n", i);
	n += (!ret) & 1;
      }
  printf("%d file descriptors open across execs.\n", n);
}


Ian
-- 
Ian Dall          I'm not into isms, but hedonism is the most
                  harmless I can think of. -- Phillip Adams

internet: dall@hfrd.dsto.gov.au

Newsgroups: gnu.bash.bug
From: marc@r-node.gts.ORG (Marc Fournier - Admin)
Subject: trying again...compiling bash 1.12 on isc386
Organization: R-node Public Access UNIX Information System (416-249-5366)
Distribution: gnu
Date: Sun, 22 Nov 1992 11:47:28 GMT

Hi Folks...
	
	I'm trying again to compile BASH on my system.  It compiles
with little to no errors until jobs.c, where I get multiple errors,
all saying the same thing to me.

request for member 'w_termsig' in something not a structure or union
                   'w_retcode'

	I'm using gcc to compile it, as determined by configure, I
presume.

Can anyone help?

Thanks...

Marc
-- 
Marc G. Fournier      | R-node Public Access Unix running UnixBBS 1.10
Etobicoke, Ontario    | 416-249-5366   24hrs 7 days/week   network email
voice: 249-4230       | shell accounts available  2500+ newsgroups  FREE
marc@r-node.pci.on.ca | Telebit WorldBlazer/SupraModem2400/Cardinal 2400 


Newsgroups: gnu.bash.bug
From: kaveh@cam.org (Kaveh Kardan)
Subject: problem on SGI Indigo
Organization: Communications Accessibles Montreal, Quebec Canada
Distribution: gnu
Date: Mon, 23 Nov 1992 05:17:54 GMT

I am running on an SGI Indigo under Irix 4.0.5.

When I specify bash as my shell, it seems bash thinks my terminal is only 7
characters wide, and places linefeeds after seven characters in a line.
This does not happen if I launch bash from an existing csh.

Kaveh

--
------------
Kaveh Kardan                                     kaveh@CAM.ORG
Metropolis Graphics Ltd                          (514) 842-6172
Montreal Quebec Canada
-- 
------------
Kaveh Kardan                                     kaveh@CAM.ORG
Metropolis Graphics Ltd                          (514) 842-6172

Newsgroups: gnu.bash.bug
From: rcf@chinook.eel.ufl.edu (Robert Fellenz)
Subject: Problems with "*" in bash
Keywords: bash
Organization: UF EE Department
Distribution: gnu
Date: Wed, 18 Nov 1992 07:38:59 GMT

---------------------------
BASH_VERSION:   1.12.2      
hardware:	HP9000s300
compiler:	cc
---------------------------

I am currently having difficulty with the "*" in writing aliases and functions.  If the "*" is being used in a command line (ie. "ls *" ) the wild card will only match some --not all-- of the files it comes across.  The following are examples which demonstrate the problems I am having with bash.

_________________________________________________________________
example 1:

  I'm in directory "test" with the files "a", "b", "c", "d"

  bash$ ls
  a	b	c	d

  bash$ ls *
  a
  
  bash$ touch dd ddd

  bash$ ls [d]*
  d     dd    ddd

  bash$ ls *
  dd
_________________________________________________________________
example 2: Still in the same directory as in example 1.


  bash$ foo()
  >{ echo $* }

  bash$ foo *
  a

  bash$ foo x y z
  x y z

_________________________________________________________________
example 3: Same directory again


  bash$ rm -i *
  a: ? (y/n) y   <--skips b c d ...
  
  bash$ rm -i b c d
  b: ? (y/n) y
  c: ? (y/n) y
  d: ? (y/n) y

_________________________________________________________________
example 4: The following is not related to the above examples but it produces a core dump that can be very large --this might be the result of "cd" being a built in function.

  bash$ cd()
  > { cd *$ }
 
  bash$ cd

the following is the result of the function
 
  Tell root@sioux to fix this someday.
  Stopping myself...free: Called with bad argument

  Tell root@sioux to fix this someday.
  Stopping myself...
___________________________________________________________________
 
Also, my compiled version of bash is 971908 bytes, is it suppose to be that large?

I would appreciate any help you could give me.

Please email me at rcf@sioux.eel.ufl.edu.

Thanks in advance,

-bob							

Robert Fellenz					University of Florida
rcf@sioux.eel.ufl.edu				(904)372-9951



  
  


Newsgroups: gnu.g++.bug
From: dcb@us-es.SEl.DE
Subject: ARM page 87
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 12:51:38 GMT

Hello there,

See section 6.4.2 of the ARM. Top of page 87. GNU G++ 2.3.1 does not do the
right thing for the following code derived from the example.

int main() {
	int a;

	switch (a) {
	case 1:
		int v2 = 3;
	case 2:
		if (v2 == 7)	// error not flagged by 2.3.1
			;
	}

	return 0;
}

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841

Newsgroups: gnu.g++.bug
From: krste@icsi.berkeley.edu (Krste Asanovic)
Subject: template constructors with argument bug.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 21 Nov 1992 04:16:51 GMT

The following transcript shows a C++ program using templates that gets
a fatal signal with gcc-2.3.1, but compiles OK with gcc-2.2.2. This is
on a SPARC running SunOS Release 4.1.1.

Krste Asanovic,                   Computer Science Division, 
email: krste@cs.berkeley.edu      c/o 571 Evans Hall
phone: +1 (510) 642-4274 ext 143  University of California at Berkeley
fax:   +1 (510) 643-7684          CA 94720, USA

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

icsib43:src>cat main.cc
template<class T>
class Vec
{
public:
    Vec(int nElements);
    ~Vec();

    int size();

protected:
    int n;
    T *p;
};

template<class T>
inline
Vec<T>::Vec(int nElements)
  : n(nElements)
{
    p = new T[nElements];
}

template<class T>
inline
Vec<T>::~Vec()
{
    delete[] p;
}

template<class T>
inline int
Vec<T>::size()
{
    return n;
}

main()
{
    Vec<int> a(3);

    return 0;
}
icsib43:src>gcc -o main main.cc
main.cc: In function `int  main ()':
main.cc:13: inconsistent return types for method `Vec' in class `Vec<int>'
gcc: Internal compiler error: program cc1plus got fatal signal 11
icsib43:src>gcc -V2.2.2 -o main main.cc
icsib43:src>


Newsgroups: gnu.g++.bug
From: dcb@us-es.SEl.DE
Subject: pointers to class data members don't work
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 22:12:54 GMT

Hello there,

Given the following code,

class A
{
public :
        A() ;
        ~A() ;
private :
        int a ;
        int b ;
        typedef int A::* pm ;
        struct A1
        {
                pm p ;
        } ;
        static A1       tbl[] ;
} ;

A::A1           
A::tbl[ 2 ] = 
{ &A::a  , 
	 &A::b  } ;

then it looks legal to me, and most of the compilers I have agree with
this opinion. However, Gcc 2.3.1 produces the following

kanze28.cc:20: error: invalid initializer
kanze28.cc:14: error: storage size of `tbl' isn't known

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
From: court+@cmu.edu (Court Demas)
Newsgroups: gnu.g++.bug
Subject: Possible "new" bug
Date: 17 Nov 92 07:08:52 GMT
Article-I.D.: andrew.0f2GQY600Vom8jZ40U
Distribution: gnu
Organization: GNUs Not Usenet

I have been wrestling with what seems to be a bug in g++ v2.2.2.  I am first
assuming that the following two are equivalent:

Footype *f = new Footype();

and

Footype *f;
f = new Footype();
But these two fragments produce very different results (this is inside a
function call).  The 1-line version behaves very badly - 'new' seems to
reallocate a block of memory which was already allocated earlier in the
application.  So, the object gets initialized ok, but it trashes a few other
objects in the process.

I haven't been able to quantify this yet into a sample program, but I can
definitely reproduce it in my application (it's 5k and 70 source files).
I *never* deallocate memory in the application (all delete's are commented out)
so I can't see why this should happen under any circumstances.

If anybody could provide an insight on this I would greatly appreciate it.
I will hopefully be able to post a sample program which exhibits the bug soon.


thanks,
court
Newsgroups: gnu.g++.bug
From: dumesnil@etca.fr (Antoine de Maricourt)
Subject: bug G++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 20:18:34 GMT

Hi again,

I reported a bug to g++ yesterday. Here is another one (maybe the same). 
The configuration is the same. There is a syntax error of course but I get signal 11 again.

>cat d.cxx

class INT : {
  long obj;
 public:
  INT (int i)        { obj = (i << 3) ; }
  operator int ()    { return obj >> 2; }
};

main () 
{
  register INT  i = 3;
}

>g++ -S d.cxx
d.cxx:2: parse error before `{'
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11


By the way, if I remove the ':', I get the following message with option -O2 :
d.cxx: In function `int  main ()':
d.cxx:11: warning: address requested for `i', which is declared `register'

It were OK if I were using variable 'i' but I don't. I thought I would have got a message
telling I am not using 'i' instead ?  

If you have any idea how I could find and remove the bug, I would appreciate any help.
Thanks.
        
        A. de Maricourt

Newsgroups: gnu.g++.bug
From: jkh@whisker.lotus.IE (Jordan K. Hubbard)
Subject: Crash bug with 2.3.1
Organization: Lotus Development Ireland
Distribution: gnu
Date: Sun, 22 Nov 1992 17:01:57 GMT

The following C++ program will crash gcc 2.3.1:

class fred {
	int i;
};

main()
{
	fred *fp;

	fp = new fred[100]();
}

Removing the empty constructor argument list from the above will eliminate
the crash.  I.E.

	fp = new fred[100];

Crash details:

jkh@whisker-> g++ -v crash.cc -o crash
Reading specs from /usr/gnu/lib/gcc-lib/i386--bsd/2.3.1/specs
gcc version 2.3.1
 /usr/gnu/lib/gcc-lib/i386--bsd/2.3.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__386BSD__ -D__unix__ -D__i386__ -D__386BSD__ -D__unix -D__i386 -D__386BSD__ crash.cc /var/tmp/cc001269.i
GNU CPP version 2.3.1 (80386, BSD syntax)
 /usr/gnu/lib/gcc-lib/i386--bsd/2.3.1/cc1plus /var/tmp/cc001269.i -quiet -dumpbase crash.cc -version -o /var/tmp/cc001269.s
GNU C++ version 2.3.1 (80386, BSD syntax) compiled by GNU C version 2.3.1.
crash.cc: In function `int  main ()':
crash.cc:9: Internal compiler error 40.
crash.cc:9: Please report this to `bug-g++@prep.ai.mit.edu'.

Newsgroups: gnu.g++.bug
From: jody@algorithmics.COM (Jody Goldberg)
Subject: Inheritance bug
Organization: Gnus Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 14:51:00 GMT

Using gcc-2.3.1 on a Sparc II running 4.1.3 with libg++-2.2 the following code
produces.
---------------------------------------------
g++ -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/specs
gcc version 2.3.1
---------------------------------------------
g++ Test.C ; ./a.out
----------
3
3
---------------------------------------------
We expected
-----------
1
2
------------------------
Test.H
------
#include <iostream.h>

class A
{
public:
	virtual ~A();
	virtual int type(void);
};

class B
{
public:
	virtual ~B();
};


class C0 : public B, public A
{
public:
	int type(void);
};

class C1 : public C0
{
public:
	int type(void);
};

class C2 : public C0
{
public:
	int type(void);
};

class C3 : public C0
{
public:
	int type(void);
};
----------------------------
Test.C
------

#include "Test.H"

A::~A()
{
}

int A::type(void)
{
	return 1;
}

B::~B()
{
}

int C0::type(void)
{
	return 0;
}

int C1::type(void)
{
	return 1;
}

int C2::type(void)
{
	return 2;
}

int C3::type(void)
{
	return 3;
}

main()
{
	C1* one = new C1;
	C2* two = new C2;
	
	cerr << one->type() << '\n';
	cerr << two->type() << '\n';
}

	Thanks
		jody Goldberg

jody@algorithmics.com

Newsgroups: gnu.g++.bug,comp.unix.sysv386
From: fred@cv.ruu.nl (Fred Appelman)
Subject: g++ and shared libraries
Summary: Problems with shared libaries, gcc and global variables.
Date: Sat, 21 Nov 1992 12:11:34 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group
Keywords: shared, global
Apparently-To: gnu-g++-bug@nluug.nl
Distribution: world
Approved: info-gnu@prep.ai.mit.edu
From: teague@stc.lockheed.COM (Alan Teague)
Subject: Nested Classes Problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 02:55:00 GMT

The following code causes the compile to crash.  If it doesn't cause your
compiler to crash also, then please let me know so that I can check the 
installation and building of the one here.

Under g++ 1.40.3 this code generates the error message:
	multiple `::' terms in declarator invalid
But I could work around it by dropping the "enclose::" part of the
destructor definition.  I can't figure out how to work around this
problem.  Defining the function in the definition would work only for
very limited functions (non-recursive etc.).

// Compiled with: g++ nested-classes.cc
// Compiler: gcc 2.3.1
// sparc-sun-sunos4.1
// SPARCstation 2 running 4.1.1
//
// Example drawn from page 187 ARM
class enclose {
  class inner {
   public:
    ~inner();
  };
};

// Causes cc1plus to get fatal signal 11 - segmentation violation
enclose::inner::~inner()
{
  x = 0;
}

Newsgroups: gnu.g++.bug