Re: Adding _eh.o frame-dwarf2.o to libstdc++.so.3?

[Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>]

On Jul 28, 2000, Benjamin Kosnik <bkoz@redhat.com> wrote:

>> > However, when I go to re-generate the aclocal/configure bits in the 
>> > libstdc++-v3 subdir, I get this:
>> 
>> > ./aclocal.m4:1801: AC_LIBTOOL_SETUP was called before AC_LIBTOOL_DLOPEN
>> [...]
>> 
>> Works for me with autoconf 2.13 and both automake 1.4 and (relatively
>> recent) CVS.

> Huh? You are trying to rebuild libstdc++-v3/aclocal.m4 and 
> libstdc++-v3/configure by running "aclocal; autoconf" in the top level 
> libstdc++-v3 directory, right? 

Yup.

> 1) rh 6.2 automake 1.4 /autoconf 2.13

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])
])

The problem was that aclocal was seeing calls to AC_LIBTOOL_DLOPEN and
AC_PROG_LD in configure.in and acinclude.m4, and decided to bring
libtool.m4 in to resolve them.  For some reason, my libtool.m4-less
aclocal didn't complain about them.

-- 
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    *Please* write to mailing lists, not to me