Re: MSW DLLs support in libtool

[Evgeny Grin]

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



On 12.02.2016 23:23, Bob Friesenhahn wrote:
> On Fri, 12 Feb 2016, Evgeny Grin wrote:
> 
>> option is NOP for anything except W32 and AIX.
>> Moreover, if it does matter only for W32 and AIX, let's rename it to
>> "-w32-aix-shared-compatible". And add more flags, like
>> "-linux-compatible", "-open-bsd-compatible". This will signal libtool
>> that developed checked compatibility of build system with specific OS.
> 
> We don't do this sort of thing since we have no control over the future
> and don't know what the future will bring.  So we use generic options. 
> If we try to guess what the future may bring then we may guess wrong and
> someone will take us to task about our bad decisions.
It's not a future. It's present time. Currently "-no-undefined" means
"-w32-shared-compatible" or "-w32-aix-shared-compatible" (you know
better, but I can't find information about it in documentation. Not for
AIX, not for Windows)
We have a number of OSes. Let's add "-bsd-shared-compatible" and
"-darwin-shared-compatible" (plus some more). This will improve
compilation success as with those flags libtool will know that build
system is compatible with specific OS.
Does it correspond current libtool logic?

>> Anyway, what's drawback of assuming "-no-undefined" on W32 and AIX (or
>> on all platforms)?
> 
> As previously explained, it is more likely to lead to compilation
> success for packages which have not been crafted/tuned to succeed on
> targets where -no-undefined makes a difference.
Actually not. If static is disabled, build without "-no-undefined" must
be failed on W32, but can be succeed if tried. Does it improve something?
Even with enabled static, why not to try linking? Libtool can build
static upon result of linker. This will significantly improve number of
successful builds.

> A core Autotools principle is that the person compiling the software
> should be in control as much as possible.  This includes people who just
> received a tarball and are not the developer of the software. Another
> core principle is that defaulting to imperfect success is better than
> utter failure.
Than libtool failed at lest in two important points:
* You can't prevent fallback to static.
* You can't be sure that build result in what requested even if build
succeed.
No control at all for those.

Libtool is the only exception in GNU toolchain, including GCC, binutils
and autotools where "enable" means "may be". Could you name at least one
option (preferable important) in other tools where "enable" means "may be"?

Instead of hiding failures (which are totally *unobvious* even for
developers) is much better to fail with message like
'*** Linking shared lib failed. Try configure with options
"--disable-shared --enable-static".'
This will help much more!
It's very common that "make" output is dozen of tens screens and libtool
message is somewhere in the middle. It's really hard to understand
what's wrong, especially if you don't know what you need to find in this
text.

And using "-no-undefined" in LDFLAGS is not continent at all. You should
add it in the end of configure or any other link/run test will fail.

One more question. If compatibility with Win32 DLL is already signalled
by LT_INIT([win32-dll]) why is required to signal it again by
"-no-undefined"?

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

iQEcBAEBCAAGBQJWv25xAAoJEL96xKXqwrr0ieIIAKuI6n8AcdYKtdsGoNKAaWIh
KXLLYw/ZDquEqcS6RkVxG/dgFGDzMa8UkPPqpEhyN55qPsldJfd5BfcoE5056eeL
sTMvmJpqpBi5O03y2Bx5i2hNYkpusXyylJKaxwxMDF7ZcnOuR+Sr0nOokdXo6VQa
ZnTp0h3zTsmtX4JT7NpX20vYC7Y+tpHsj+ylNmVYYMu+76QfVeMC07Kt6QRLpOD2
JJ0GbvB96G+DW0IN2T4wAClFjChLjst6IINSSG/ZojJ1lmp5yxnPlWcGy2nqyMvU
3rIiJeHlq/sljBiMSu5lLpUVTLGxAylBjy9zzCMQDpa85XByBfg//QgSt+uAJnI=
=v4+N
-----END PGP SIGNATURE-----