With i386-wine(-devel) going away, when I attempt to log into Toontown Rewritten (http://www.toontownrewritten.com/), I get this error when the game attempts to start: 0114:err:module:open_builtin_file failed to load .so lib "/root/.i386-wine-pkg/usr/local/lib/wine/openal32.dll.so" 0114:err:module:import_dll Loading library OpenAL32.dll (which is needed by L"C:\\Program Files (x86)\\Toontown Rewritten\\TTREngine.exe") failed (error c000007a). 0114:err:module:LdrInitializeThunk Importing dlls for L"C:\\Program Files (x86)\\Toontown Rewritten\\TTREngine.exe" failed, status c0000135 Note: I had to run Wine as root since TTR's "launcher" would not work without Wine-as-root. This is insecure and a bad practice, but TTR's developers aren't exactly the best-in-class. You can disable the root check for 32-bit wine /usr/local/share/wine/pkg32.sh. This is on a 64-bit system.
I'm not quite sure about the actual reason for this error (there is some weird interaction between rpath and LD_LIBRARY_PATH there), but it can be worked around with LD_32_LIBMAP="libgcc_s.so.1 /usr/lib32/libgcc_s.so.1". We should probably add this to our wow64 wrapper script.
(In reply to Neel Chauhan from comment #0) > Note: I had to run Wine as root since TTR's "launcher" would not work without Wine-as-root. This is insecure and a bad practice, but TTR's developers aren't exactly the best-in-class. Well, it's not possible for Windows apps to know what kind of Unix account your are running. Wine always presents Window admin account, afaik.
> Well, it's not possible for Windows apps to know what kind of Unix account your are running. Wine always presents Window admin account, afaik. Yes, I know. However, Wine-as-root is more to work around a Wine bug which I forgot what it was.
(In reply to Alex S from comment #1) Any feedback on that?
Sorry for taking a week to respond, but using `LD_32_LIBMAP="libgcc_s.so.1 /usr/lib32/libgcc_s.so.1"` works.
So, what we want is to add this line to wine, wine-devel and wine-proton (with appropriate revision bumps): diff --git a/emulators/wine/files/wine-wow64.sh b/emulators/wine/files/wine-wow64.sh index a7b1efba17cc..2ec4cc31703e 100644 --- a/emulators/wine/files/wine-wow64.sh +++ b/emulators/wine/files/wine-wow64.sh @@ -33,6 +33,7 @@ do done export LD_32_LIBRARY_PATH_RPATH=y export LD_32_LIBMAP=" +libgcc_s.so.1 /usr/lib32/libgcc_s.so.1 $LOCALBASE/lib/libvulkan_intel.so $I386_ROOT/$LOCALBASE/lib/libvulkan_intel.so $LOCALBASE/lib/libvulkan_radeon.so $I386_ROOT/$LOCALBASE/lib/libvulkan_radeon.so $LD_32_LIBMAP" to counteract rpath=/usr/local/lib/gcc10 field in i386 executables (this a Mk/bsd.gcc.mk default, Wine itself doesn't set it), which makes the dynamic linker attempt to load a 64-bit version of the library which happens to be at that path on amd64. It's also possible to remove this flag at compilation time, but that would be comparatively more annoying. Now, should that be GCC's libgcc_s.so.1 rather than FreeBSD one? Not necessarily. For C code they are fully* compatible and C++ dependencies Wine loads (openal-soft and various Mesa userspace graphics drivers) are actually compiled with Clang, so that the version of the library they would normally load without rpath interference. * Well, kind of. Wine is a bit special and tends to reveal very subtle differences. I actually had some kind of crash related to exactly this library difference (base vs GCC) before, but I can't reproduce it right now. Go figure.
Neel, can you please give Alex' patch from comment 6 a try and share what you find (presumably that it fixes the issue for you)? Alex, do I assume correctly we'll also want this for wine-devel?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=316c372c7d133c416ced0bd6b1f21fdd011117eb commit 316c372c7d133c416ced0bd6b1f21fdd011117eb Author: Alex S <iwtcex@gmail.com> AuthorDate: 2021-12-05 19:22:04 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2021-12-05 19:45:31 +0000 emulators/wine: Use the right libgcc_s for 32-bit on amd64 In our situation, where we leverage 32-bit, i386 executables of Wine in an amd64 world running 64-bit executables of Wine, the rpath of $PREFIX/lib/gcc10 which Mk/bsd.gcc.mk sets for the former makes the dynamic linker attempt to load a 64-bit version of libgcc_s.so which happens to be at that location on amd64. Removing this rpath setting at compilation time would be comparatively more involved, so leverage LD_32_LIBMAP which we are already using in wine-wow64.sh to point to the system version of libgcc_s.so. This works since for C code both flavors of libgcc_s.so are fully compatible and Wine's C++ dependencies Wine (like openal-soft and various Mesa userspace graphics drivers) are actually compiled with clang. In other words we are only reverting to the version of the library they would normally load without rpath interference. Bump PORTREVISION so new packages with the tweaked script will be generated. PR: 259926 Reported by: nc Tested by: nc emulators/wine/Makefile | 1 + emulators/wine/files/wine-wow64.sh | 1 + 2 files changed, 2 insertions(+)
Alex confirmed my questions via e-mail - thank you! Damjan, I plan on forward porting this to the wine-devel port in the coming week. Any thoughts?
Too be clear, I did not mean to imply that there are any issues with libgcc_s.so and C++, I simply didn't bother to look into it. (There are definitely issues with libcxxrt/libstdc++, but that is, thankfully, not the case here.)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=6344ed87cd08032ea97adf3982fea383e7f73436 commit 6344ed87cd08032ea97adf3982fea383e7f73436 Author: Alex S <iwtcex@gmail.com> AuthorDate: 2021-12-11 19:25:53 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2021-12-11 19:25:53 +0000 emulators/wine-devel: Use the right libgcc_s for 32-bit on amd64 Forward port 316c372c7d133c416ced0bd6b1f21fdd011117eb from the main wine port: In our situation, where we leverage 32-bit, i386 executables of Wine in an amd64 world running 64-bit executables of Wine, the rpath of $PREFIX/lib/gcc10 which Mk/bsd.gcc.mk sets for the former makes the dynamic linker attempt to load a 64-bit version of libgcc_s.so which happens to be at that location on amd64. Removing this rpath setting at compilation time would be comparatively more involved, so leverage LD_32_LIBMAP which we are already using in wine-wow64.sh to point to the system version of libgcc_s.so. This works since for C code both flavors of libgcc_s.so are fully compatible and Wine's C++ dependencies Wine (like openal-soft and various Mesa userspace graphics drivers) are actually compiled with clang. In other words we are only reverting to the version of the library they would normally load without rpath interference. Bump PORTREVISION so new packages with the tweaked script will be generated. PR: 259926 Reported by: nc Tested by: nc emulators/wine-devel/Makefile | 1 + emulators/wine-devel/files/wine-wow64.sh | 1 + 2 files changed, 2 insertions(+)
With this I believe we can close this report. Thanks for your help, Alex, and the report that triggered this, Neel!