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

Warren Young
Fri Oct 11 21:52:00 GMT 2013

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:


In 3.7.17, the same line is this instead:


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 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 generated from SQLite 3.7's was doing 
something that the handwritten in SQLite 3.8.1 doesn't?

If you want to see this yourself:

     $ cd some/tmp/dir
     $ fossil clone sqlite3.fossil
     $ mkdir sqlite3-head
     $ cd sqlite3-head
     $ fossil open ../sqlite3.fossil
     $ ./configure
     $ make
     $ ./libtool --mode=install install /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.

More information about the Cygwin-apps mailing list