A new feature in Wine 5.0 are builtin modules in PE format. https://www.winehq.org/announce/5.0 An example using a random DLL file: $ file /usr/lib64/wine-vanilla-5.0/wine/aclui.dll.so ELF 64-bit LSB shared object, ... Pre-built Wine for Ubuntu: $ unpack wine-devel-amd64_5.0_rc6_eoan_amd64.deb $ file opt/wine-devel/lib64/wine/aclui.dll PE32+ executable (DLL) (console) x86-64, for MS Windows
You need mingw for those, personally I have it installed from crossdev and force re-enable it with EXTRA_ECONF=--with-mingw, and have my PE files just fine (I also build the PE dxvk :) Given installing and depending on mingw is not straight forward in gentoo, supporting this may be problematic. But I believe the forced "--without-mingw" could be removed at this point? Is it still a problem? I'd be happy to remove my package.env workaround. Then again, it does create a situation where the result is different based on what is installed.
(In reply to Ionen Wolkens from comment #1) > You need mingw for those, personally I have it installed from crossdev and > force re-enable it with EXTRA_ECONF=--with-mingw, and have my PE files just > fine (I also build the PE dxvk :) > > Given installing and depending on mingw is not straight forward in gentoo, > supporting this may be problematic. But I believe the forced > "--without-mingw" could be removed at this point? Is it still a problem? I'd > be happy to remove my package.env workaround. Then again, it does create a > situation where the result is different based on what is installed. I tried crossdev mingw some time ago but I uninstalled it because it requires extra work compared to installing/updating normal packages. Are there chances of mingw behaving like a normal Gentoo package in the near future?
It's pretty difficult to set up the cross compiling environment and I don't have the bandwidth to figure out how to do it. Pull requests are welcome, but closing as WONTFIX for now since I have no plans to do this.
(In reply to Nick Sarnie from comment #3) > It's pretty difficult to set up the cross compiling environment and I don't > have the bandwidth to figure out how to do it. Pull requests are welcome, > but closing as WONTFIX for now since I have no plans to do this. Before we close this, would it be possible for you to write what ebuild modifications would be the 1st steps in making cross-compiling more user-friendly?
Maybe could add user-based support? Like a mingw flag would give a warning that it'll fail without mingw and point to the gentoo mingw wiki page. It's not an optimal solution but well, plus I guess it'd also increase maintenance since would have to test it now and then.
(In reply to Jan Ziak (http://atom-symbol.net) from comment #4) > (In reply to Nick Sarnie from comment #3) > > It's pretty difficult to set up the cross compiling environment and I don't > > have the bandwidth to figure out how to do it. Pull requests are welcome, > > but closing as WONTFIX for now since I have no plans to do this. > > Before we close this, would it be possible for you to write what ebuild > modifications would be the 1st steps in making cross-compiling more > user-friendly? (In reply to Jan Ziak (http://atom-symbol.net) from comment #4) > (In reply to Nick Sarnie from comment #3) > > It's pretty difficult to set up the cross compiling environment and I don't > > have the bandwidth to figure out how to do it. Pull requests are welcome, > > but closing as WONTFIX for now since I have no plans to do this. > > Before we close this, would it be possible for you to write what ebuild > modifications would be the 1st steps in making cross-compiling more > user-friendly? I haven't investigated at all, but my institution is: First, add a mingw USE flag Second, add a dependency on the correct mingw version for the correct architecture for the correct ABI that is pulled in if the USE Is set Third, stop passing --no-mingw or do whatever to tell wine to use mingw, and see if it works It is pretty easy to get that far, but I don't know if it will require more work. Is there any reason a user would want this? Is it faster?
It's mostly for compatibility, wine's shared dlls aren't normal and cause issues when working together with native dlls (like things that wrap over other dlls).
According to following wine bug ([1] and [2] specifically) wine-staging will stop working for some applications starting with wine 5.12. wine-vanilla wouldn't work either. Currently only building wine-staging with mingw could fix this issue, according to [2]. It'd be great if mingw support could be added to both wine-staging and wine-vanilla. [1] https://bugs.winehq.org/show_bug.cgi?id=45349 [2] https://bugs.winehq.org/show_bug.cgi?id=45349#c17
