In the process of resolution of bug #244547 a conflict has been found between nvidia-driver and i386-wine-devel: both ports create the file lib32/libGL.so.1. In the case of nvidia-driver it is a regular file, in the case of i386-wine-devel it is a symlink to lib32/.libGL/libGL.so.1, installed by i386-wine-devel itself. This conflict has as a consequence that users of i386-wine-devel and nvidia-driver need to install nvidia-driver after i386-wine-devel. The issue most probably affects i386-wine as well.
danfe: I assigned to myself the bug that was automatically assigned to you as I think that it is more natural to fix the wine ports rather than nvidia drivers. Feel free to take it back if you want.
I think you just unsubscribed danfe@.
Added danfe@ back. Thanks Alex.
As for the issue itself, my preference would be to duplicate nvidia-driver's libmap.d/nvidia.conf solution (for consistency), but since apparently nobody did bother to set up /etc/libmap32.conf pointing to the /usr/local/etc/libmap32.d directory, we are stuck with symlink dance.
I can assure you it affects both: --i386-wine:3.0.4_1,1 --i386-wine-devel:4.0.r1_1,1 --i386-wine-devel-5.5,1 I had the same problem with all, same outputs, that is Wine was incapable to find/use the 32bit opengl library, and therefore incapable to start the opengl Windows executable. Checked the aformentioned libraries at both versions. First I checked with both Wine versions, whether the problem occurs with all, then re-installed the nvidia-driver, which solved the problem by re-installing the aformentioned library: ----/usr/local/lib32/libGL.so.1 To make things clear, and summarize on this thread by copying the resolution, and outputs from my own comments in the mentioned thread bug #244547: Wine changed ----/usr/local/lib32/libGL.so.1 into a symlink to --> ----/usr/local/lib32/.libGL/libGL.so.1. After FRESH Nvidia driver install ----/usr/local/lib32/libGL.so.1 IS a regular file, NOT a symlink, in my case at -- nvidia-driver version: 440.64 --> 532.0 KiB (544768 bytes). ---------------------------------------------------------------- I checked with: -- wow.exe (World of Warcraft 2.4.3 client) - (32bit executable) -- and with Godot Engine, with its 32bit Windows executable Both of them with: --i386-wine:3.0.4_1,1 --i386-wine-devel:4.0.r1_1,1 --i386-wine-devel-5.5,1 Both wow exe, and Godot 32bit exe did not work. The outputs were, generally all the same with all versions: //wow.exe (World of Warcraft 2.4.3 client): ---->> popup window saying: "Failed to find a suitable display device. Exiting program" ---->> in terminal: 0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32edd8,0x00000000), stub! 0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32ed68,0x00000000), stub! libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast 0009:err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems 0009:fixme:win:EnumDisplayDevicesW ((null),0,0x32f250,0x00000000), stub! //Godot Engine, 32bit Windows executable: ---->> in terminal: Godot Engine v3.2.1.stable.official - https://godotengine.org libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast 0009:err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems ERROR: is_viable: Error initializing GLAD At: drivers/gles2/rasterizer_gles2.cpp:166 YET, I tried the 64bit Godot Windows executable, with the normal 64bit Wine in packages (wine-5.0,1), which worked without any problem.
(In reply to daemonpup from comment #5) Can confirm that. When I've installed my system, of course I've installed nvidia-driver first so when I had my desktop done, I had the error (I'm using Guild Wars, since it's a 32bit game). Maybe if nvidia create his own links pointing to /usr/local/lib32/.libGL-nvidia/ (similar to what wine do), we'll have both libGL in the same system (in case you need the one wine installs).
Created attachment 214949 [details] just an example, did not test this I suspect it might be enough to remove symlinking from pkg-install script and add /usr/local/lib32/.libGL to the library search path after /usr/local/lib32. This would require i386-wine rebuild if/when https://reviews.freebsd.org/D25020 lands.
(In reply to Alex S from comment #7) Thanks Alex, I will soon test your patch. I will wait a few days to see if that review you linked is committed. As I do not have a nvidia graphic card, I will not be able to test if things improve for nvidia users: I will update Alex's patch so that it points to the testing packages I am going to create, so that nvidia users will be able to easily test.
Review https://reviews.freebsd.org/D25020 will not be committed before July, so I am going to test Alex's patch as soon as possible.
Alex S: I made a preliminary test for your patch: - I installed x11/nvidia-driver; - I installed emulators/i386-wine-devel after having applied your patch, but without recreating the packages. The preliminary test was successfull: with your patch applied i386-wine-devel does not overwite libGL.so.1. I am going to recreate the packages very soon for the real test. Could you please suggest a comment to add on top of nvidia.sh to describe your changes? Just create version 1.18. You might also want to add your copyright in the first lines (I am not a lawer but I think you can add it, since you modify the file with your work, even if not much).
(In reply to Lorenzo Salvadore from comment #10) > Could you please suggest a comment to add on top of nvidia.sh > to describe your changes? Just create version 1.18. Nope. I don't care about manually keeping change history in a file already tracked by a version control system. Double so for changes not limited to that file. What's the point if you'll have to consult the VCS history anyway to make sense of the change? > You might also want to add your copyright in the first lines Labeling the commit with "Submitted by" or "Suggested by" should be enough.
Gerald: I think Alex is definitely right: there is no point in tracking version for files/nvidia.sh since we have svn logs. What do you think we should do with it? I see 3 possibilities: 1 - continue updating it; 2 - stop updating it and finishing it with a note explaining that vcs logs should be refered from now on; 3 - stop updating it and remove existing history from the file. I am for option number 3: I agree with Alex so I think 1 does not make sense. I dislike 2 because it splits the history of the files into two sources: vcs logs and file itself. Moreover, option 3 has the advantage that the history removed is still accessible through vcs history.
Created attachment 215302 [details] test I have recreated the packages: here is the patch that allow users to test them. I do not have a nvidia card, so I could only determine that the patch does not break anything for non nvidia users and that the file conflict is fixed. Someone with a nvidia card should test it as well: just install the nvidia drivers and AFTER i386-wine-devel and see if wine works.
Comment on attachment 215302 [details] test Testing the patch on IRC with daemonpup it was found that I did something wrong while updating distinfo and probably in my subsequent tests as well. Those errors have nothing to do with Alex's work: his patch most probably works. I will soon update this PR with a fixed patch so that it is easy to test his work. Sorry for the inconvenience.
Created attachment 215612 [details] test (correction 1) I fixed the test patch. Besides the changes needed to have the port downloading the new binary packages correctly, I had to add only a small change to Alex's work: I removed "rm ${PREFIX}/lib32/libGL.so.1" from the DEINSTALL case in pkg-install, since the file does not exist anymore. I tested the patch successfully on a non-nvidia graphic card. Testing is now needed on a nvidia graphic card.
(In reply to Lorenzo Salvadore from comment #12) > I think Alex is definitely right: there is no point in tracking version > for files/nvidia.sh since we have svn logs. What do you think we should > do with it? I see 3 possibilities: : > 3 - stop updating it and remove existing history from the file. > > I am for option number 3: Yep, makes sense to me, too.
Tested successfully on a nvidia card with daemonpup on IRC. Gerald, Tobias: do I have mentor approval to proceed? The commit includes the "test (correction 1)" attachment and removes the history in nvidia.sh as already discussed in comments 11, 12 and 16.
(In reply to Lorenzo Salvadore from comment #17) > Gerald, Tobias: do I have mentor approval to proceed? Yes, thanks. Looks like you tested this in sufficient scenario.
A commit references this bug: Author: salvadore Date: Tue Jun 16 22:38:57 UTC 2020 New revision: 539385 URL: https://svnweb.freebsd.org/changeset/ports/539385 Log: emulators/i386-wine-devel: Fix conflict with x11/nvidia-driver Fix a conflict with x11/nvidia-driver involving the file ${PREFIX}/lib32/libGL.so.1. While here, also stop tracking a parallel and redundant history in nvidia.sh: the existing history in that file is removed so that the svn logs are now the only history source (but of course the histoty in the file can be retrieved from older revisions if needed). PR: 245496 Submitted by: iwtcex@gmail.com Reported by: daemonpup@tuta.io Tested by: daemonpup@tuta.io Approved by: gerald (mentor) Changes: head/emulators/i386-wine-devel/Makefile head/emulators/i386-wine-devel/Makefile.amd64 head/emulators/i386-wine-devel/distinfo head/emulators/i386-wine-devel/files/binbounce head/emulators/i386-wine-devel/files/nvidia.sh head/emulators/i386-wine-devel/files/pkg-install head/emulators/i386-wine-devel/pkg-plist
Fixed for i386-wine-devel. I will soon forward the fix to i386-wine as part of a bigger update.
This bug can be closed, the fix have been forwarded in ffe41e64464c.
^Triage: Assign to committer that resolved. CC original committer.