Bug 22852

Summary: GCC 2.96 cannot compile GCC 2.95.2
Product: [Retired] Red Hat Linux Reporter: Need Real Name <gotta>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: jbednar
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-12-26 20:13:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2000-12-26 20:13:09 UTC
This bug report applies both to GCC 2.96 as shipped with RH 7.0 and to the
updated
2.96-69 release.

I download a 2.95.2 tarball, and build it as follows:

% ./configure --enable-shared --enable-version-specific-runtime-libs
% make bootstrap

It builds for a while, until I get:

indstream.cc: In method `struct streampos indirectbuf::seekoff(long long
int, ios::seek_dir, int = 3)':
indstream.cc:82: `struct streampos' used where a `int' was expected
indstream.cc:85: `struct streampos' used where a `int' was expected
indstream.cc:87: `struct streampos' used where a `int' was expected
indstream.cc:89: conversion from `int' to non-scalar type `streampos'
requested
indstream.cc: In method `struct streampos indirectbuf::seekpos(_G_fpos64_t,
int = 3)':
indstream.cc:99: `struct streampos' used where a `int' was expected
indstream.cc:102: `struct streampos' used where a `int' was expected
indstream.cc:104: `struct streampos' used where a `int' was expected
indstream.cc:106: conversion from `int' to non-scalar type `streampos'
requestedmake[2]: *** [indstream.o] Error 1
make[1]: *** [all-target-libio] Error 2
make: *** [bootstrap] Error 2

This problem is a double whammy for my company becuase:

 1) The same behavior of 2.96 shows up when I try to build my companies
code.
 2) We are successfully using GCC 2.95.2 on RedHat 6.2 but cannot recreate
this
     success in RedHat 7.0 because we cannot build the compiler.

Consequently we are unable to move to RedHat 7.0 as a development platform.

Comment 1 Bill Nottingham 2000-12-27 04:47:38 UTC
From the glibc FAQ (/usr/share/doc/glibc-2.2/FAQ):

2.35.   When recompiling GCC, I get compilation errors in libio.

{BH} You are trying to recompile gcc 2.95.2?  After upgrading to glibc 2.2,
you need to apply a patch to the gcc sources, because the fpos_t type and
a few libio internals have changed in glibc 2.2. The patch is at
http://clisp.cons.org/~haible/gcc-glibc-2.2-compat.diff


Comment 2 Jakub Jelinek 2000-12-27 10:20:57 UTC
Actually, I'd rather direct you to:
http://gcc.gnu.org/install/specific.html#*-*-linux-gnu

Comment 3 jbednar 2000-12-27 22:04:25 UTC
It should be noted that at least the patch at

  http://clisp.cons.org/~haible/gcc-glibc-2.2-compat.diff

works even for egcs-1.1.2, which is often more useful than GCC-2.95.2 or 2.96
(generating faster C++ code than 2.95.2, while compiling much faster than 2.96
for my applications).

Since this issue is bound to come up for so many people for the next year or
two, it would be very helpful if RedHat could release RPMs for GCC-2.95.2 and
egcs-1.1.2 that do not conflict with the 2.96 RPMs.  The egcs RPMs from e.g.
RedHat 6.1 appear to conflict with gcc-2.96 and are not relocatable, so they
cannot be installed in e.g. /usr/local.  So instead each user needing one of
these compilers has to download the source, realize that they need the patch,
apply the patch, and get the compilation to work.  If we just had /usr/local or
relocatable RPMs for 2.95.2 or egcs-1.1.2 we could avoid all of that hassle, and
perhaps RedHat wouldn't be getting flamed so much about GCC :-).