llvm dev - Jul 2015 - [LLVMdev] [LLD] support for dlltool generated libs in COFF/PECOFF

Hi Ivan, :)

For testing purposes, I've managed to make the old COFF linker work with
a
> simple test case
>
Have you got patches for this that I can look at ?

Had to make two little changes, and link the exe manually, because
the
> linker doesn't understand the GNU flags
>
I've solved the issue of having a GNU driver for the linker so that's
not
an issue anymore
I sent in patches to the mailing list on this previously :)
I keep them updated over in the msys2 project btw

By the way, even the MS linker works with the binutils generated
import
> libraries.
>
Yes i assume binutils was based from a very old version of a MS linker
which did this layout at the time.
lld is so much newer and the MS linker has been updated to a more modern
layout which is why we have this issue

Kind Regards
Martell


On Sat, Jul 25, 2015 at 12:43 PM, Ivan Garramona <heavenandhell171 at
gmail.com
> wrote:
> Hi Martell.
>
> I too was trying to make the new COFF linker recognize the libraries
> generated by binutils, but it wasn't resolving the DLLs, just like you
> described. Apparently it is not identifying the libraries as import
> libraries but archives.
>
> For testing purposes, i've managed to make the old COFF linker work
with a
> simple test case. Had to make two little changes, and link the exe
> manually, because the linker doesn't understand the GNU flags, but it
> works. By the way, even the MS linker works with the binutils generated
> import libraries.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150725/cc6541e4/attachment.html>

Hi Martell,

Sorry for the belated response. I missed this email.

I took a quick look at the library file you have attached and noticed that
the file consists of regular object files. LLD expects that all dllimported
symbols are described using "short import library" (PE/COFF spec 7).
Because I didn't test LLD with dlltool-style archive files, it's no
surprise that it didn't work (although it should theoretically work).

Do you think that you can make dlltool to generate short import libraries?
If you can, it would be the easiest way to solve the issue.

On Sat, Jul 25, 2015 at 6:23 AM, Martell Malone <martellmalone at
gmail.com>
wrote:
> Hi Ivan, :)
>
> For testing purposes, I've managed to make the old COFF linker work
with a
>> simple test case
>>
> Have you got patches for this that I can look at ?
>
> Had to make two little changes, and link the exe manually, because the
>> linker doesn't understand the GNU flags
>>
> I've solved the issue of having a GNU driver for the linker so
that's not
> an issue anymore
> I sent in patches to the mailing list on this previously :)
> I keep them updated over in the msys2 project btw
>
> By the way, even the MS linker works with the binutils generated import
>> libraries.
>>
> Yes i assume binutils was based from a very old version of a MS linker
> which did this layout at the time.
> lld is so much newer and the MS linker has been updated to a more modern
> layout which is why we have this issue
>
> Kind Regards
> Martell
>
>
> On Sat, Jul 25, 2015 at 12:43 PM, Ivan Garramona <
> heavenandhell171 at gmail.com> wrote:
>
>> Hi Martell.
>>
>> I too was trying to make the new COFF linker recognize the libraries
>> generated by binutils, but it wasn't resolving the DLLs, just like
you
>> described. Apparently it is not identifying the libraries as import
>> libraries but archives.
>>
>> For testing purposes, i've managed to make the old COFF linker work
with
>> a simple test case. Had to make two little changes, and link the exe
>> manually, because the linker doesn't understand the GNU flags, but
it
>> works. By the way, even the MS linker works with the binutils generated
>> import libraries.
>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150725/3236892f/attachment.html>

Hi Rui,

Thanks for getting back to me on this

Do you think that you can make dlltool to generate short import
libraries?
> If you can, it would be the easiest way to solve the issue.
>
On my current tests ld seems to not like libraries built with short import
libraries so this would require an ABI break in binutils.

dlltool has support for loads of legacy targets and changing this would
also possibly break some of those targets so
Rather than working on dlltool I opted for creating a new tool for mingw-64
to generate libs from def files using the "short import library"
Another reason for me doing this is to have a complete clang based
mingw-w64 toolchain without any gnu gcc or binutils dependencies.

It would be ideal however if we could support what dlltool currently
produces in lld.
mingw.org toolchains will not be using the new tool I am creating and every
distribution of mingw would have to rebuild their crt's just to work with
lld.
This isn't ideal when clang is currenly used like a drop in add on for
mingw-64 toolchains.
So if it is an easy enough fix we should support this in lld
Especially when MSVC already does.

Is there much involved with supporting this on the lld end?

Many Thanks
Martell

On Sat, Jul 25, 2015 at 10:38 PM, Rui Ueyama <ruiu at google.com> wrote:
> Hi Martell,
>
> Sorry for the belated response. I missed this email.
>
> I took a quick look at the library file you have attached and noticed that
> the file consists of regular object files. LLD expects that all dllimported
> symbols are described using "short import library" (PE/COFF spec
7).
> Because I didn't test LLD with dlltool-style archive files, it's no
> surprise that it didn't work (although it should theoretically work).
>
> Do you think that you can make dlltool to generate short import libraries?
> If you can, it would be the easiest way to solve the issue.
>
> On Sat, Jul 25, 2015 at 6:23 AM, Martell Malone <martellmalone at
gmail.com>
> wrote:
>
>> Hi Ivan, :)
>>
>> For testing purposes, I've managed to make the old COFF linker work
with
>>> a simple test case
>>>
>> Have you got patches for this that I can look at ?
>>
>> Had to make two little changes, and link the exe manually, because the
>>> linker doesn't understand the GNU flags
>>>
>> I've solved the issue of having a GNU driver for the linker so
that's not
>> an issue anymore
>> I sent in patches to the mailing list on this previously :)
>> I keep them updated over in the msys2 project btw
>>
>> By the way, even the MS linker works with the binutils generated import
>>> libraries.
>>>
>> Yes i assume binutils was based from a very old version of a MS linker
>> which did this layout at the time.
>> lld is so much newer and the MS linker has been updated to a more
modern
>> layout which is why we have this issue
>>
>> Kind Regards
>> Martell
>>
>>
>> On Sat, Jul 25, 2015 at 12:43 PM, Ivan Garramona <
>> heavenandhell171 at gmail.com> wrote:
>>
>>> Hi Martell.
>>>
>>> I too was trying to make the new COFF linker recognize the
libraries
>>> generated by binutils, but it wasn't resolving the DLLs, just
like you
>>> described. Apparently it is not identifying the libraries as import
>>> libraries but archives.
>>>
>>> For testing purposes, i've managed to make the old COFF linker
work with
>>> a simple test case. Had to make two little changes, and link the
exe
>>> manually, because the linker doesn't understand the GNU flags,
but it
>>> works. By the way, even the MS linker works with the binutils
generated
>>> import libraries.
>>>
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150725/9f90b7e2/attachment.html>