On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler <nbow...@draconx.ca> wrote:
NB> On 2/10/16, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: NB> > On Wed, 10 Feb 2016, Peter Rosin wrote: NB> >> I agree wholeheartedly with the notion that --disable-static should end NB> >> up in a failure and not somehow degrade to a static build anyway. I NB> > NB> > Is this not the case? I have seen builds on Windows fail due to using NB> > --disable-static. NB> NB> I just tested it on a library which does not specify -no-undefined, and NB> therefore won't be built as a shared lib on Windows: This just doesn't correspond to my experience: when cross compiling from Linux using libtool 2.4.2, a static library is created. If you want to reproduce this, just clone https://github.com/vadz/test-libtool-dll and then do % libtoolize % automake --add-missing --foreign % autoconf % mkdir build-msw % cd $_ % ../configure --enable-maintainer-mode --host=i686-w64-mingw32 % make V=0 It does give the following (misleading, as there are no undefined symbols in this case) message: libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries but then proceeds with creating a static library. I don't know if this works differently under MSYS or if this was fixed since 2.4.2, but it's definitely broken here. Regards, VZ
pgpf8mAMt2IKY.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool