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

["Janis Johnson" <janis at us dot ibm dot com>]

I've also been building gcc on DYNIX/ptx recently and have run into
some of the same problems that Biswa is seeing.  I'm using DYNIX/ptx
V4.6.0 with the native assembler and linker.  With a few changes to
config/ptx4.h I can build the entire compiler set for 2.95.2.  With
the latest snapshot I need to specify BOOT_CFLAGS="-O2", as Robert
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
tests but haven't yet investigated the failures.

I had hoped to lurk awhile longer to avoid asking dumb questions, but
don't want anyone else to get stuck looking at the same problems that
I am running into.

I'm trying builds on DYNIX/ptx because that's the most stable system
I have available and I'm familiar with it, but I'll soon be building
and testing on an Intel IA-64 system running Linux, and don't expect
to track down all of the problems on DYNIX/ptx.  I will, however, put
together a patch for necessary changes to ptx4.h for 2.95.2 and for
building C with the current snapshot, or share my information with
Biswa if he's planning to create such a patch.

robertlipe@usa.net wrote:
> biswapesh.chattopadhyay@bt.com wrote:
> > ----------------------------------------------------------------------------
> > --- 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?

> > +
> > +#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,
but I can't find a record of any problem like that.  I have access to
the DYNIX/ptx source code, and bcopy() looks fine to me.

There's a bug in the DYNIX/ptx linker (not yet reported) that can cause
the last address of user data space (_end, used by sbrk()) to be
incorrect if common data specifies an alignment.  This can be worked
around by changing the macro ASM_OUTPUT_ALIGNED_COMMON, in config/ptx4.h,
to ignore the ALIGN parameter.  I'd like to look at this more before
submitting a patch to see if this is really the right way to handle it.
This problem showed up during a bootstrap of the C compiler when
gengenrtl aborted.

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.  I've
looked through the documentation but haven't yet figured out how to do
that.  Is there a symbol that is defined when this config header is
included that will let me know if the GNU assembler will be used, or a
compiler option that I can look for within the option string itself,
using the mechanism used by the rest of the options in ASM_SPEC?

Janis Johnson
IBM Linux Technology Center
(503) 578-5458
janis@us.ibm.com