RE: Unable to bootstrap gcc snapshot of 20001211 on Dynix/ptx

[biswapesh dot chattopadhyay at bt dot com]

Hi

Sorry I was off this weekend - hence the delay.

The NO_SYS_SIGLIST was required in 2.95.2 (it wasn't autoconf detected) so I
put the patch for the snapshot as well. Maybe this is not required any more.
I'll try the build without this patch.

#undef HAVE_BCOPY is definitely required - you cannot build 2.95.2 without
it (ptx 4.4.6) - C++ streams parsing go all wrong. I grepped through the
source for it's use and it seemed that the problem is (as Janis said) that
overlapping memory is indeed not handled properly. I applied a patch as per
the old mail to use memmove in the one case (in cp/class.c)where overlapping
copy was being done and things worked fine (in 2.95.2). Since there might be
other places which this might affect, I thought it would be wise to force
Dynix builds to use memmove consistently throughout instead. Janis, can you
try the bcopy patch in ptx4.h and see if you can build libstdc++
successfully ? It is, ofcourse, possible that the bug was corrected in 4.6.0
(I'm using 4.4.8)

I'll try and come up with a patch for the assembler issue (so that people
don't have to rename gnu as to gas), unless Janis has one (since he built
95.2 with native assembler/linker) ?

I'll also try the build with the suggested optimizer flag (BOOT_CFLAGS=-O2)
and see what comes up.

Janis, can you post me your ptx4.h patch ?

Thanks.
Biswa.

> -----Original Message-----
> From: Robert Lipe [mailto:robertlipe@usa.net]
> Sent: 15 December 2000 23:13
> To: Janis Johnson
> Cc: biswapesh.chattopadhyay@bt.com; gcc@gcc.gnu.org
> Subject: Re: Unable to bootstrap gcc snapshot of 20001211 on Dynix/ptx
> 
> 
> Janis Johnson wrote:
> 
> > Lipe said.  I can bootstrap the snapshot C compiler, but currently
> > when I try the entire build it dies building libstdc++-v3.  I've run
> 
> That's a depressingly common state. 
> 
> > building C with the current snapshot, or share my information with
> > Biswa if he's planning to create such a patch.
> 
> It'd be great for you two to cooperate on such a thing.
> 
> 
> > > > --- ptx4.h.orig Fri Dec 15 16:56:46 2000
> > > > +++ ptx4.h      Fri Dec 15 16:57:32 2000
> > > > @@ -27,6 +27,14 @@
> > > >  /* Define a symbol indicating that we are using svr4.h.  */
> > > >  #define USING_SVR4_H
> > > >
> > > > +#ifndef NO_SYS_SIGLIST
> > > > +#define NO_SYS_SIGLIST
> > > > +#endif
> > >
> > > This shouldn't be necessary any more, as it's 
> autoconf-detected now.
> > 
> > I also needed to make this change; any hints on how to find out why
> > autoconf isn't setting it up correctly?
> 
> On 2.95.2, you probably do have to do this.  Look to see why configure
> is seeing HAVE_SYS_SIGLIST in config.cache (esp in 
> libibiberty) and yet
> you're not getting a useful one.
> 
> What probably should be happening is that libiberty should 
> see that you
> DON'T have one (it's a BSD-ism and not part of any pertinent 
> standard, I
> think) and then it should build one for you in strsignal.o.
> 
> 
> > > > +#ifdef HAVE_BCOPY
> > > > +#undef HAVE_BCOPY
> > > > +#endif
> > > Why is this necessary?
> > 
> > I didn't do this, and had no problems.  There was a 
> reference to old mail
> > that said that bcopy() for DYNIX/ptx didn't handle 
> overlapping memory,
> 
> Was this observed to be necessary, or was it just a wive't 
> tale from that
> message?
> 
> > Biswa mentioned recently that ASM_SPEC includes the option 
> -no_0f_fix,
> > which causes problems with the GNU assembler.  That option 
> is necessary
> > when using the DYNIX/ptx assembler.  Robert Lipe said that 
> there's a way
> > to specify the option only if the GNU assembler is not being used.  
> 
> Have configure use a different .s file if it sees --with-gas 
> that sets a
> #define that you can then test inside ptx.h.  Search for "USE_GAS" for
> prior art.
> 
> RJL
>