Bug reports for EGCS 2.95 (beta) on UW2.1

Robert Lipe robertlipe@usa.net
Mon Jun 28 18:26:00 GMT 1999


This moved from the newsgroup to the EGCS list.  Somehow, I doubt that
Warren's experiences are going to be unique.  Individually, his steps
didn't seem illogical even though we can point to places where things
are documented.  How can we make these things clearer to users?

In comp.unix.sco.programmer Warren Young wrote:

>I've started playing with building EGCS 2.95 (CVS'd on 6/18/1999 at
>about 9 or 10pm Mountain time) on a UW 2.1.3 box.  For reference, my
>initial configure line was:

>./configure --with-gnu-ld --with-gnu-as --enable-shared

>The configure command in config.status also includes the following
>options:

>    --host=i386-pc-sysv4.2uw2.1.3 --norecursion 

>The configure script found my existing egcs 2.91.60 compiler, which I
>let it use, to begin with.  I have GNU ld and GNU as installed, both
>at version 2.9.1.  For superstitious reasons related to the fact that
>egcs requires GNU auto*, GNU m4 and GNU make to build, I've asked
>configure to use those tools rather than the SCO ones.

>Now begins my egcs saga:

>1. After configuring as noted above, I started a plain "make", as
>opposed to a bootstrap make, on the theory that egcs 2.91.60 could
>probably build the new compiler all by itself.  

Yes, it would indeed build the new compiler, but only if given the
'bootstrap' target.

>The build failed in the f77 bit, during the build of the info files.

I think f77 is just the first place where it _obviously_ does the wrong
thing if you don't do the 'make bootstrap'.


>The makeinfo tool gave a raft of errors, and then said to give it the
>--force option to persevere despite these errors.  So, I grepped
>around in the code until I found the place to pass that option
>(gcc/f/Make-lang.in), did the deed, and continued the build.  The
>build failed again in the same place.  

>Perhaps it's important that in the configuration of texinfo, it said
>that it couldn't find a working makeinfo.  (I couldn't find such a
>package on ftp.gnu.org.  Is it part of some other package?)  Maybe the
>f77 compiler would have worked if I'd installed a version of makeinfo
>first instead of letting it use the one in egcs tree.

It should work using the one in the tree.

>2. Since I don't need or want FORTRAN support, I just worked around
>this by reconfiguring with a "--enable-languages" that didn't include
>f77.  At this point, I decided it might be a good idea to do a "make
>bootstrap" after all.  Much disk crunching later, I got the following
>error, in stage 1:

>stage1/xgcc -Bstage1/ -B/usr/local/i386-pc-sysv4.2uw2.1.3/bin/ -c \ 
>    -DIN_GCC     -W -Wall -O2 -g -O2  -DHAVE_CONFIG_H    -I. -I. \
>    -I./config -I./../include regclass.c
>regclass.c: In function `init_reg_sets_1':
>regclass.c:417: Internal compiler error in `find_life_end', at \
>    loop.c:7127

>(Backslashes and indenting added for clarity.)

I do see some traffic about a similar problem in EGCS this week.   I've
been out of the country so I don't know the details yet.

>I figured that this was a problem with egcs 2.91.60, so I did a "make
>distclean", then an "export CC=cc" to force the build to do stage1
>with the SCO compiler, and finally a "configure..." and a "make
>bootstrap".  That brings me to:

OK.   This at least gets you back on the road documented to travel. :-)


>3. In the texinfo/lib code, cc complained of a redefined memcpy.  To
>fix it, I manually #defined HAVE_MEMCPY in texinfo/config.h (bad
>style, I know, but I don't know how to make autoconf detect memcpy
>correctly) and changed texinfo/memcpy.c so that it only compiled the
>memcpy code if HAVE_MEMCPY is not defined.  "cvs diff memcpy.c" says:

This is actually lameness in autoconf.  We've been discussing possible
solutions this week.  Jeff, this is another symptom of the Autoconf
2.11 "intrinsics don't need no steeeeking arguments " thing tripping up
native compilers.



>Index: memcpy.c
>===================================================================
>RCS file: /cvs/egcs/egcs/texinfo/lib/memcpy.c,v
>retrieving revision 1.2
>diff -r1.2 memcpy.c
>8a9
>> #if !defined(HAVE_MEMCPY)
>20a22
>> #endif //!defined(HAVE_MEMCPY)

>I think this should go into egcs -- it seems obvious to me that the
>code should be wrapped like this.  Else, why have a HAVE_MEMCPY
>configuration macro at all?

>4. After fixing that problem and reissuing the "make bootstrap", I got
>the virtually the same error as in item #2.  (The only difference was
>that the second -O2 was missing.)  So, I did a "make distclean" and
>reconfigured, leaving off the bits for GNU ld and GNU as.  After
>re-applying the texinfo/config.h hack, I started a "make bootstrap".
>Result: same problem.  I then took off --enable-shared; same result.

>5. I then decided to try something that the "host specific" help page
>at egcs.cygnus.com hinted at and tried the i?86-*-udk target.  (I
>didn't do this from the start because your previous posts here
>indicated that config.guess Did The Right Thing out of the box now.
>Perhaps you only meant that for UW7?)  I used much the same command
>line as the one given on that page, except that my cc isn't under
>/udk*, but simply under /usr/ccs/bin.

The UDK target should only be used if you have the UDK.   It doesn't
sound like you do or that you want it.   Can you suggest text in that
section to make that clearer?


>That also failed, because it couldn't find various common include
>files like stdlib.h and unistd.h.  Based on the command line make
>echoed, I guessed that the --exec-prefix argument given in the
>configure command on the platform notes page was wrong, so I
>reconfigured without it to see what would happen.  No joy.  The
>complete error is:

Here  you're spinning from the UDK mistake above.



>  ./xgcc -B./ -B/usr/local/i686-pc-udk/bin/
>-I/usr/local/i686-pc-udk/include -O2   -DIN_GCC     -g  -I./include
>-fPIC -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I./config
>-I./../include -c -DL${name} \
>       ./libgcc2.c -o ${name}.o; \
>  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
>  ` if [ -f /usr/local/src/egcs/gcc/../binutils/ar ] ; then echo
>/usr/local/src/egcs/gcc/../binutils/ar ; else if [ "i686-pc-udk" =
>"i686-pc-udk" ] ; then echo ar; else t='s,x,x,'; echo ar | sed -e $t ;
>fi; fi` rc tmplibgcc2.a ${name}.o; \
>  rm -f ${name}.o; \
>done
>_muldi3
>./libgcc2.c:41: stdlib.h: No such file or directory
>./libgcc2.c:42: unistd.h: No such file or directory

>I'm now at a loss as to what to try next.  Was this only supposed to
>work on UW7?

>= Warren -- http://www.cyberport.com/~tangent/


No it _should_ work out of the box on UW2.  Let's focus on that target.
The UDK thing is a distraction.  Help us make that doc clearer.  Let's
hope (or at least verify) that the find_life_end ICE was either fixed or
a flue from the aborted build.    We need to figure out a solution for
the autoconf problem that tripped you up.

RJL


More information about the Gcc mailing list