Making shared libraries (DLLs) on Windows: -no-undefined

[John Brown]

Hello All,

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> iare 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 it 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?

_________________________________________________________________
Need a break? Find your escape route with Live Search Maps. 
http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01