Bug 22852 - GCC 2.96 cannot compile GCC 2.95.2
Summary: GCC 2.96 cannot compile GCC 2.95.2
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-26 20:13 UTC by Need Real Name
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-26 20:13:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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
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'
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
 2) We are successfully using GCC 2.95.2 on RedHat 6.2 but cannot recreate
     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

Comment 2 Jakub Jelinek 2000-12-27 10:20:57 UTC
Actually, I'd rather direct you to:

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


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 :-).

Note You need to log in before you can comment on or make changes to this bug.