Bug 22852 - GCC 2.96 cannot compile GCC 2.95.2
Summary: GCC 2.96 cannot compile GCC 2.95.2
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
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:
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: ---


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


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