Ron,

> Due to messing around with various releases of gcc/egcs, I ended up
> with several different gcc installations on my system. I was 
> deleting what were
> (I thought) the ones I wasn't using, and unfortunately deleted 
> something required
> for c++ compiliation. Since the C compiler was still working, I 
> tried reinstalling
> gcc, but his didn't fix the problem.

        The g++ compiler is implemented as a source patch on the
gcc compiler.  Reinstalling the gcc compiler would overwrite
the patches to the parser, eliminating g++ support.

> My best guess ... is that some configuration file is ...
> pointing at the broken installation ...

        Since the "configuration file" is source code, I suggest
that you reinstall g++ (and gcc) from the source code.  It may
save you time (but may not work) if you reinstall g++ (which
includes gcc) from a binary.

        Traditionally unix package management has involved the
installation and testing of packages each in its own directory,
and using symbolic links to make the package available.

                ---- simplified example ----
        /opt/packages/gcc-2.7.2
                /original
                        gcc-2.7.2.tar.gz
                        maintenance_notes.html
                        GNU_PUBLIC_LICENSE
                        ...
                /bin
                        gcc
                        glint
                        ...
                /lib
                        libc-5.4.6.so
                        /g++-inc
                                iostream.h
                                ...
                        ...
                /include
                        stdio.h
                        ...

        /usr
                /bin
                        gcc -> /opt/packages/gcc-2.7.2/bin/gcc
                        ...
                /lib
                        g++-inc -> /opt/packages/gcc-2.7.2/lib/g++-inc
                        ...
                ---- simplified example ----

        This approach has evolved for several reasons:

        o A new packages can be installed and tested by an unpriveleged
                user (traditionally tool) without risking modification
                of other installed packages.
        o The old package is still available to normal users while the
                new package is being installed and tested.
        o The new package can be made available after it has been
                tested by a priveleged user that creates the symbolic
                links.
        o A package can be removed completely and certainly by
                removing all links into the particular package
                directory and by removing the package directory.

        Tools have also evolved to support this approach.

        install(8) is traditionally used to perform a limited set
of operations approved by the system administrator, such as creating
links in the system directory.  install(8) is typically used by a
Makefile supplied with the package, but has a much lower risk than
running arbitrary scripts from the package with no check on the
safety of the operations.

        I use opt_depot (I'll send the URL upon request) to automate
the linkage described above.

Good luck,

Bob

Reply via email to