This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A completely different approach to EH runtime
- To: Joe Buck <jbuck at synopsys dot COM>
- Subject: Re: A completely different approach to EH runtime
- From: "H . J . Lu" <hjl at valinux dot com>
- Date: Thu, 22 Feb 2001 09:49:18 -0800
- Cc: Zack Weinberg <zackw at stanford dot edu>,Joern Rennecke <amylaar at cambridge dot redhat dot com>,Alexandre Oliva <aoliva at redhat dot com>, gcc at gcc dot gnu dot org
- References: <20010221231833.A1251@valinux.com> <200102221736.JAA16324@toledo.synopsys.com>
On Thu, Feb 22, 2001 at 09:36:48AM -0800, Joe Buck wrote:
>
> Case 2: ls was built by 3.0, and the user is testing 3.1-beta1, which
> is installed with prefix /opt/gcc-3.1-beta with libs in /opt/gcc-3.1-beta/lib.
> ls will now get the new libgcc_s.so. However, this new library will
> provide all of the same symbols and ABIs as the old library (plus,
> possibly, some new ones). ls still runs just fine.
>
> So where is the problem? It appears that you are implicitly assuming
>
How can you be 100% sure your libgcc is always newer than the one in
/lib? How about ls is built by 3.1 and I want to try 3.0.1? Or
you installed gcc 3.0.1 and ls is now upgraded to the one built by
gcc 3.0.2?
> > Even if you use -rpath,
> > which I don't like, it will means all DSOs, including those come with
> > the system, opened by the new binary will use the new libgcc_s.so in
> > /path/to/other/lib. Do you think it is safe to do so? If yes, why not
> > put the new libgcc_s.so in /lib?
>
> People should be able to test gcc on machines where they don't have root.
Isn't that the same problem to test glibc? As I said before, having the
shared libgcc under Linux puts libgcc in the same category as glibc. Do
you really think you have seen something new with shared libgcc we
haven't seen in glibc before?
--
H.J. Lu (hjl@valinux.com)