[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Brown
Subject: Making shared libraries (DLLs) on Windows: -no-undefined
Date: Sat, 28 Apr 2007 07:57:26 -0400

Hello All,

I was trying to build libamrnb ( 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 -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
rm -fr .libs/libamrnb.a .libs/libamrnb.dll.a .libs/ .libs/libamrnb.l
ar cru .libs/libamrnb.a  interf_dec.o interf_enc.o sp_dec.o sp_enc.o
ranlib .libs/libamrnb.a
(cd .libs && rm -f && cp -p ../

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 -rpath / usr/local/lib -version-info 2:0:0 interf_dec.lo interf_enc.lo sp_dec.lo sp_enc.l

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

        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

        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

        U __imp___iob
        U _free
        U _fwrite
        U _malloc
        U _memcpy
        U _memset
        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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]