This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Adding _eh.o frame-dwarf2.o to

On Jul 28, 2000, Benjamin Kosnik <> 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? 


> 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

The good thing is that the solution is very simple.  Replace the last
lines of the patched acinclude.m4 with:

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

The problem was that aclocal was seeing calls to AC_LIBTOOL_DLOPEN and
AC_PROG_LD 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
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]