libtool ../bin hack for cyg*.dll not working

[Warren Young]

libtool has long had a hack that causes it to install cyg*.dll into 
bindir instead of libdir by appending "/../bin" to the end of the 
installation directory.  While trying to get SQLite 3.8.1 working on 
Cygwin, I've found that this isn't working any more.  (It did work in 
SQLite 3.7.17.)

I've narrowed the problem down to a difference in the generated 
.libs/libsqlite3.lai file.

With the SQLite source repo tip, that file contains:

     dlname='cygsqlite3-0.dll'

In 3.7.17, the same line is this instead:

     dlname='../bin/cygsqlite3-0.dll'

One of the many differences between SQLite 3.7 and 3.8 is that 3.7 
shipped a libtool based on libtool 1.5, whereas the 3.8 source tree 
currently includes ltmain.sh 2.2.6 from libtool 2.4.  That's the current 
version on Cygwin, too, so re-running libtoolize or autoreconf doesn't help.

Did this feature change its nature between libtool 1.x and 2.x?

Another difference is that SQLite is no longer using automake.  Perhaps 
the Makefile.in generated from SQLite 3.7's Makefile.am was doing 
something that the handwritten Makefile.in in SQLite 3.8.1 doesn't?

If you want to see this yourself:

     $ cd some/tmp/dir
     $ fossil clone http://www.sqlite.org/cgi/src sqlite3.fossil
     $ mkdir sqlite3-head
     $ cd sqlite3-head
     $ fossil open ../sqlite3.fossil
     $ ./configure
     $ make libsqlite3.la
     $ ./libtool --mode=install install libsqlite3.la /usr/local/lib

(The latter two steps are a simplified form of "make install" without a 
lot of unrelated junk getting in the way of seeing the problem.)

Obviously, I can hack around this in my cygport file, but I'm hoping 
there's a way we can fix the SQLite build system so that it does the 
right thing without a post facto hack.