This is the mail archive of the
mailing list for the Cygwin project.
libtool ../bin hack for cyg*.dll not working
- From: Warren Young <warren at etr-usa dot com>
- To: Cygwin Apps List <cygwin-apps at cygwin dot com>
- Date: Fri, 11 Oct 2013 15:52:32 -0600
- Subject: libtool ../bin hack for cyg*.dll not working
- Authentication-results: sourceware.org; auth=none
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
I've narrowed the problem down to a difference in the generated
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 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
$ 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.