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

Reply via email to