[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OBJDUMP incorrect on cross-compiles to mingw32
From: |
Simon Josefsson |
Subject: |
Re: OBJDUMP incorrect on cross-compiles to mingw32 |
Date: |
Thu, 22 Jun 2006 12:28:04 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) |
Ralf Wildenhues <address@hidden> 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