Games/League Of Legends : DirectX9 error?

[Kreyren]

Once all verbs are installed I receive this error:

Originally posted by @Zemogiter in https://github.com/PhoenicisOrg/scripts/pull/797#issuecomment-454341965

[ImperatorS79]

@Kreyren Could you try to install a package like lib32-openal ? (I know it is weird but it comes from here -> https://www.reddit.com/r/leagueoflinux/comments/8ljlrb/client_cant_install_directx_9/).

[Zemogiter]

I have libopenal1:i386 package installed which is basically the same.

[Kreyren]

Emerging media-libs/openal-1.19.1::gentoo

results in same issue, unmerging media-libs-openal

---

Note that i can't reproduce the issue configuring league of legends manually -> Phoenicis bug?

[madoar]

@Kreyren what do you mean by i can't reproduce the issue configuring league of legends manually?

[Kreyren]

@madoar WOMS (Works On My System), assuming that league of legends is configured without phoenicis..

[ImperatorS79]

@Kreyren the error comes from here:

0031:err:module:load_builtin_dll failed to load .so lib for builtin L"XAudio2_2.dll": libavcodec.so.57: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type

For example I have libavcodec.so.58. @qparis How to handle this generally (because i would assume a symlink is enough)?

[plata]

This is something which pops up over and over again. I don't really see a proper way to handle it for deb and dmg (unless providing a runtime like Steam or Lutris). For flatpak it should be relatively easy.

[ImperatorS79]

Could it be possible to create a directory of symlink when phoenicis is launched for the first time? It is easy to find (with ldd) the different libs wine needs, and then you "just" have to symlink the not present ones.

[Kreyren]

@plata > This is something which pops up over and over again.

So it's problem on precompiled wine side assuming that precompiled wine is unable to use mensioned lib above?

Wait.. that's xact.. why does it call for xact dependency? League Of Legends doesn't need it?

[Kreyren]

@ImperatorS79

Could it be possible to create a directory of symlink when phoenicis is launched for the first time?

Afaik Lutris reads from specified directories on distros can we do the same here if not already present? Alike read dependencies from /lib, /lib64, etc.. ? (There is quite a lot of places to greb libs from..)

[plata]

@ImperatorS79 I don't think it's possible. Whether or not the symlink solution works strongly depends on the OS version you use. E.g. a symlink that works on Ubuntu 16.04 might not do so on 18.10.

@Kreyren the problem is that some apps require certain system libraries. As we have no control about the system (except for flatpak), we simply cannot ensure that users have them installed (unless we create dedicated packages for every possible OS version).

For these reasons I still be believe that we should try to make people use the flatpak because it will simply avoid system dependent issues.

[Kreyren]

E.g. a symlink that works on Ubuntu 16.04 might not do so on 18.10.

afaik the libraries are same everywhere just the definitions for libraries hierarchy might be different. e.i: Gentoo uses libraries from debian, fedora or what's the most sufficient at hand. I never heard of any special modifications to libraries that would make them incompatible.

the problem is that some apps require certain system libraries. As we have no control about the system (except for flatpak), we simply cannot ensure that users have them installed

I see, but why can't we greb them from the OS that it's used on? for example output error that file.so is needed for user to download and precomiled wine to use?

I can use app-portage/pfl which has e-file command that searches gentoo for libraries and where to get them. I've used it to workaround this issue on lutris.

(unless we create dedicated packages for every possible OS version).

On gentoo we don't really need precompiled wine.. just outputing a message to download specified wine version or to invoke emerge for needed version is sufficient, but it can be used for certain scenarios as precompiled..

There is also a function to provide a binhost for precompiled packages, not sure if it's of any help.

---

We can also approach it as lutris and provide something like phoenicis runtime, but i would consider that as optional hotfix or optional feature since it's rarely fix anything + it needs constant maintainance.

---

In theory why can't we introduce a feature that allows compiling wine if needed? Afaik it would solve most (if not all) issues with wine excluding compatibility limited by the implementation of wine.

and compiling wine takes few seconds if optimized..

[plata]

Our Wine is compiled already, that's not the point. Also providing a runtime doesn't make much sense. If you install via flatpak, you get a runtime already.

[Kreyren]

What is the point then? I understand that there are missing libraries?

[plata]

Yes but system libraries. Not libraries in Wine.

[Kreyren]

@plata That's what i meant..

[ImperatorS79]

@ImperatorS79 I don't think it's possible. Whether or not the symlink solution works strongly depends on the OS version you use. E.g. a symlink that works on Ubuntu 16.04 might not do so on 18.10.

Creating a symlink is the "daily" solution everyone use in front of this problem.

You can compute the full list of dependencies of phoenicis' wine (there are all build under stretch) and put them inside one single file. Then, when phoenicis starts, you check if each lib exists. Since the format is mylib.so."version", you can check first if the lib exists, second if it is the right version. In the first case, you ask the user to install the missing deps (not the case if they are deps in the .deb normally), in the second case, you create a symlink from the version wine needs the the nearest version installed.

@Kreyren Wine is compiled under the latest Debian stable. So it asks for specific libs version that may be more recent on a system.

[qparis]

@ImperatorS79 So what would your recommend?

[ImperatorS79]

Personnaly any solution that prevents me from having too much duplicated things installed. I don't know if the idea I have proposed before here is feasible or not, but since I can do it manually, I would assume a program could do it automatically ^^.

[qparis]

Maybe we can create a winebuild extension that creates a library bundle from an environment

[plata]

@ImperatorS79 it will not work. I have proposed something similar some time ago but it turned out that the symlinks do not work in all situations. They might do so if the libraries are similar enough but assuming that a symlink to the installed system libraries works in general is simply not true. Apart from this you have to keep in mind that this would possible require root privileges and (maybe more important) might completely mess up other applications on the system.

@qparis it's an option but honestly I don't think it's a good one. If you check Lutris and Steam, you will see that it's not as easy as it sounds and can create very weird subtle issue. Also, if you want to have a defined environment, it's a much better idea to use flatpak directly (in my opinion). We do not have to talk about OSX here because there we do not have so much fragmentation.

[qparis]

@plata Honestly, relying only on flatpak will cut us on a lot of users. For me, this is not the right strategy here

[plata]

Do you think rebuilding the same functionality is a better idea?

[plata]

Also I'm not saying that we have to rely only on flatpak but if you decide to use the deb, you must bare the consequences. If that's fine for you, go ahead. If not, use the flatpak.

[qparis]

Do you think rebuilding the same functionality is a better idea?

This is what we are doing for most of the others components (Lnk, Cab extracting, etc...)

[plata]

I wouldn't agree to this. Cab extract etc. is something we need in Phoenicis itself. The libraries we are talking about here are system libraries which are required by certain applications. In my opinion that's quite a difference.

[qparis]

Well for me it is the same. Cabextract is not required for all programs. One could argue that it should be a flatpak dependency, like any others. I don't see why a library like gnutls would be any difference

[plata]

cabextract is used by the installer mainly as a workaround because we miss an implementation in Java. So we have a dedicated requirement what it must do. For something like libldap, this is not the case.

We can try to extend the Wine packages and see where it will take us. It would also solve e.g. https://github.com/PhoenicisOrg/phoenicis/issues/1535. However, I'm afraid that it will cause a lot of trouble on the long run (e.g. how to handle conflicting dependencies?).

[qparis]

What kind of conflicting dependency you imagine?

[ImperatorS79]

@ImperatorS79 it will not work. I have proposed something similar some time ago but it turned out that the symlinks do not work in all situations. They might do so if the libraries are similar enough but assuming that a symlink to the installed system libraries works in general is simply not true.

Yes, but in the case it works, the problem is solved. For the case it does not work, it is just a "status quo". And if wine is always builded under latest debian stable, the probability that the libs would be too different is small.

Apart from this you have to keep in mind that this would possible require root privileges and (maybe more important) might completely mess up other applications on the system.

Not if you create the symlink in a directory somewhere in .Phoenicis. For example this:

ln -sf /lib/i386-linux-gnu/libncurses.so.6 ~/.Phoenicis/hello.so 

runs fine. You can then add the directory to the library path when launching wine.

[plata]

@qparis just the thing you would normally call "dependency hell".

@ImperatorS79 you're right. The question is: what if also the system dependency with the wrong version is not installed? I think it would be better to bundle the required dependencies directly like @qparis suggested.

I would say: let's try to bundle the libs with Wine. If it doesn't work out, we have to find another solution.

[ImperatorS79]

As I said, you ask the user to install the missing dependencies. (It should be installed through the dependency field of the .deb though)

[Kreyren]

What's status? Interested in expected solution..

i'm still for compiling wine on end-user's demand.. offers better optimization and functionality

[ImperatorS79]

Ok so I have computed a list of dependencies (using ldd) for all the .dll.so of wine, and I have this: libs.txt. There are certainly some dependencies missing here (for example: the deps of the deps ^^).

I tried my idea and ended up with a nice bash script creating the required symlink. However, that did not work for libavcodec, because the xaudio dll is requiring version 57 and nothing else.

So the only way I know to fix this is either providing wine builds for every distros or providing a "runtime" common to every wine version (the best option IMHO). To minimize the place of the runtime, one could imagine a script that checks if the libs exist on the system (using ldconfig -p | grep lib.so.x ) to download only in the "runtime" the libs that does not exist on the user distro (and thus minimizing redundancy).

[plata]

@ImperatorS79 can you open a new issue for this in the winebuild repo?

[Kreyren]

Ok so I have computed a list of dependencies (using ldd) for all the .dll.so of wine, and I have this: libs.txt.

seems insane..

Do we really want to ship wine with static libs?

Would suggest making a something like libs repo with the ability to chose required deps, but i wouldn't consider it as permanent fix..

[qparis]

There is no "right" solution of doing this, except using flatpak as @plata suggested. Flatpak is not a universal solution either. So unless you have a better alternative, we have to follow this path

[Kreyren]

@qparis Why can't we use system wine on demand then? Personally using precompiled wine is useless for me..

[qparis]

Believe me, it is not useless, even for you.

[Kreyren]

Not really considering that system wine offers supperior optimization and functionality.. like pba, esync, gallium9 that are not supported by phoenicis or using custom patches per wineprefix on demand etc..

Based on my experience in lutris precompiled wine had issues from time to time that can be fixed by using system wine which is preffered by some users afaik..

.+ it's implementation shouldn't be hard considering that phoenicis needs to invoke wine without set variables to use precompiled wine.

[qparis]

Not really considering that system wine offers supperior optimization and functionality.. like pba, esync, gallium9 that are not supported by phoenicis or using custom patches per wineprefix on demand etc.

You see, this is exactly what we want to avoid: Fragmentation. If we can prove with a large number of test that a version works great for the main part of our user base, there are no reasons to create many different cases that will lead to many bug reports.

Based on my experience in lutris precompiled wine had issues from time to time that can be fixed by using system wine which is preffered by some users afaik..

And based on mine, using system wine leads to fragmentation and regresions and bug reports. You see the point.

.+ it's implementation shouldn't be hard considering that phoenicis needs to invoke wine without set variables to use precompiled wine.

This is not a technical issue here.

[Kreyren]

And based on mine, using system wine leads to fragmentation and regresions and bug reports. You see the point.

Not really assuming that phoenicis won't corrupt the wineprefix with it's configuration, but i see your point maybe making it as hidden feature and assuming that we are going to have some method to generate bug report within phoenicis to print huge warning that bug reports from system wine are not accepted?

[qparis]

Take the problem from the other side. Assuming we need to provide reliable binaries (because wine can have regressions), and assuming we have almost all the builds avaible, why would system wine be needed?

[Kreyren]

i believe that we can't provide reliable binaries for wine on each system assuming different hardware configuration and methods that distros handle the drivers.

Regression and other issues are possible for many wine builds, but that doesn't mean that we should discourage it..

why would system wine be needed

For non-standart configuration and testing mostly + to expand phoenicis funtionality assuming that it would be used as frontend for wine configuration for those who prefers using system wine with their tweaks (compiled for specific platform instead of native, specific features, specific configuration etc..) or for usecase when precompiled wine is not sufficient to be used alike current league of legends due this issue since i believe that simmilar issues are going to be common.

.+ if not included users would just invoke it manually from CLI if needed..

.+ it shoudn't be beneficial to not include features that offers additional functionality for wine configuration assuming that phoenicis should provide a platform for contributors to make scripts. -> For example gentoo script could invoke emerge to compile wine and use it which is preffered instead of using precompiled wine.

[qparis]

This would be a total nightmare to maintain. Just imagine that we have 50+ distros and we are not yet able to maintain one single stream of scripts. I’m afraid that this scenario is not realistic

[Kreyren]

@qparis I'm practically suggesting to add a feature (as a workaround/feature) that would invoke wine $GAME_DIR on demand. What's hard to maintain on it?

About emerge i understand that the command can be invoked from the javascript? Practically golden for gentoo's/LFS/compilation-based usecase.. since portage can check if wine with required function is compiled and compile it if not present. -> ideall wine for system that precompiled can never offer..

[qparis]

@qparis I'm practically suggesting to add a feature (as a workaround/feature) that would invoke wine $GAME_DIR on demand. What's hard to maintain on it?

This is much more complex that this. Wine comes with other binaries that we need to use and are not always exposed on every disitribution, for example wineserver. We need these binaries to make script works. Not to mention architecture (x86 vs amd64 prefixes) compatibility problems, the fact that one given version cannot be run in the same time than an other one, etc... It is not because the problem appears simple to you that it is indeed simple. If you think you can tackle it, feel free to create a merge request.

About emerge i understand that the command can be invoked from the javascript? Practically golden for gentoo's/LFS/compilation-based usecase..

This command would only work on your particular case. There are more than 100 hundred linux distribution. Why would we chose to advantage the one you prefer and not another one?

since portage can check if wine with required function is compiled and compile it if not present. -> ideall wine for system that precompiled can never offer..

This is not true

[Kreyren]

This is much more complex that this. Wine comes with other binaries that we need to use and..

That is handled by user considering that system wine is used. Why would we need to do something else but configuring wineprefix using phoenicis's verbs and invoking wine through phoenicis?

POC: https://github.com/RXT067/Scripts/tree/master/KUWAC https://github.com/RXT067/Scripts/blob/master/KUWAC/CONFIGURATION/LeagueOfLegends.sh

Bash script that installs league of legends and uses system wine if required version is present. (WIP concept)

This command would only work on your particular case. There are more than 100 hundred linux distribution. Why would we chose to advantage the one you prefer and not another one?

Probably not usable for ubuntu and other distribution, but i believe that implementation is resource-friendly and it can be used for distro specific scripts.

This is not true

Why not? I can practically taky any version that i want from https://github.com/bobwya/bobwya/tree/master/app-emulation/wine-staging and compile it with required configuration alike esync, pba, samba, staging, vkd3d, etc.. (USE flags on https://packages.gentoo.org/packages/app-emulation/wine-any) + compiler is optimized based on CPU architecture that usually pulls additional patches for better compatibility.

If you think you can tackle it, feel free to create a merge request.

Not qualified for working with ~langfromhell~ JAVA atm.

Is added in my TODO and i will focus on it when i have the time for further contribs.

[ImperatorS79]

Do we really want to ship wine with static libs?

Static libs are libs directly inside an executable, .so are dynamic libs.

Would suggest making a something like libs repo with the ability to chose required deps, but i wouldn't consider it as permanent fix..

That is near what me and plata proposed. Create a runtime containing required libs from debian stretch and only downloads the one that are not installed on user computer.

Not really considering that system wine offers supperior optimization and functionality.. like pba, esync, gallium9 that are not supported by phoenicis or using custom patches per wineprefix on demand etc..

There will be a verb for gallium9 that will allow you to install it on any wine version provided by phoenicis.

i believe that we can't provide reliable binaries for wine on each system assuming different hardware configuration and methods that distros handle the drivers.

Well this does not have anything to do with system or not system wine.

For non-standart configuration and testing mostly + to expand phoenicis funtionality assuming that it would be used as frontend for wine configuration for those who prefers using system wine with their tweaks (compiled for specific platform instead of native, specific features, specific configuration etc..) or for usecase when precompiled wine is not sufficient to be used alike current league of legends due this issue since i believe that simmilar issues are going to be common.

So basically your main problem is that you want wine with pba and esync for your tests. The discussion about esync has already been done -> it would be much easier if the esync was in form of a .patch in a repo with proper tags (or directly inside wine-staging).

PBA is in my opinion really "for hardcore user". The patch is unmaintained and use cases are really limited.

[Kreyren]

That is near what me and plata proposed. Create a runtime containing required libs from debian stretch and only downloads the one that are not installed on user computer.

Seems sufficient, but it still requires constant maintainance.. Woudn't limit it on debian stretch assuming that broken lib is fixed elsewhere.

There will be a verb for gallium9 that will allow you to install it on any wine version provided by phoenicis.

Cool, like it.. now only verb for staging, pba, esync and other patches :D

Well this does not have anything to do with system or not system wine.

It does considering that provided wine is broken in phoenicis repo which i think is likely considering that rolling are using newer versions that may depend on different libs.

So basically your main problem is that you want wine with pba and esync for your tests. The discussion about esync has already been done -> it would be much easier if the esync was in form of a .patch in a repo with proper tags (or directly inside wine-staging).

well depends.. lots of winehackers are patching lots of libraries and functions in wine for their testing and usecase which is impossible on phoenicis..