mingw import library compatibility question

[Kai Tietz]

2010/3/9 Doug Semler <dougsemler@gmail.com>:
> Are the DLL import libraries generated by the mingw toolchain
> (specifically dlltool and ld) meant to be compatible with the native
> MS LINK tools?
>
> If they aren't, then that's no big deal (but it should be documented
> somewhere :), except that it means another step to use the MS tool to
> generate a link library based on a .def file during the build...
>
> If they are then I've been having issues with linking with them unless
> the native link command line includes /OPT:NOREF.  Apparantly the MS
> linker is throwing away the sections from the import libraries that
> include the relocations (such as idata$2, $4, etc, which is a bad
> thing, obviously).
>
> In addition, if they *are* meant to be compatible, I noticed some
> inconsistencies.  Eg:. ld (not dlltool) doesn't mark the .text
> sections of the function jump thunks (i.e. the _funcname jump to
> __imp__funcname) as readonly, and i think that those functions should
> be marked .linkonce so that they may be dropped during link if unused
> by the compilation having used __declspec(dllimport).  But before I
> open a bug report I wanted to find out whether I should open one...if
> the import libraries aren't meant to be compatible then the previous
> statements are moot :)
>

Well, this is a peak into the box of the pandora. All in all binutils
wants to be PE-COFF compatible to VC (at least VC 6). There are some
minor and some major nits, which make those import libraries
incompatible at the moment.
As you already marked, is the generation of import libraries in
binutils at the moment inconsistant (wrong section flags, .drectve
handling, etc).
For VC 2005 and newer (could be even before, but I am not absolutely
sure here) MS uses an new object file format not supported by binutils
at the moment (but silently ignored). This makes newer VC generated
import-libraries not compatible to binutils' ld Btw managed code and
some other extension are using those new object-file formats (there
are at the moment three different kinds), too. So linking VC generated
static libraries using managed code won't work, too.

Additional there is a hic-up about SECREL in binutils. This relocation
type is used (as described in PE-COFF specification) by MS for
debugging information and TLS-relocation. The gcc-toolchain uses
SECREL in terms of an image-base relocation, which is wrong in terms
of description of PE-COFF specification. So linking a VC library by ld
leads to wrong relocations).

Additional (but this is more a minor nit and can be worked-around by
windres-tool) is ld not able at the moment to link more then one
resource-object to a binary.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination