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]

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


On 2013-10-11 23:52, Warren Young wrote:
> 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.

Works just fine for me.

...
$ make libsqlite3.la
[...]
$ grep dlname .libs/libsqlite3.lai
dlname='../bin/cygsqlite3-0.dll'
$ grep dlname .libs/libsqlite3.la
dlname='cygsqlite3-0.dll'
$ grep dlname libsqlite3.la
dlname='cygsqlite3-0.dll'
$ ./libtool --mode=install install libsqlite3.la /usr/local/lib
[...]
$ grep dlname /usr/local/lib/libsqlite3.la
dlname='../bin/cygsqlite3-0.dll'
$ ls /usr/local/bin/*sqlite3*
/usr/local/bin/cygsqlite3-0.dll
$ ls /usr/local/lib/*sqlite3*
/usr/local/lib/libsqlite3.a      /usr/local/lib/libsqlite3.la
/usr/local/lib/libsqlite3.dll.a

Cheers,
Peter


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