Re: mingw import library compatibility question

[Doug Semler <dougsemler at gmail dot com>]

On Tue, Mar 9, 2010 at 9:26 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 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.

That's what I figured.  I really don't care about linking VC generated
libs via the mingw chain since the mingw crt is sufficient.  What I am
doing is using the mingw cross compiler on linux on the same code base
to generate binaries for the different systems.  The DLL generates
just fine (well, except for being unable to gc unused globals it seems
<shrug>).  All I was really caring about is whether the binutils
generated imports can be used by the MS compiler chain, which
apparently is a no at this time.  I do think that this should be
documented somewhere though :)

In this case I may have to delve into the inner workings of the
toolchain to fix/workaround it (for my job this is more than a "nice
to have" feature...i seriously doubt this is high on other peoples'
lists) and patch it in the local copy of the toolcahin...

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

Yeah, I ran into that by accident, but that's not really a big issue
for me since I've already had to do work on the MS side due to the
fact that they don't support using .rsrc sections in their static
libraries (well, they support putting them in the .lib, but no real
way of forcing their use like in the ld --whole-archive manner)...

Thanks,
Doug