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.

So, I took an initial look at this. It's rather messy though...

First off, there's a bucketload of completely unnecessary def files in there, that aren't DLL files that you want to link to (but that are loaded as some sort of plugin, among other there are keyboard layout drivers...), and lots of files that have nothing exported than DllMain and something such. Getting rid of these thins down lib64 by hundred of files already.

There's 123 files that have the exact same list of symbols in lib64 and libarm32. Other than that, most have a few differences.

This is most probably since lib64 have been dumped from an older version of windows than libarm32. So for these, we should probably make some decision to just go with the newer version (even though it's dumped from an arm version), or redump def files from a current version of windows to serve as base for both.

When looking at wine's spec files, only the following DLLs have -arch annotations about functions only existing in specific architectures:
- api-ms-win-*
- msvcrt*, msvcp*, ucrtbase (and concrt140, vcruntime140)
- kernel32, kernelbase, krnl386
- ntdll, ntoskrnl
- rpcrt4
- user32
- vssapi

So for any DLL outside of these, architecture specific differences are most probably nonsignificant and we could probably go with either version.

Anyway, I'll post my initial patchset for cleaning up at least some amount of it.

// 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