Re[4]: MSW DLLs support in libtool

On Wed, 10 Feb 2016 11:02:29 -0500 Nick Bowler <[email protected]> wrote:

NB> On 2/10/16, Vadim Zeitlin <[email protected]> wrote:
NB> > On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler <[email protected]> wrote:
NB> > NB> On 2/10/16, Bob Friesenhahn <[email protected]> wrote:
NB> > NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
NB> > NB> >> I agree wholeheartedly with the notion that --disable-static
NB> > NB> >> should end up in a failure and not somehow degrade to a static
NB> > NB> >> build anyway.
NB> > NB> >
NB> > NB> > Is this not the case?  I have seen builds on Windows fail due to
NB> > NB> > using --disable-static.
NB> > NB>
NB> > NB> I just tested it on a library which does not specify -no-undefined,
NB> > NB> and therefore won't be built as a shared lib on Windows:
NB> >
NB> > This just doesn't correspond to my experience: when cross compiling from
NB> > Linux using libtool 2.4.2, a static library is created.
NB> 
NB> I cannot reproduce it.  The build fails as expected.
NB> 
NB> Can you reproduce with the latest release of libtool (2.4.6)?  2.4.2 is
NB> very old.

 Damn, don't I feel stupid. This is indeed fixed in the latest version and
the commit fixing it was this one (just don't look at the author)

https://github.com/autotools-mirror/libtool/commit/12641bdc45d091fd1e014d242dcf271237f3c95c

I had completely forgotten that this patch got applied, sorry :-(

 But the problem with not being able to link in static libraries into a DLL
under MSW (the point (3) of the post which started this thread and the one
which I said was the most important for me) remains, even with the latest
master (2.4.6.24-5944f). It does give a long warning:

*** Warning: linker path does not have real file for library -lboost_filesystem.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libboost_filesystem and none of the candidates passed a file format test
*** using a file magic. Last file checked: /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

but it still doesn't make any sense. Interestingly enough, if I use the
full path to the static library (instead of "-L$path -lboost_filesystem"),
it says something similar:

*** Warning: Trying to link with static lib archive /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.

but then proceeds with creating a DLL.

 Can we agree that this is another bug worth fixing?
VZ

_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iEYEABECAAYFAla7af8ACgkQBupB3k9sHoZAWQCghd4t/+ZHQt5HYQ6PUm7b0d+x
wQIAn0cUBEoKd491SNBrcVjKenIcAdV0
=8GZO
-----END PGP SIGNATURE-----