Bug 245496 - emulators/i386-wine{-devel} and x11/nvidia-driver: conflict on lib32/libGL.so.1
Summary: emulators/i386-wine{-devel} and x11/nvidia-driver: conflict on lib32/libGL.so.1
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Li-Wen Hsu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-09 21:59 UTC by Lorenzo Salvadore
Modified: 2021-06-10 00:37 UTC (History)
7 users (show)

See Also:
Alexander88207: maintainer-feedback+


Attachments
just an example, did not test this (2.32 KB, patch)
2020-05-28 03:55 UTC, Alex S
no flags Details | Diff
test (4.63 KB, patch)
2020-06-06 22:54 UTC, Lorenzo Salvadore
no flags Details | Diff
test (correction 1) (4.86 KB, patch)
2020-06-16 12:21 UTC, Lorenzo Salvadore
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lorenzo Salvadore freebsd_committer freebsd_triage 2020-04-09 21:59:38 UTC
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.
Comment 1 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-04-09 22:02:34 UTC
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.
Comment 2 Alex S 2020-04-09 22:18:30 UTC
I think you just unsubscribed danfe@.
Comment 3 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-04-09 22:20:19 UTC
Added danfe@ back.

Thanks Alex.
Comment 4 Alex S 2020-04-09 22:29:56 UTC
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.
Comment 5 daemonpup 2020-04-09 23:04:20 UTC
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.
Comment 6 Daniel Menelkir 2020-05-01 13:46:30 UTC
(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).
Comment 7 Alex S 2020-05-28 03:55:31 UTC
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.
Comment 8 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-28 09:17:10 UTC
(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.
Comment 9 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-01 20:11:45 UTC
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.
Comment 10 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-05 00:08:44 UTC
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).
Comment 11 Alex S 2020-06-05 00:33:05 UTC
(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.
Comment 12 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-05 08:54:44 UTC
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.
Comment 13 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-06 22:54:22 UTC
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 14 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-15 23:52:20 UTC
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.
Comment 15 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-16 12:21:27 UTC
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.
Comment 16 Gerald Pfeifer freebsd_committer freebsd_triage 2020-06-16 12:30:46 UTC
(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.
Comment 17 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-16 19:15:57 UTC
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.
Comment 18 Gerald Pfeifer freebsd_committer freebsd_triage 2020-06-16 21:06:07 UTC
(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.
Comment 19 commit-hook freebsd_committer freebsd_triage 2020-06-16 22:39:17 UTC
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
Comment 20 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-06-16 22:40:21 UTC
Fixed for i386-wine-devel.

I will soon forward the fix to i386-wine as part of a bigger update.
Comment 21 Alexander Vereeken 2021-06-09 21:10:38 UTC
This bug can be closed, the fix have been forwarded in ffe41e64464c.
Comment 22 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-10 00:37:45 UTC
^Triage: Assign to committer that resolved. CC original committer.