Re: MSW DLLs support in libtool

[Evgeny Grin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10.02.2016 18:23, Nick Bowler wrote:
> Libtool will transparently handles this, by not building shared
> libraries when it cannot do so.  The idea is that packages can
> still be useful without shared library support.  In my experience,
> this works very well.
I my experience, this works not really well.
If set of .dlls are prepared for some app then you'll get error only
when compiling main application, not set of libs. This is really
confusing, because all libs were created successfully (not actually,
because libtool built static instead of shared and do not report error).
This is good for some one-shot testing of proof-of-concept, but really
very bad for production.
If package is configured with some (currently not existing) option
"--enable-any-usable-form" it's OK to fallback to static even if it
wasn't requested.
But without it, this behaviour is a bad thing. Currently erroneously
built packages can be published as good packages during automated
rebuild process because even running test suite will not detect any error.
Because of it, I saw advises like: "I don't know why .dll is no created
because make finished without any error. Just go to src/somedir and run
dlltoll with *.o. This will create usable .dll."

> The -no-undefined option is a signal to libtool: "This library is
> compatible with systems that don't support undefined symbols in shared
> libraries".  It affects libtool's decision on whether or not a shared
> library is possible.
We signalled this already by LT_INIT([win32-dll]). Why we need to signal
this second time?

- -- 
Best Wishes,
Evgeny Grin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWu5xIAAoJEL96xKXqwrr0CRoH/1JtIpKNe2w7EQlUxK3qh07Y
MGRbagr8YTvI0cV0bb2qwXT5H/2DKwkNoIg2SAO1avTvNYjDX4LWIUkNNVD+nlDJ
hbGeSu0eQ0VX6oH9B3fHD0XZb8WxINk3W+gGGobM0XbXyGHccUa2lBdK9/D00wn9
QrLGGoPuL0D0R+QGAXmgKwixz3rkHFmLkhbM1kYbDIzTEGVF7vCsm5MNBtQcrED/
F12oBkBiAXwiHcdPwqr/5cVQD4qgy+WxJ0bD/Dptg7cPny7FBKRXHDf2CgHWPOl/
lZMQ+TxKI6AfYNBbqQORd3O50vAlRx4nedG1672lzQ9TfKrznMmFplU+1AXDGBI=
=wXQv
-----END PGP SIGNATURE-----