libtool-1.9f, cygwin: good news, bad news

[Charles Wilson]

First the good news:  libtool-1.9f built successfully on cygwin, and all 
tests passed:

====================
All 114 tests passed
====================

Then the bad news:

After installing libtool-1.9f on my system, I tried to use it to build 
m4 CVS HEAD, bootstrapping with the very latest CVS gnulib.  I mention 
this because the problems are most probably issues with libltdl and not 
specifically m4-cvs.


After fixing a few problems in m4's system_.h and .build/m4/system.h 
(having to do with include files coming from "m4/" vs. "gnu/"), I 
successfully built m4.exe.

Two big problems:
(1) A DESTDIR install showed that the following were installed --

<DESTDIR>/usr/local/bin/cygdlloader-6.dll
<DESTDIR>/usr/local/lib/libdlloader.a
<DESTDIR>/usr/local/lib/libdlloader.dll.a
<DESTDIR>/usr/local/lib/libdlloader.la
<DESTDIR>/usr/local/share/libltdl/libltdl/<lots of stuff>

That is unacceptable, from a distribution standpoint.  If every package 
that uses libltdl tries to install all of its crap, you have a BIG 
problem with file/package ownership issues.  If m4 wants to avoid using 
the system-instaled dlloader library, then it should build it as a 
convenience lib and link it in statically.  Or use the system-installed one.

(2) m4's make check failed every single test.  testsuite.log shows that 
they all failed with the following message:

+m4: cannot open module `m4': unknown error

It appears, even tho cygwin passes the pdemo, mdemo, and mdemo2 tests, 
dlpreloading is still broken on cygwin for anything more complicated 
than those simple tests (or, perhaps, m4's testsuite/autotest is not 
properly handling the case where m4.exe is run from the build directory 
during 'make test').

Note that the modules are installed as

<DESTDIR>/usr/local/libexec/m4/m4-0.dll
<DESTDIR>/usr/local/libexec/m4/m4.a
<DESTDIR>/usr/local/libexec/m4/m4.dll.a
<DESTDIR>/usr/local/libexec/m4/m4.la

(other modules present but ommitted from the above list).