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).
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