Re: libtool dll creation (mingw32 undefined symbols)
Hello John, in addition to Brian's answer: * John Brown wrote on Sat, Apr 28, 2007 at 04:39:33PM CEST: > > Should I tell the libamrnb maintainer that configure needs to add > -no-undefined > on Windows, Yes, you should. > or Windows users should configure with LDFLAGS=-no-undefined? No. Because configure also uses LDFLAGS for links without libtool (for example AC_CHECK_LIB), which would then likely fail with a linker error (because it does not understand -no-undefined). A decent workaround would be ./configure make LDFLAGS=-no-undefined > I just want to know if this behaviour is a bug or a feature. Intended, so not a bug. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
Hello Ralf, Ralf Wildenhues 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 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. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
(resend, because i forgot to CC the list) Typo: -no-undefined (just one leading hyphen). thanks a lot Ralf, this was the only error. the dll compiles and i get a running .exe in ./libs (tested with wine and winXP). hurray. Actually i thought long parameters are supposed to start with "--" or at least there should be an error about a undefined command line switch. Look at the mdemo test sources, that's a test that uses libltdl. Is that a little better? Oh great, I will look into this. AC_C_CONST FWIW, I don't think you need AC_C_CONST nowadays. I think this one got added out of panic and frustration - i will remove it. Thanks again, Richard ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
Hello Richard, Please keep the libtool list in Cc:, thanks. * richard wrote on Thu, Apr 19, 2007 at 05:45:01PM CEST: > >> Typo: -no-undefined (just one leading hyphen). >> > thanks a lot Ralf, this was the only error. the dll compiles and i get a > running .exe in ./libs (tested with wine and winXP). hurray. > Actually i thought long parameters are supposed to start with "--" or at > least there should be an error about a undefined command line switch. Yep, there isn't, I guess there should be. But the way libtool works it's almost impossible to do without lots of noise: link mode only allows very few arguments through to the linker command line unchanged, and of those that it drops/needs to drop, it cannot know whether they would have raised a warning or an error with the system's compiler or linker, respectively. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
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). > i would be very thankful for an simple howto or demo program which > accomplishes what i am trying to do. > I took a look at the libltdl sources, because they compile perfectly as > a dll, but did not manage to get much out of it. Look at the mdemo test sources, that's a test that uses libltdl. Is that a little better? > >AC_C_CONST FWIW, I don't think you need AC_C_CONST nowadays. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool dll creation (mingw32 undefined symbols)
Hello list,
for a project i'd like to create a plugin mechanism, and don't want to
be the bottleneck when the project is slowly made ready for cross
compilation to win32.
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
using:
automake 1.10
autoconf 2.1.6
libtool 1.5.22
gcc 4.1.2
mingw32 3.4.5
in debian unstable
The --no-undefined is set for the library, and i tried to follow the
(maybe seriously outdated dll compilation howto from the autobook at
http://sourceware.org/autobook/autobook/autobook_252.html#SEC252)
I also tried to __declspec(dllexport) but thought that this is for data
export only -
so i think i got something wrong or don't fully understand what i am doing-
i would be very thankful for an simple howto or demo program which
accomplishes what i am trying to do.
I took a look at the libltdl sources, because they compile perfectly as
a dll, but did not manage to get much out of it.
So i am a little stuck at the moment.
here is more info how i try to get it done:
i configure it with
./configure --target=i586-mingw32msvc --host=i586-mingw32msvc
--build=i686-pc-linux-gnu --disable-static
there is a configure.ac and a Makefile am in my top-dir
and plugin.cpp plugin.h test.cpp and test.h in the src dir
their contents are:
Makfile.am:
SUBDIRS = src
configure.ac:
AC_PREREQ(2.50)
AC_INIT([amplug],[1.0],[EMAIL PROTECTED])
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_PROG_CC
AC_C_CONST
AC_C_INLINE
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
AC_SUBST([LIBTOOL_DEPS])
AC_LIB_LTDL
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT
src/Makefile.am
lib_LTLIBRARIES = libtest.la
libtest_la_SOURCES = test.cpp test.h
libtest_la_LDFLAGS = --no-undefined -version-info 0:0:0 -Wall -Werror
--debug
libtest_la_CXXFLAGS = -Wall -Werror
libtest_la_LIBADD = $(LIBADD_DL)
bin_PROGRAMS = plug
plug_SOURCES = plugin.cpp plugin.h
plug_LDADD = libtest.la
src/test.h
#ifndef TEST_H_
#define TEST_H_
#if HAVE_CONFIG_H
# include
#endif
extern "C"{
extern int computesomething(void);
}
#endif /*TEST_H_*/
src/test.cpp
#include"test.h"
int computesomething(void){
return 42;
}
src/plugin.cpp
#include"test.h"
int main(int argc, char** args){
std::cout << "testing dll crosscompile" << std::endl;
std::cout << computesomething() << std::endl;
return 0;
}
thanks in advance,
Richard
___
http://lists.gnu.org/mailman/listinfo/libtool
