This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: Adding _eh.o frame-dwarf2.o to libstdc++.so.3?
- To: Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>
- Subject: Re: Adding _eh.o frame-dwarf2.o to libstdc++.so.3?
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Fri, 28 Jul 2000 09:34:12 -0700 (PDT)
- cc: "H . J . Lu" <hjl at lucon dot org>, libstdc++ at sourceware dot cygnus dot com
> Now I see the problem. It's that I've got libtool.m4 installed in
> /usr/share/aclocal, but not in /n/gnu/automake/share/aclocal, whose
> aclocal 1.4 I've been using. As soon as I use /usr/bin/aclocal and it
> finds the out-dated installed libtool.m4, I get the same errors you
> do.
>
> The good thing is that the solution is very simple. Replace the last
> lines of the patched acinclude.m4 with:
>
> sinclude(../libtool.m4)
> dnl The lines below arrange for aclocal not to bring an installed
> dnl libtool.m4 into aclocal.m4, while still arranging for automake to
> dnl add a definition of LIBTOOL to Makefile.in.
> ifelse(,,,[AC_SUBST(LIBTOOL)
> AC_DEFUN([AM_PROG_LIBTOOL])
> AC_DEFUN([AC_LIBTOOL_DLOPEN])
> AC_DEFUN([AC_PROG_LD])
> ])
Cool. We are both on the same page now. Yes, with this change things work
again for me, with no dependency on what autoconf/automake being used.
For what it's worth, I can use the standard autoconf/automake now, for
whatever reason, so I'd like to use the net releases instead of random
drops of automake/autoconf.
I'd like to see this patch go in. Do you want me to check it in, or
should you do so? It would be nice if this could go in today...
-benjamin