How to install new typelibs on multilib

[Michael Cronenworth]

Wine 5.9 installed typelibs for the first time in /usr/include: oleacc.tlb, 
stdole2.tlb, and stdole32.tlb

Are these meant to be shipped there? I cannot find the commit that did this. They're 
arch specific so how do 32-bit and 64-bit users install them at the same time?

Thanks,
Michael

[Jacek Caban]

Hi Michael,

On 02.06.2020 18:52, Michael Cronenworth wrote:
> Wine 5.9 installed typelibs for the first time in /usr/include: 
> oleacc.tlb, stdole2.tlb, and stdole32.tlb
>
> Are these meant to be shipped there? I cannot find the commit that did 
> this.

Yes, see:

https://source.winehq.org/git/wine.git/commitdiff/7a1a77b6765801b13754916026...

Those are used when one tries to build a typelib with widl that uses 
importlib(). mingw-w64 already does the same thing.
> They're arch specific so how do 32-bit and 64-bit users install them 
> at the same time?

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.

Jacek

[Michael Cronenworth]

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

[Jacek Caban]

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

[Michael Cronenworth]

On 6/2/20 12:46 PM, Jacek Caban wrote:
> 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.

Thanks for the patch, but I feel better about dropping the files from the 32-bit 
package.

Thank you,
Michael