Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

Charles Wilson <libtool <at> cwilson.fastmail.fm> writes:

> No, what it means is that, IF the project maintainers want to support
> shared libraries (DLLs) on win32, then they must do the following -- and
> this is true regardless of whether libtool is involved.

 I think the real problem is that we differ in our understanding of how the
development of a typical project work. You assume that the developers know
in advance everything there is to know about Win32 DLLs and libtool but IME
this is not always the case, especially for the latter. So while I can't
disagree that what you wrote should happen in an ideal case, a more typical
scenario is simply that somebody tries to build the project under Windows.
If there are undefined symbol errors, they will be fixed and maybe, just
maybe, while doing it the person attempting the build will also discover
libtool --no-undefined flag but maybe not even then. What is almost certain
however is that if there are no undefined symbol errors (which is a rather
common case after all) there is going to be much head-scratching because of
libtool seemingly unmotivated refusal to build the shared libraries even
so.

 IOW maybe the simplest solution would be to just include a mention of
--no-undefined in the warning message given by libtool when it decides to
skip building the shared library. E.g. replace the current

libtool: link: warning: undefined symbols not allowed in $host shared libraries

message with something more user-friendly like this:

libtool: link: warning: Skipping the generation of the shared library as
        undefined symbols are not allowed in $host shared libraries.
        Use -no-undefined option to allow building it if there are really
        no undefined symbols.

With the current message it's far from clear that libtool isn't going to
build the shared library (it just warns about something but doesn't say
explicitly what does it mean) nor, most importantly, what can be done about
it.

> 2) Once you've gone thru the exercise in #1, now you might as well add
> -no-undefined unconditionally to your libtool invocation -- if you are
> using libtool, that is.

 Exactly! If you don't use libtool, you don't need to do anything special
and can just run the same "g++ -shared ..." command as under Unix provided
you don't really have any undefined symbols. But if you do use libtool you
need to know to use -no-undefined to prevent libtool from quasi-silently
deciding that your shared library can't be built for you.


 Anyhow, to use the terminology of Peter Rosin's reply, I'm going to resume
my efforts to provide a patch to at least fix this for the case (C1). But
personally I remain convinced that the current behaviour in case (C3) is
very unhelpful. Hopefully at least the warning message could be modified as
proposed above to make it slightly less so.

 Regards,
VZ