(Reposting to the list without the large files - if you want them, look @
SourceForge in the User-Contrib section)
Luca et al:
Since I'm tired of breaking each other's changes and being snippy in the cvs
commit messages, let's try TALKING it over before making the next round of
changes.
Specifically, following up on the Darwin/non-Darwin scripts, I'm wondering
if the root problem is LIBTOOL...
I thought the question was "How can we use the normal AC_PROG_LIBTOOL()
macro instead of this code":
dnl> Apple, just to be difficult, calls the gnu version glibtool...
case "${target}:${CC}" in
*-*-darwin*:* )
AC_CHECK_TOOL(LIBTOOL, glibtool)
;;
* )
AC_CHECK_TOOL(LIBTOOL, libtool)
;;
esac
See - One problem of NOT using AC_PROG_LIBTOOL is that automake LOOKS for
the AC_ value, not whether you've set LIBTOOL. So as it stands now, we
can't run automake to rebuild makefile.in... you get this error:
Makefile.am:146: library used but `LIBTOOL' not defined in `configure.in'
Researching it further, I find the macro AC_PROG_LIBTOOL in libtool.m4.in
As near as I can tell, the one in the ntop directory is close but not
exactly the 1.3.4 version. It probably matches the 1.3.5 version of libtool
(the shell script) we include. The 1.4.x versions of libtool.m4 are vastly
different.
Looking at this code in libtool.m4:
# Always use our own libtool.
LIBTOOL='$(SHELL) $(top_builddir)/libtool'
AC_SUBST(LIBTOOL)dnl
It becomes obvious why 1) we rarely see libtool problems and 2) why on
Darwin it requires the work-around above. What Luca's code does is to skip
the ntop directory version of the libtool shell script and use the installed
gnu libtool named glibtool.
Remember, the sequence if you have the tools to build aclocal.m4 is
$ cat acinclude.m4.ntop libtool.m4.in > acinclude.m4
$ aclocal
Meaning we use whatever is in libtool.m4.in as part of our aclocal.m4, not
what's installed on the user's computer.
So, I'm wondering if there's a different (non-standard) version of
libtool.m4 under Darwin, one that knows to use the glibtool program not
libtool and that might solve more of these Mac vs. non-Mac issues.
However, it may also be that simply updating to the 1.4.2 version of both
files would help solve a lot of the version conflict issues.
If I do this:
$ cp /home/bstrauss/libtool143/share/aclocal/libtool.m4 libtool.m4.in
cp: overwrite `libtool.m4.in'? y
$ cp /home/bstrauss/libtool143/bin/libtool .
cp: overwrite `./libtool'? y
to install the standard (gnu) 1.4.3 files, then the rebuild works:
$ cat acinclude.m4.ntop libtool.m4.in > acinclude.m4
$ aclocal
$ automake --gnu --copy --add-missing
$ autoconf
I've attached libtool.m4.in (1.4.3's libtool.m4), the resulting acinclude.m4
file and the libtool (from 1.4.3's bin directory). With these versions, I
think the ./configure script works in all places. Luca, please let me know.
If you can figure out what version the glibtool is, and whether it differs
from the gnu 1.4.2 version, that's important too.
Everyone else who uses platforms other than RedHat 8, I'd appreciate the
same feedback. You do not need to have the auto* tools (automake, autoconf,
libtool) installed - just substitute the three files, do your usual
./configure and make will give a usable report.
If it doesn't work, please send me the equivalent files (the native
libtool.m4 and (g)libtool from the offending system so I can look at the
differences).
-----Burton
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
