Currently, LLD fails to link to import libraries produced by GNU binutils.
GNU binutils import libraries aren't the same kind of short import libraries as link.exe and LLD produce, but are a plain static library containing .idata section chunks. MSVC link.exe can successfully link to them (prior to MSVC 2012, they failed if the link used -opt:ref though).
Currently, the main issue is that the whole .idata section is synthesized all in one by the IdataContents class, that doesn't allow it to be mixed with such section chunks that are linked in. This patch makes the IdataContents class produce section chunks that are sorted together with other chunks from input object files.
However, since the first object file in the static import library to be included is the function itself, that object file gets pulled in before the object file that contains the import directory header. That causes the import directory header to point at the wrong point in the IAT and import name table. If these object files are included in the same order as they are in the static library (or alphabetically), this works out fine though.
I've tested handling that by sorting object files alphabetically within each static library included, but that turned out to break linking msvcrt.lib. I've yet to figure out what the correct algorithm for doing this would be - apparently link.exe manages to do it though.