>
> 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 don't want to put this on you for this patch but while we are on this
discussion, I want to bring the issue up.
The same thing should apply to x64 and x86 also.
binutils dlltool and mingw-w64 does some weird wrapping of the `_` for x86
to make it appear more like x64 symbols that is not done by msvc lib.exe
and the msvc headers.
We would ideally update dlltool and mingw-w64 to not do this anymore.

In llvm I left room to easily enable and disable this for llvm-dlltool
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/COFFModuleDefinition.h#L48

I talked to Rui a little bit before about adding a flag for llvm-dlltool to
disable this
The same flag should be added to dlltool so that we can share def files
between all 4 targets.

For the rest, I guess it needs more or less manual labour to sort out the
> differences into some sort of template like what I described. The i686 ones
> with stdcall probably aren't mergeable at all, unless we do even more
> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).

If I remember correctly, I will have to reconfirm though we should not need
the @ for short import libraries but binutils dlltool doesn't use short
import libs. :(
ld supports them however.. even though it does not support the PE/COFF Aux
spec 3 for weak externals i.e. the `==` functions in llvm-dlltool
So there are 3 issues here at least for sharing i686 with the rest.

With that in mind it might be a good idea just to share the other 3 for now
leaving i686 as is?




On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö <mar...@martin.st> wrote:

> 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 should be possible to use the same files for both
>> platforms by simply modifying Makefile.am. Maybe we should have libarm/
>> for common files and then libarm32/ and libarm64/ for things that
>> differ? I'm not sure about the exact solution, but I think we should
>> share those one way or another.
>>
>
> That'd probably be a good idea - the size of the total amount of def files
> is staggering. There's >1100 def files in libarm32 weighing in over 7 MB.
> This patch, generated with git format-patch -C, is even 400 KB, just to
> describe the copied files... lib64 also has got about as many files, while
> lib32 only has got a bit over 300 files.
>
> 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?
>
>
> That said, most DLLs probably are mostly identical, but some might have
> minor differences. Ideally these should be dumped from real DLL files, just
> like on previous platforms, but since platform isn't really available yet,
> it's not really doable, so I started out with the one that is most probable
> to be similar, and then meant to add other changes on top once we know more
> details.
>
> Ideally we'd do something like wine, with minor arch annotations in the
> spec files for the few functions that differ. Perhaps something with CPP
> macros, like we already have for def-include/msvcrt-common.def.in - with
> macros like FUNC_ARM_ARM64(fabsf) or something such.
>
> I guess the first step would be to try to compare what we have and unify
> those that are easily mergeable (that already are identical). Hopefully
> that'd be the vast majority of them.
>
> For the rest, I guess it needs more or less manual labour to sort out the
> differences into some sort of template like what I described. The i686 ones
> with stdcall probably aren't mergeable at all, unless we do even more
> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4).
>
> // Martin
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to