G++ an multiple architectures (solved)

[ed at eh3.com (Ed Hill)]

On Wed, 15 Nov 2006 07:43:20 -0500 Jerry Feldman <gaf at blu.org> wrote:

> On Tue, 14 Nov 2006 09:38:17 -0500
> Matthew Gillen <me at mattgillen.net> wrote:
> 
> > Jerry Feldman wrote:
> > > As I mentioned yesterday,
> > > the /usr/include/c++/3.4.3/x86_64-redhat-linux directory was
> > > missing. At the moment, I don't have the systems set up for
> > > up2date, but my solution was to simply copy that directory tree
> > > from a known good system. Apparently the libraries were fine, so
> > > it is simply the c++ include files. I was able to compile both
> > > 64-bit and 32-bit c++ programs aftrer I did that.
> > 
> > On the known-good system, you can do:
> >  rpm -q --whatprovides /usr/include/c++/3.4.3/x86_64-redhat-linux
> > 
> > to find out what package you're missing on the broken system
> > (libstdc++-devel perhaps?).
> It does not show up. It does show up on the good system.


Hi folks,

Its possible that the compiler was updated on one machine and not on
the other.  On RHEL and Fedora (and CentOS, etc.) systems, GCC installs
its standard (or "internal") headers and libraries within a directory
structure such as:

  /usr/lib/gcc/i386-redhat-linux/4.1.1/

and you can confirm this by, for instance, running:

  rpm -ql gcc
  rpm -ql gcc-c++
  rpm -ql gcc-gfortran

Some months ago I updated ("yum update") a Fedora Core 5 system and
it dutifully upgraded the GCC system from 4.1.0 to 4.1.1.  As a result,
the directory:

  /usr/lib/gcc/i386-redhat-linux/4.1.0

and its contents were removed and the newer:

  /usr/lib/gcc/i386-redhat-linux/4.1.1

was installed along with a new set of headers, libs, etc.

For the *vast* majority of properly packaged software, such a change is
perfectly fine (since the compiler ABI is unchanged).  But some folks
(despite the warnings in the GCC documentation advising against it)
either deliberately or inadvertently explicitly include items within
the above "GCC internal" directories.  One example I've encountered is
the Portland Group compiler suite.  In those cases, upgrading the
compiler can indeed break things -- although a reasonable person can
certainly argue that such packages were broken from the outset.

And the "fix" that you performed (simply copying the files over) is not
the recommended way to deal with these problesm on *any* RPM-based
distribution.  In all likelihood your RPM database is now out of sync
with whats actually installed on your system.

Ed

ps - Version-specific compiler bits for older compilers are 
     sometimes available as a set "compat" rpms such as:

  compat-gcc-32-g77-3.2.3-56.fc5
  compat-libf2c-32-3.2.3-56.fc5
  compat-gcc-32-3.2.3-56.fc5
  compat-gcc-32-c++-3.2.3-56.fc5


-- 
Edward H. Hill III, PhD  |  ed at eh3.com  |  http://eh3.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20061115/6973591e/attachment.sig>