Re: libtool dll creation (mingw32 undefined symbols)

[John Brown]

Hello Ralf,

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> 
> Hello Richard,
> 
> * richard wrote on Tue, Apr 17, 2007 at 11:18:24PM CEST:
> > 
> > I'd like to start slow by just crosscompile a executable and a dynamic 
> > library,
> > but i fail at building the .dll with libtool complaining about
> > >libtool: link: warning: undefined symbols not allowed in 
> > >i586-pc-mingw32msvc shared libraries
> [...]
> > The --no-undefined is set for the library,
> 
> Typo: -no-undefined (just one leading hyphen).
> 

You have already seen this on the mingw-users list, but in case any one else
wants to answer:

I was trying to build libamrnb (http://www.penguin.cz/~utx/amr) on Windows with
the MingW port of gcc, binutils, etc.

The libtool command that builds the library is:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2  -version-info 2:0:0  -o
libamrnb.la -rpath /mingw/lib interf_dec.lo interf_enc.lo sp_dec.lo sp_enc.lo

The result is:
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared
libraries
rm -fr  .libs/libamrnb.a .libs/libamrnb.dll.a .libs/libamrnb.la .libs/libamrnb.l
ai
ar cru .libs/libamrnb.a  interf_dec.o interf_enc.o sp_dec.o sp_enc.o
ranlib .libs/libamrnb.a
creating libamrnb.la
(cd .libs && rm -f libamrnb.la && cp -p ../libamrnb.la libamrnb.la)

It builds the static library, but not the shared library.

If I add '-no-undefined' like this:
/bin/sh ./libtool --mode=link gcc  -g -O2  -no-undefined -o libamrnb.la -rpath /
usr/local/lib -version-info 2:0:0 interf_dec.lo interf_enc.lo sp_dec.lo sp_enc.l
o

then the shared library is built.

As far as I can see, there are no undefined symbols. I tried to find out what it
was complaining about by running nm on the *static* library: 

nm --undefined-only .libs/libamrnb.a

interf_dec.o:
         U __imp___iob
         U _free
         U _fwrite
         U _malloc
         U _memset
         U _Speech_Decode_Frame
         U _Speech_Decode_Frame_exit
         U _Speech_Decode_Frame_init
         U _Speech_Decode_Frame_reset

interf_enc.o:
         U __imp___iob
         U _free
         U _fwrite
         U _malloc
         U _memset
         U _Speech_Encode_Frame_exit
         U _VADxSpeech_Encode_Frame
         U _VADxSpeech_Encode_Frame_init
         U _VADxSpeech_Encode_Frame_reset

sp_dec.o:
         U __imp___iob
         U _free
         U _fwrite
         U _malloc
         U _memcpy
         U _memset
sp_enc.o:
         U __alloca
         U __imp___iob
         U _acos
         U _cos
         U _floor
         U _free
         U _frexp
         U _fwrite
         U _log10
         U _malloc
         U _memcpy
         U _memset
         U _sin
         U _sqrt

It is true that the definitions of the functions in <math.h> are not in these
object files. They are in the C standard library. As for the others:

The xxx_Decode_xxx functions called by interf_dec.o are defined in sp_dec.o. The
xxx_Encode_xxx functions called by interf_enc.o are defined in sp_enc.o.
sp_dec.lo and sp_enc.lo are 3rd and 4th on the command line, and interf_dec.lo
and interf_enc.lo are 1st and 2nd.

In all cases, ld would find the symbols easily, if only libtool would try. Is
libtool really complaining about these so-called undefined symbols? If that is
so, why? Why does it not just try to build the DLL? If ld fails because of
undefined symbols, then it can say so at that time.

Is that if I am building my.dll on Windows, and it consists only of my.c, which
calls only functions in my.c, then -no-undefined is not required, but otherwise,
-no-undefined is necessary?

Should I tell the libamrnb maintainer that configure needs to add -no-undefined
on Windows, or Windows users should configure with LDFLAGS=-no-undefined?

I just want to know if this behaviour is a bug or a feature.