This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Got NEWS?
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: Got NEWS?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 27 Jul 1998 23:53:52 -0600
- cc: hjl at lucon dot org, jason at cygnus dot com, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199807280504.WAA28410@atrus.synopsys.com>you write:
>
> > > I'd like to see my library interface in 1.1. Otherwise, it may be
> > > a disaster for Linux where libstdc++ is usd by the system. It is very
> > > likely that
> > >
> > > # configure --prefix=/usr
> > I suspect most folks do not do this. And I certainly do not recommend
> > doing this since it overwrites files in the "system area".
>
> You're used to thinking in terms where there is a "system compiler"
> and there is gcc. But on OSes where gcc *is* the system compiler, at
> some point a new compiler has to be installed into the "system area".
Not exactly. I'm used to making a differentiation between places
where sysadmins install the tools used to build the base system and
the location where most folks install tools.
In fact, I've worked on systems where gcc was the only compiler for
7 of the last 10 years. Only recently have I moved to a platform
where gcc is not the system compiler (hpux).
> This operation should work "out of the box", though perhaps extra warnings
> would be nice. Yes, you can tell people "don't set --prefix=/usr",
> but then how do they build /usr/bin/gcc? You can tell them "don't do
> this, let HJ do it for you", but folks should be able to patch the
> compiler, rebuild it, and install it as the system compiler (possibly
> screwing up their system, but hey, how else do you learn?).
Actually I think it will work right now because we changed the version
# for libstdc++ (which I had forgotten about). This is by no means
an ideal solution and will break down if someone took our libstdc++,
then tried to compile it with gcc-2.8 (for example). Or when glibc
versions change and similar situations.
I see both the version # change as well as putting stuff in libsubdir
as short term solutions -- enough to get us through egcs-1.1, but
not the right thing to do for egcs-1.2.
> The operation does have to be done at some point by those making
> distributions for which egcs is the primary compiler, or distributing
> packages designed to be installed this way.
Right, but I suspect these folks take the compiler, build and install
it as a whole and use it to build the entire system.
I doubt they try to keep 3 versions of libc live on the system and I
doubt they try to build the egcs libstdc++ with different compilers.
Some developers do this (myself included), but I don't think it is
the norm. Thus I have not considered this issue critical for egcs-1.1
> Let's not get back into the
> same boat of forcing HJ to patch each g++/libg++ release. If a relatively
> simple patch can make the lives of people who make distributions easier,
> it seems worthwhile.
Can't argue with that. The fewer such patches the better!
jeff