Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hi Simon, > > Thanks for the report. However, I do not think this is a bug: > > * Simon Josefsson wrote on Wed, Jun 21, 2006 at 03:48:08PM CEST: >> Hi! I'm using Debian's mingw32 packages to build native win32 >> DLL/EXE's with libtool. I'm configuring with: >> >> --host=i586-mingw32msvc --build=i686-pc-linux-gnu >> >> However, when linking a shared library, I get this error: > [...] > >> # Used on cygwin: object dumper. >> OBJDUMP="objdump" >> >> This is incorrect on my system, the "objdump" binary is the >> i686-pc-linux-gnu objdump, which doesn't understand the Windows DLLs. >> The "correct" objdump would be called i586-mingw32msvc-objdump. > > Do you use AC_LIBTOOL_WIN32_DLL?
Hi Ralf! No. The document for that macro seems a bit terse, but I'm not using __declspec(dllexport) etc, so I guess I shouldn't use the macro? If I build GnuTLS on MSYS under Windows, I do get a DLL without using AC_LIBTOOL_WIN32_DLL. The DLL seems to work fine (well, except for some other problems, but those are my bugs). This seems to be counter to the AC_LIBTOOL_WIN32_DLL documentation -- a shared library _is_ built. Also, if I fix those DLLTOOL/OBJDUMP definitions, I do get a DLL built even under Debian. The DLL seems to work fine when transferred to the Windows hosts. Why do I need __declspec(dllexport)? In other words, what's wrong with the DLL that I get now? Hmm... Looking at the implementation of AC_LIBTOOL_WIN32_DLL, it seems that it just makes sure DLLTOOL/AS/OBJDUMP is properly found. If so, it seems to be what I need. However, then the documentation for the macro seems incorrect. Also, is there any harm in libtool always calling that macro internally? /Simon _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
