This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: patch for PR 6158 (important for 3.1)
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: tromey at redhat dot com
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, Java Patch List <java-patches at gcc dot gnu dot org>
- Date: 16 Apr 2002 15:49:58 -0300
- Subject: Re: RFC: patch for PR 6158 (important for 3.1)
- Organization: GCC Team, Red Hat
- References: <87wuv8adbn.fsf@creche.redhat.com>
On Apr 15, 2002, Tom Tromey <tromey@redhat.com> wrote:
> I don't think this is really quite perfect. In particular it seems to
> me that the user will also experience problems if he happens to make a
> change to libgcj and then rebuilds an already built-and-installed
> tree.
Probably.
> Alexandre, is it possible for libtool to work around this somehow?
I'd love to know of a way to do it. So far, my understanding of the
problem has been proven to be wrong since switching from a set up with
inter-library dependencies to one that didn't have them didn't fix the
problem :-(
> If not, won't this be a problem for any libtool-using package that
> links an executable against a shared library it also installs?
For some reason, it had never been a problem before.
I suspect this may have to do with libgcj being linked with gcj, which
implicitly links in libgcj, but I'm yet to find the time to
investigate this closely again :-(
> I tested this on the affected platform. Ok to commit?
> * configure.in: Disallow configuring libgcj when it is already
> installed and we're using Solaris 2.8 linker. Do enable libgcj on
> Solaris 2.8 by default. For PR libgcj/6158.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer