This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]