Help Needed With 14.2 MultiLib and Wine
 

I'm hesitant to lean on others so I've spent many weeks trying to figure this out and fix it but two tenacious problems remain. The first seems to be totally a Slackware issue which is this :


Since what I understand is default, I have both libpng-legacy12 1.2.23 and libpng-1.6.23 (both 64 and compat32) I don't understand why this error occurs so of course I can't conclude how to fix it. I should mention that this is my first foray into 64bit Multilib and have stuck with pure 32 bit for exactly this sort of issue until just a few months ago.

The second problem is extremely elusive since when I search for the error message I get hit after hit about problems with OSX and ATi video cards neither of which I have. I've tried different nVidia drivers and numerous GL tweaks as well as Wine registry and app specific switches none of which has fixed this issue which is quite possibly not specific to Slackware but more about Mesa and/or Wine. Please note that this problem occurs even in applications where that app is specifically commanded to default to OpenGL and that the following is just a sample of the voluminous error output all the same as this:

Also I have tried this in several versions of Wine both with and without recommended library exceptions and the output remains the same. I could possibly live with turning off winedbg or even with wasteful messaging but apps will just suddenly crash and that is not acceptable.

FWIW I am currently using Wine-Staging 2.3 but have tried several versions of Wine-2 and even dropped back to 1.9.20 for a time, all with the same d3d errors. While I am demanding OpenGL, after such errors I used winetricks to install all of the appropriate d3d9 dlls. I'm stumped and would appre4ciate any input at all. I really don't wish to drop all the way back to the wine 1.6 area or back to 32 bit Slack if I can avoid that. Thank you in advance for any assistace.

Spending weeks trying to get multilib and wine up and running is such a waste. Just use slackpkg+ with Eric's repositories. Depending on your internet connection you should have multilib and wine up and running within an hour.

I use wine 2.0 32bits downloaded from wine site for slackware 14.2.
Alien's do not work OK for me.
Works OK on multilib no png issue.
MAybe you have multilib wrong installation?

For DirectX you only need one d3dx9_25.dll override if system dll do not work.
You can also consider install IE using winetrics not for browsing but for several dll overrides that help run programs.
Some aplications do not like gecko engine and do not work or work but have some problems.
The best option is ??? IE6 :)

Hope helps.

I run multi lib and use the playonlinux build from slackbuilds works fine I need it for xfinity tv and firefox.
if you set up multilib like Alien Bob explains all you need is to add his build of OpenAl i486 and convert it to compat ok then install it.
The 64 bit build of alienbob I have had to many issues with.
If you have the latest SBOPKG then open a terminal as root and put this in therethen load that queue file and build it. it will complain at building wine but you have multilib installed so "P" to proceed.
but that said I created a libpng12 compat for much of my devel work so I do have libpng12 installed.

Do you use slackpkg+ to update multilib?

If you aren't using Nvidia binary drivers then you need 32 bit opengl libraries. The NVIDIA binary should pick up multilib and offer to install 32 bit libraries.

What I do is I use wine staging slackbuild. I download it. Then I build it after I go 32 bit using: . /etc/profile.d/32dev.sh

Then I install PlayOnLinux. It requires that a version of Wine be installed on the system but after that you can install 32 bit and 64 bit versions of wine all you want for your user with PlayOnLinux with just the 32 bit wine package installed, change wine versions for a specific program instantly and install directx and whatever else you want through its configuration menu. It downloads and installs the packages itself. A virtual drive can be created for each application.

Just FYI wine works and has worked for me for decades, usually improving considerably over time. I don't use slackpkg+ and hope I never have to. I prefer knowing exactly what is being done and keeping as close to vanilla as possible. I followed Eric's installation for multilibs carefully and to the letter. I'm not unhappy with how it runs with the exception of pulseaudio, which I passionately hate but has no problems specific to Multilib, and this tiny but important obstacle with libpng in Wine. The GL Shader thing is mysterious enough to me that I don't understand it enough to make any conclusions yet. I'm not some rank noob nor do I leap to conclusions and I don't mind spending many hours to get exactly what I want, no more and no less, if I can see a positive conclusion. Convenience and speed are of lesser concern to me, but thank you for your kindness in posting your take on this..

Thanks everyone for responding. I had hoped to provide enough explanation of what I'm running but I did neglect to mention I am now and always have used nVidia's proprietary drivers.

To try to summarize - Why is libpng 1.2.x being wrongfully called when what it wants, libpng-1.6.x, exists and should solve the problem? Of equal importance is how can I change that, as in uninstalling libpng-1.2.x or designating it for ONLY what needs it.

Secondly, since I specify OpenGL, why is d3d even an issue and what can I do to properly solve that?

If any of these solutions is a tradeoff (ie: something else will cease to work properly) I only need to know what that or those might be to determine if they are important to my system.

Again, many thanks. I love this community.

Note: I have used PlayOnLinux in the past and have liked it rather a lot but I uninstalled it in order to avoid problems with WineHQ as they don't support POL. To avoid complication, at least until I've solved this, I'd prefer to avoid POL at least for now.

Thank you very much. I do recall begrudgingly adding IE as you say "not for browsing" so I will try that and I suspect you are "right on the money" that IE6 may avoid the system takeover that later versions demand.

I am unsure about the exact meaning of your first sentence regarding DirectX. Are you saying that only one D3D override is needed? I have perhaps as many as 20 overrides.

About DirectX.

I am not game player but played for about 5 Titles for more than 10 years on wine 0.9-2.0 and for proper DirectX running that one dll was enough .
MAybe some other apps needs more . I do not know.

avoid the system takeover - If you affraid:

1. Install win10 and do not play with wine and .... linux
BUt it not protect You from other kinds of surveillance maybe worse:)
If not you have options:


2.Apps do not need IE integration.OK.
If not:

3. "FAke IE" by gecko .If app runs fine you not need to install IE.
If not:

4.Winetrics have options: IE6,7,8. The newest is 8 but from today's perspective "system takeover" is as same old as a little older IE6. So the only proper question is which one enables the best cooperation it's dlls with running app. From that point of view IE6 is a little better than IE8 in some cases IMHO But both are not much different so if apps go well with IE8 do that. If not try IE6. Do not bother with IE7 do not worth trying when the previous two are not working :)
If not :

5.You can try override every needed single dll but it needs a little hard work and knowledge and in effect at the end often do not work better or at all :)
If not:

6.Go to.....point 1 :)

Of caurse every single app may have some other needed overrides /https://appdb.winehq.org/ /like: corefonts,vcrun6sp6, riched20 /most wanted/ and other but mess with lack of IE dlls is most annoying IMHO.

I've run WINE for many years on Slackware, with a wide variety of programs, 1st 32-bit then with 64-bit with Alien Bob's multilib packages. There are several things one needs to be aware of:

1. FIXME messages: Not a damn thing you can do about these as they are placeholders for planned upstream fixes.
2. missing 32-bit libs: Alien Bob's multlib packages are not all inclusive. That is why he includes 'convertpkg-compat32'. You still have to check the dependencies for the WIN32 program for what you need to install.
3. winetricks is your friend. Keep it updated.
4. Always check https://appdb.winehq.org/ for tips and tricks for your program. It is highly unlikely you are the first to run across most issues.
5. For SBo WINE, don't use IEFIX=yes. That thing is antiquated. Use wintricks instead.
6. Do not use anyone's pre-compiled WINE.
7. WINE provides wrappers for Direct3D to OpenGL conversion for WIN32 programs that use D3D. There are no Directx/3D drivers for Linux. Most win32 use DX/D3D to some extent.
8. Never build WINE without OpenGL support. Without it, D3D may not work properly (see above). You can dll override until you are purple...
9. make sure you have properly installed the 32-bit compatibility libs of the Nvidia proprietary driver. To do this, you must install the mesa-compat32 packages.
10. I recommend to avoid WINE64 and just compile as pure WIN32. WINE64 still has a few stability issues. YMMV.
11. Run WINE in Slackware 32-bit to make sure everything works.

As for libpng, the only two packages you need for WINE-2.x is (for base Slackware):
Currently, I use and compile WINE against patches/libpng-1.6.27. Alien Bob's usually will work fine but you have no control over what he had installed when he compiled it. You must compile your own for best compatibility and stability. You need to keep an eye on the WINE changelogs and appdb for anything related to the program you are trying to run. I recommend you stick with wine-2.0 (stable), and only try wine-staging (unstable, testing, 2.x) for a damn good reason. Changing versions randomly is like pissing in the wind. WINE is trying to juggle a lot of balls at once to simulate a win32 environment. I highly recommend using the build scripts from SBo, with a few modifications, for example:
'32dev.sh' sets up a 32-bit environment for the compile. '--disable-tests' can provide a BIG performance improvement. Also, to suppress FIXME messages, to also improve speed, you can try
Or perhaps turn off all debug messages:
See: https://wiki.winehq.org/Debug_Channels

EDIT: Do NOT install/run WIN10. It is not an OS but an advertising platform with spyware. The traffic I see from it in a VM us incredible. Run Win7 if you must. Better yet, don't give your money to companies that refuse to support Linux. There is always a Linux alternative.

@kingbeowulf

This is no longer the option if you update and update is a must in term of bugs.

Microsoft are also retroactively applying telemetry updates to existing installs of Windows 7 / 8 / 8.1

Just a quick comment as I am digesting all this and still trying things out, but I just noticed (weird how quick scanning can float right past the obvious) but the version of libpmg 1.2.x that came with Slack64 is libpng12-1.2.23 and the one wine sees as being used is libpng-1.2.50. Since I did compile Wine here, with only the above mentioned versions available, I am uncertain of how any application is using the latter which does not exist on my system. Does this mean the application is hard-linked during it's compile and I need to match it when I compile wine? That seems odd to me, if it even is so.

Oh, and to steal a line from Steve Jobs, "One more thing"... I am never going to buy another version of windows beyond the Win 7 I had to get while I still had clients locked into Redmond. Thankfully it's been fulltime Linux for me for quite a few years.

The only libpng libs on 14.2 are:

aaa_elflibs package:

/usr/lib/libpng14.so.14.18.0
/usr/lib//usr/lib/libpng14.so.14.18.0

and /or/

libpng-1,6,27 from patches - this replace /usr/lib/libpng16.so.16.23.0

There is no libpng12.

If there is need it there is something wrong with your instalation packages.
Maybe you upgraded from previous version of slackware not all packages and one /dependency for wine/ need old libpng12 ?

FWIW this is not an upgrade install but a fresh 64bit Multilib install, even to the point of foregoing some apps so that I could test whether it was possible for me to find cost/benefit a net gain by going to a 64bit system. Up until just a few month ago I used a 32 bit installation which I still keep and use for comparison. I think I have solved the libpng issue by recompiling with libpng12 removed.

Important notes:

1) There is considerable differences in wine versions as to how they compile and, for some, even the address of download locations. For example, though his post was very helpful otherwise, the following lines did not work for me and had to be commented out since messages indicated the configure script did not understand those commands.

Please be aware that changes require at the very least some trial and error, and that what worked for you on one version may not for others.

2) Another note is that "fixme" lines are worth checking by your favorite search engine because these do get fixed over time and I have had happy conclusions to quite a few.

FWIW I have had much success with dugan's wine-staging Slackbuild script and prefer it over AlienBob's. I should also note that I first tried wine-staging to see if it would work for me in a performance boost, and it did prior to 2.0. I subsequently compiled 2.1, 2.2, and 2.3 and saw a steady decrease in FPS on an old game that is quite important to me and that worked very well for year. I dropped back to 2.0 staging and then finally to 1.9.20 and then 1.8.6 non staging and much to my surprise did not create the solid, high performance I'd enjoyed for so long.

For hard numbers my FPS had been so high that I happily capped FPS at 60 for extreme smoothness and consistency. In the past several months it has been an ordeal to keep a solid 30FPS and this is what instigated seeking to solve errors. Just to be certain my video card was not suffering and causing the drop, I booted Win 7 for the first time in over 2 years and copied the game to an ntfs partition so the game settings would be identicaland unlocked that games maxfps and saw over 120fps. So I am convinced my video card is healthy and that I have a software problem since this game has always run better overall in wine than in windows, largely due to my low-latency, realtime kernel and Linux's superior TCP/IP stack. So I still have a lot of work to do. The next step is dropping back to a 1.6.x wine version since that worked the best the longest.

My video card is an nVidia GTX-760 and I always drop out of X to runlevel 3 and use nVidia's installer.

Thanks again for all your comments and considerations. I will keep working on this to discover the "rotten apple" in the bushel and updating here for any interested.

OK it has taken me many more hours and I'm still having problems but at least I know where libpng12 came from. I got it from Slackbuilds.org as a legacy compatibility package which seemed then and still does the root cause of my issues. Another problem is though I'm an old hand at 32 bit Slackware I'm very new with 64bit multilib. I'm not at all certain even that I have the legacy libpng installed as wine needs it for World of Warcraft WOTLK since Slackbuilds shows both 32 bit and 64 bit versions on the same page and I downloaded them both to the same directory as the provided SlackBuild but I don't know how to be certain that a 32 bit libpng12 exists or that wine "sees" it during compile since the problem persists.

Every manner in which I try to "convertpkg-compat32 libpng-1.4.20-i486-1_slack14.1.txz" (the 32 bit version on Slackbuilds.org) I get an immediate

I'm reasonably sure this needs to be done since all of the libpng12-legacy files are installed to "usr/lib64" when it seems to me there needs to be files in "/usr/lib" for wine to use them. I'm really not one who likes hardly anything to be automatic but it does seem to me that my system should be aware that of what packages are responsible for the "/usr/lib" mutilib versions and at least ask me if that's what I want much like nVidia's proprietary driver always asks me if I want he 32 bit compatibility files installed.

To be blunt I'd go back to simple 32 bit Slackware in a little more than a heartbeat if Discord was available as source or as a 32 bit binary and not 64bit only binary run-in-place.