PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)

[Vadim Zeitlin]

On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin <address@hidden> wrote:

PR> Den 2011-06-23 14:25 skrev Vadim Zeitlin:
PR> > Am I the only one to think that this behaviour is singularly
PR> > unhelpful?
PR> 
PR> Of course not, others have stated that a patch would be welcome to
PR> fix --disable-static (and --enable-shared) to error out if it is not
PR> possible to create a shared library (due to a missing -no-undefined).

 Sorry for the delay, I got distracted by other things but here is finally
the promised trivial patch (I also cc it to libtool-patches just in case,
sorry if you get this message twice):

----------------------------------------------------------------------------
From: Vadim Zeitlin <address@hidden>
Date: Thu, 7 Jul 2011 17:26:43 +0200
Subject: [PATCH] Don't fall back to static libraries if building them was 
disabled.

If -no-undefined was not specified but the platform didn't support shared
libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were
built instead of shared ones, even if building them was explicitly disabled
with --disable-static configure option.

Fix this by stopping with a fatal error if a shared library can't be built in
this case instead of unexpectedly building a static library instead.

* libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when
trying to build a shared library without -no-undefined on a platform not
supporting undefined symbols in shared libraries.

Signed-off-by: Vadim Zeitlin <address@hidden>
---
 libltdl/config/ltmain.m4sh |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 8e5c588..40b1d5f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6735,9 +6735,12 @@ func_mode_link ()
        # Check to see if the archive will have undefined symbols.
        if test "$allow_undefined" = yes; then
          if test "$allow_undefined_flag" = unsupported; then
-           func_warning "undefined symbols not allowed in $host shared 
libraries"
-           build_libtool_libs=no
-           build_old_libs=yes
+           if test "$build_old_libs" = yes; then
+             func_warning "undefined symbols not allowed in $host shared 
libraries"
+             build_libtool_libs=no
+           else
+             func_fatal_error "can't build $host shared library unless 
-no-undefined is specified"
+           fi
          fi
        else
          # Don't allow undefined symbols.
-- 
1.7.2.3
----------------------------------------------------------------------------

I've tested this patch with the default and --disable-static configurations
under Windows and Linux and it behaved as expected. Maybe the error message
could be improved but I tried to remain consistent with the existing
warning, if this consideration is not important it might be better to be
more explicit about the problem and its potential solution.


PR> But fixing that is a separate issue from what the default behavior
PR> should be when -no-undefined is not specified.

 I agree with this but I still disagree that the current default behaviour
is useful. IMO both (C1) and (C3) should try to build a shared library even
if -no-undefined was not given and simply either stop with a fatal error or
fall back to a static library if it failed. I don't see how could getting a
shared library in addition to the static one in the case (C3) could ever be
a problem and getting the expected result in the case (C1) is definitely an
advantage and not a drawback.

 But I won't discuss this any more as I don't have any new arguments and
apparently the ones I already gave were insufficiently convincing.

 Regards,
VZ

pgpF2RxBIGIyf.pgp
Description: PGP signature