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

[Peter Rosin]

Den 2011-06-23 14:25 skrev Vadim Zeitlin:
> On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin <address@hidden> wrote:
> 
> PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> PR> >  I have no idea whether -no-undefined is supposed to work like this but 
> in
> PR> > any case it seems to me that it's perfectly useless right now. It's not
> PR> > checked at all under normal Unix systems so it can't be used to ensure 
> that
> PR> > a shared library actually doesn't have any undefined symbols and so 
> could
> PR> > be created under Windows too. And it must be always specified under
> PR> > Windows as otherwise DLL are never created at all.
> PR> 
> PR> If you really are targeting Windows (or some other platform which needs
> PR> -no-undefined to build libtool libraries) then you really do get a failure
> PR> if there are undefined symbols.
> 
>  Yes but *only* if you had "-no-undefined" in your Makefile.am. If you do
> not specify "-no-undefined", you practically silently (not quite as it does
> output "libtool: link: warning: undefined symbols not allowed in $host
> shared libraries" but this is very easy to miss) get a static library
> instead, whether there are any undefined symbols or not.
> 
>  This is even worse than the original problem that I had because at least
> you had a big fat warning with plenty of asterisks in that case because
> there was another problem in that case. But if all goes perfectly well you
> still never get a shared library without "no-undefined". Even if you
> specified --disable-static as you did in my example (although IMO even
> without it silently creating static library when a shared one was requested
> is wrong). Am I the only one to think that this behaviour is singularly
> unhelpful?

Of course not, others have stated that a patch would be welcome to
fix --disable-static (and --enable-shared) to error out if it is not
possible to create a shared library (due to a missing -no-undefined).
But fixing that is a separate issue from what the default behavior
should be when -no-undefined is not specified. The think the push-
back you are sensing is because you are mixing those two issues.

The thing is, if you really do have undefined symbols, *and* are
targeting Windows (or other platforms needing -no-undefined for "normal"
libraries), there is no (clean & simple) way to explicitly declare that
you don't want libtool to attempt to build the shared lib, you can
only implicitly declare that fact by *not* specifying -no-undefined. At
the same time, you want failures to be reported back and interrupt the
build, for cases where you really do hit undefined symbols.

Let me attempt to line up all the cases:

A. We know that there are no undefined symbols, -no-undefined is
   specified.
B. We know that there are undefined symbols, -no-undefined is
   not specified.
C. Noone has bothered to check for undefined symbols, package was
   never ported to Windows, -no-undefined is not specified.

1. --disable-static in effect
2. --disable-shared in effect
3. Build both static and shared, or whatever is possible.

For A1 and B1 we want to error out on Windows if we can't find
shared versions of all dependencies, because we do not want to
risk including static libs in the resulting shared lib, and we
don't want to fall back to a static lib since a shared lib was
explicitly requested. IMO there is a bug for this case, since
currently libtool falls back to creating a static lib when it
can satisfy missing symbols with static dependencies. You also
think this is a bug, and I don't think anyone disagrees with
you, me, Bob and Chuck that it really is a bug.

For A2, B2 and C2, there is no problem, you get a static lib.
For A3 and B3, there is no problem, but you don't get a shared lib
on Windows (as desired, don't want to risk static dependencies
inside the shared lib).

For C1, it would perhaps be nice to go looking for shared versions
of all dependencies and then attempt to link the library and fail
if any of that didn't work out. But see below (-*-).

For C3, I can agree that libtool *could* look for shared versions
of all dependencies and if found, libtool *could* attempt to create
the shared lib, hoping that there would be no undefined symbols.
I.e. just as in C1, but then not error out if any of that fails but
instead just ignore the failure and proceed with a static-only
result as if nothing happened. But I must say that it would be kind
of surprising to one day get both a static lib and a shared lib, and
the next day "silently" only get a static lib because some bozo
broke something (completely unrelated) for Windows. True, the bozo
code would perhaps fail on Windows for the static case as well,
but maybe not.

And since it is a bit fragile to make that shared attempt for the
C3 case, it would be quite surprising if the C1 case (-*-) did
succeed in creating a shared lib, but C3 didn't.

> PR> Quoting the docs for the libtool -no-undefined option:
> ...
> PR> I.e. no mention of any actual check if there were any undefined
> PR> symbols.
> 
>  I agree that the current behaviour conforms to documentation. I just think
> it's pretty bad and I dare say that I'm not alone to misunderstand it
> because of expecting something useful from this option.
> 
> PR> However, I agree that it is awkward. If this was done today, with
> PR> no backwards compatibility in mind, I'd say that -no-undefined should
> PR> be the default and any packages that truly needed undefined symbols
> PR> should somehow declare that instead, since that is more of a special
> PR> case (IMHO). But it is as it is.
> 
>  I continue to believe that it's much worse than awkward under Windows.
> Libtool should try to create DLLs there and fail if it doesn't work. Not
> even trying is the worst possible solution.

Is it really the worst possible solution? At least there are no
surprises.

>  For me the ideal behaviour would be to try to link a DLL and stop with an
> error if it doesn't work but according to the beginning of this thread,
> this is not acceptable by default. So I can only propose:
> 
> 1. At least do this when --disable-static is specified.

See above, surprising if C1 can build a shared lib, but not C3.

> 2. Try to link as DLL in any case (well, unless --disable-shared was used)
>    and only fall back to static linking if it actually failed instead of
>    giving up in advance just because -no-undefined wasn't used.

"Silently" getting only a static lib when you also got a shared one
the day before is a bit surprising.

Cheers,
Peter