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:

> On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
> > Charles Wilson <don't feed spammers> writes:
> >> No, I think --disable-static, if specified, should actually *disable
> >> static*.  That should be sufficient.
> >>
> >> If it's not doing that, then it's a bug IMO.
> > 
> >  Just to confirm: no, currently it doesn't do this. The example of my
> > original message came from libxml2 build configured with --disable-static.
> > 
> >  So should I try to create a patch making libtool fail in this case?
> 
> I think so.

 So I did try. Unfortunately I didn't succeed because after looking closer
at libtool sources, things turned out to be much more complicated than I
thought -- or at least very different from what I thought that would be.

 I naively expected the presence of "-no-undefined" in foo_la_LDFLAGS to
result in passing the equivalent of "-Wl,-no-undefined" to the compiler for
the platforms where shared libraries with undefined symbols are supported
(i.e. allow_undefind_flag != "unsupported"). But this is not at all what
happens. In fact, libtool doesn't seem to have any logic for actually
ensuring that shared libraries with -no-undefined actually have no
undefined symbols! Indeed, just look at this transcript:

        % cat configure.ac
        AC_INIT([foo],[1.0])
        AM_INIT_AUTOMAKE
        AC_CONFIG_SRCDIR([foo.c])

        LT_INIT([disable-static])
        AC_PROG_CC

        AC_CONFIG_FILES([Makefile])
        AC_OUTPUT
        % cat Makefile.am
        lib_LTLIBRARIES = libfoo.la
        libfoo_la_SOURCES = foo.c
        libfoo_la_LDFLAGS = -no-undefined
        % cat foo.c
        extern void foo();
        void foo2()
        {
            foo();
            foo();
        }
        % mkdir build && cd $_
        % ../configure >/dev/null
        % make -s
        libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
-DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\" -DVERSION=\"1.0\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.
-I.. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo -c ../foo.c  -fPIC -DPIC -o
.libs/foo.o
        libtool: link: gcc -shared  -fPIC -DPIC  .libs/foo.o    -O2   
-Wl,-soname
-Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
        libtool: link: (cd ".libs" && rm -f "libfoo.so.0" && ln -s 
"libfoo.so.0.0.0"
"libfoo.so.0")
        libtool: link: (cd ".libs" && rm -f "libfoo.so" && ln -s 
"libfoo.so.0.0.0"
"libfoo.so")
        libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la"
"libfoo.la" )


I.e. it created a shared library with undefined symbols without any
problems because it never actually passed -no-undefined to g++/ld.

 I have no idea whether -no-undefined is supposed to work like this but in
any case it seems to me that it's perfectly useless right now. It's not
checked at all under normal Unix systems so it can't be used to ensure that
a shared library actually doesn't have any undefined symbols and so could
be created under Windows too. And it *must* be always specified under
Windows as otherwise DLL are never created at all.

 And setting allow_undefined to "yes" in the beginning of func_mode_link()
(after commenting out the line above that sets it to "no") illustrates the
same point: all this logic is at best useless and at worst broken as long
as libtool doesn't have any support for actually determining whether a
library has any undefined symbols because the *only* reasonable thing to do
for any project that targets Windows is to use -no-undefined in LDFLAGS and
hope for the best. In particular, the default case of having an LTLIBRARY
that does not include -no-undefined in its LDFLAGS does not work at all
under Windows as it will never actually create a DLL.

 Frankly, more I think about it, less I understand how could this be done
intentionally. Am I misunderstanding something fundamental here or is all
this just one big horrible bug?

 In any case, I'm afraid I simply don't understand the current code well
enough (this is an euphemism, actually it doesn't make any sense at all to
me...) to provide any useful patches.

 Sorry,
VZ