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

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.

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

[Peter Rosin]

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

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

[Warren Young]

On 10/14/2013 01:47, Peter Rosin wrote:
> On 2013-10-11 23:52, Warren Young wrote:
>>      $ make libsqlite3.la
>>      $ ./libtool --mode=install install libsqlite3.la /usr/local/lib
>>
> Works just fine for me.

Thanks for testing.

It turned out to be something screwed up in the local build system.  A 
complete re-checkout and re-build fixed it.  <shrug>