On 08.08.2017 22:32, Martin Storsjö wrote:
> The libarm64 directory is a copy of libarm32 with minimal modifications
> (renamings in the *.mri scripts and in Makefile.am).
In that case I don't think we should have actual copies of every single
.def file. It should be possible to use the same file
2017-08-09 14:34 GMT+02:00 Jacek Caban :
> On 08.08.2017 22:32, Martin Storsjö wrote:
>> The libarm64 directory is a copy of libarm32 with minimal modifications
>> (renamings in the *.mri scripts and in Makefile.am).
>
>
> In that case I don't think we should have actual copies of every single
> .d
On 09.08.2017 14:41, Kai Tietz via Mingw-w64-public wrote:
> 2017-08-09 14:34 GMT+02:00 Jacek Caban :
>> On 08.08.2017 22:32, Martin Storsjö wrote:
>>> The libarm64 directory is a copy of libarm32 with minimal modifications
>>> (renamings in the *.mri scripts and in Makefile.am).
>>
>> In that case
On Wed, 9 Aug 2017, Jacek Caban wrote:
On 08.08.2017 22:32, Martin Storsjö wrote:
The libarm64 directory is a copy of libarm32 with minimal modifications
(renamings in the *.mri scripts and in Makefile.am).
In that case I don't think we should have actual copies of every single
.def file. It
>
> Just out of curiosity - the 800 def files that only are available for
> x86_64 but not for i686, are they something that somebody practically care
> about? Should we try to add them to i686 as well (given that they probably
> actually exist there as well)? Do they serve any real purpose?
I do
2017-08-09 15:11 GMT+02:00 Martell Malone :
>>
>> Just out of curiosity - the 800 def files that only are available for
>> x86_64 but not for i686, are they something that somebody practically care
>> about? Should we try to add them to i686 as well (given that they probably
>> actually exist there
>
> Nevertheless llvm-dlltool should learn at least the '==' aliasing. We
> rely on it in our runtime, so I think it would be pretty helpful.
Sorry I should clarify in case I caused confusion.
llvm-dll tool supports `==` aliasing, it just does it using PE/COFF Aux
spec 3 weak externals.
binutils
Hey All,
> If I remember correctly, I will have to reconfirm though we should not
> need the @ for short import libraries
After some testing I can confirm I was correct about not needing the @
decorator for short import libraries.
Nor do we need to prepend `_`, msvc lib.exe does that automatical
