Re: OBJDUMP incorrect on cross-compiles to mingw32

[Ralf Wildenhues]

* Simon Josefsson wrote on Thu, Jun 22, 2006 at 12:28:04PM CEST:
> Ralf Wildenhues <address@hidden> writes:
> > * Simon Josefsson wrote on Wed, Jun 21, 2006 at 03:48:08PM CEST:
> >
> >> # 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?

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

Yes, the documentation is terse.  But I think you should 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

Absense of observable bugs does not imply correctness of code.  :-)

|  -- Macro: AC_LIBTOOL_WIN32_DLL
|      This macro should be used if the package has been ported to build
|      clean dlls on win32 platforms.  Usually [...]

I think the first sentence is pretty clear, even if what follows may be
outdated.

> (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.

|   [...] If this macro is not used,
|   libtool will assume that the package libraries are not dll clean
|   and will build only static libraries on win32 hosts.

Agreed, there is a mismatch between documentation and code here.
Not sure which one needs a fix; probably the documentation.

> 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.

Good.

> Why do I need __declspec(dllexport)?

When not using auto-import (and note the documentation explicitly says
data objects and not function objects).  Please read up on this feature
in
  info ld Options

It's usually best to not use public data interfaces at all.

> In other words, what's wrong with the DLL that I get now?

Probably nothing, there are just some caveats; and users not using
auto-import (for various valid reasons).  And there was a time before
auto-import.

> 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.

Yep, I guess.

> Also, is there any harm in libtool always calling that macro
> internally?

Not sure.  One cheap argument is that it saves some configure tests.
I think though that this macro used to have more effect at some time
in the darker past...

Cheers,
Ralf