On 02.06.2020 19:16, Michael Cronenworth wrote:
On 6/2/20 12:06 PM, Jacek Caban wrote:
Arch pecific bits don't matter for importlib() (and in runtime, we use typelibs from DLL files, not from includes). I think that treating just like headers generated from IDLs should be fine.
The resulting binary files don't match:
x86: $ sha1sum /usr/include/wine/windows/stdole2.tlb 510cb2eb0328f1956a78dfedb6ea6c8d081d1c21 /usr/include/wine/windows/stdole2.tlb
x86_64: $ sha1sum /usr/include/wine/windows/stdole2.tlb a913134ff210ea3e687d3214f98e6fdb6b19f14a /usr/include/wine/windows/stdole2.tlb
This means that RPM won't treat the files the same and RPM complains about file conflicts trying to install the files (packages wine-devel.i686 and wine-devel.x86_64).
The attached hack should help. I didn't test it, but it ensures that arch is the same and also overrides timestamp (which would otherwise differ between builds). I'm not sure how to make that cleaner through...
Another solution would be to not include Wine includes (and probably tools) in 32-bit package, only 64-bit package. That's how it works when using --with-wine64 to build 32-bit Wine.
Jacek