Re: MSW DLLs support in libtool

[Peter Rosin]

On 2016-02-11 12:23, Evgeny Grin wrote:
> On 11.02.2016 11:03, Peter Rosin wrote:
>> Well said, I would also like to add that libtool -no-undefined *does* *not*
>> imply ld --no-undefined. I.e. If you add libtool -no-undefined, then the
>> *only* thing that changes is that libtool actually attempts the shared
>> build.
> Libtool must attempt to build shared version if configured with
> "--enable-shared" and must not attempt to build it if configured with
> "--disable-shared". It's up to linker to fail if shared build is not
> possible. "Configure" job is to resolve everything that required.
> On W32 this sounds like "-linker-will-not-fail". Why make any
> predictions or assumptions if it possible to just try to link?

Below I will discuss the case where no --{en,dis}able-{shared,static}
options have been given to libtool.

If you have not specified any of the --{enable,disable}-{shared,static}
options and have a library that have not been declared with
-no-undefined, libtool may fail on Windows (and AIX) if libtool should
attempt a shared build. This is the reason why libtool does not even
attempt it. I'm not certain how it will go if --disable-static (or
--enable-shared) has been specified w/o -no-undefined, but there are
two options for libtool. 1) go ahead and try the shared build, or
2) fail without trying. I think 2) is what happens, but that there
used to be a bug which made libtool do a static build anyway. You can
argue that 1) should happen instead, but I see no reason not to add
-no-undefined instead, so that libtool can safely build both static
and shared when no specific --{enable,disable}-{shared,static} is given.
That is simply much more consistent. I still hate that -no-undefined
is not the default; it would have been much better to force the odd
libraries that can't live with that option to declare the reverse
situation. But alas, that ship has sailed.

Maybe, we should add a new flag -have-undefined (or something) that
these oddball libs can start using, in order to eventually phase out
-no-undefined?

>> Conditionally adding -no-undefined for systems where it matters is overly
>> defensive.
> Not agree.
> Let's consider that some dev is working on porting some lib to W32 (or
> AIX). Lib is already ported to
> Linux/Darwin/FreeBSD/OpenBSD/NetBSD/Solaris/HP-UX. And usually some
> ports contain OS-specific code parts. This developer need to add
> "-no-undefined" flag for new port. There are two choices: add flag
> unconditionally and test lib under all OSes (better - with all possible
> options and on different OS versions) or just conditionally add flag for
> specific OS. I bet which way will be chosen.

I still maintain that it is overly defensive, and that the defensive
behavior is explained by the fact that the libtool -no-undefined flag
is mixed up with ld --no-undefined. Do you understand that the libtool
flag is a NOP for all of the preexisting ports in your example? So,
even if you actually tried to make a convoluted example which would
break if -no-undefined was added unconditionally by a new port, you
failed.

> Repeat once more: with OS-specific code parts you can't add
> "-no-undefined" unconditionally.

Are you sure? The flag will only make a difference on Windows and AIX,
which is not totally out of the question to actually verify. It think
it would be a rare case indeed if it would not be ok to add it
unconditionally (if it is correct to add it at all), and I'd actually
be surprised if you could dig up /any/ such case at all (in a real
package, that is). I.e. where -no-undefined is correct for Windows but
not AIX (or vise versa).

Cheers,
Peter