wine, wine-devel install but don't work

[philroberts]

Installation appears to proceed fine, but upon running, for example, winecfg with a clean prefix:

$ WINEPREFIX=/Users/phil/cleanprefix winecfg
wine: created the configuration directory '/Users/phil/cleanprefix'
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\rundll32.exe" failed, status c0000005
err:module:DelayLoadFailureHook failed to delay load user32.dll.CreateDialogParamW
wine: Call from 0x7b42976f to unimplemented function user32.dll.CreateDialogParamW, aborting
wine: Unimplemented function user32.dll.CreateDialogParamW called at address 0x7b42976f (thread 000b), starting debugger...
err:seh:start_debugger Couldn't start debugger ("winedbg --auto 10 40") (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winecfg.exe" failed, status c0000005
$ 

Similar results with wine and wine-devel. I'm on OS X 10.9, if that matters.

[hewonen (Kimmo Sundqvist)]

A freshly installed wine under El Capitan (10.11.6) likewise does not work. And neither does wine-devel. Here is the error message from plain wine 1.8.6:

$ winecfg
err:process:__wine_kernel_init boot event wait timed out
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winecfg.exe" failed, status c0000005
$ wine --version
wine-1.8.6

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers wine wine-devel), if any.

[mf2k (Frank Schima)]

I see this now too. It must be one of the dependencies that caused this.

[mf2k (Frank Schima)]

It appears to be running 2 wineservers and that is not normal.

[mf2k (Frank Schima)]

Nevermind. It was 2 attempts to run a program. The processes don't seem to go away even when closing the terminal window!

[ryandesign (Ryan Carsten Schmidt)]

Replying to mf2k:

The processes don't seem to go away even when closing the terminal window!

I think that's to minimize startup time in case you should run another program using wine later.

[mf2k (Frank Schima)]

I did a complete source build (sudo port uninstall installed ; sudo port -s install wine-devel) with wine-devel 2.0rc5 and it works again without the runtime errors. So maybe there is a corrupt build on the buildbots.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53344.

[dershow]

I just tried a clean build, from source, of wine-devel 2.0rc5 and got the same failed run results as before. I did not uninstall everything first, as mf2k did. My guess is that the problem is that wine depends on another port and that port is not installed or being built correctly. One possibility is that some required port is being installed just with the default variant, and instead +universal is required for wine. If mf2k uninstalled everything and then installed, he might have ended up with different ports being +universal. It seems that the install order of ports can change whether ports are installed default or +universal. If some (or all?) ports are already installed, when a new port then depends on them, it seems that they are not (always?) upgraded to same variant. So the clean build might change the variants of dependents.

[mf2k (Frank Schima)]

See the recent base bug (#53322) that has been fixed on git relating to variants getting lost for ports that require +universal.

Indeed the complete source install requires more ports to be built. I will attach the list for each.

[dershow]

I don't think that the problem is solved by having the additional ports. My thinking is that one (or more) of the ports is being installed with the wrong variant. I did try to remove and reinstall wine-devel from source, and that didn't solve the problem. So, I think that the solution might be that one of the ports that I already have installed must be installed +universal. But, I don't know which one that might be. If I'm correct, what solved it for you was not rebuilding wine-devel from source. But, instead the fact that you uninstalled everything and then when you reinstalled, some other port was installed +universal that had not been. If so, just re-installing the correct, "mystery port", with the right variant should solve this problem. Is there any way to figure out which ports "should" be +universal, as required by wine-devel, versus which ones are actually installed that way?

[mf2k (Frank Schima)]

Yes, I am working on that comprehensive list of installed ports built both with and without source.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts will automatically install all required dependencies with the universal variant.

[dershow]

When I followed the migration instructions to move to a new computer, I ended up with a different set of +universal then I had had on the first machine. And, when that didn't work, I uninstalled and just installed the ports I needed directly, and ended up with yet another set. I was under the impression that there seems to a be bug where build order can affect which ports are installed +universal and which are default. Could there be a bug where some port is missed and so wine doesn't make it +universal, when it is actually required to be for wine to work?

[ryandesign (Ryan Carsten Schmidt)]

wine wouldn't be able to build if the required dependencies were not installed universal.

[dershow]

The fact that wine-devel builds fine on my machine, and on mf2k's machine, but won't run...And then mf2k uninstalled all his ports, and then rebuilt from scratch, to get it to work, suggests that something odd is going on with one of the required dependencies. Additionally, my machine has a fresh set of ports and macports that were all installed last week. If it is not an issue of universal, then do you have any other suggestions of what it could be, and how we can track it down?

[ryandesign (Ryan Carsten Schmidt)]

If wine required some ports to be universal, and you did not have them universal on your system, you would not have been able to build wine. (You would have gotten error messages about symbols not being found for the i386 architecture.) Since you were able to build, I don't think lack-of-universal is the problem. MacPorts has included code to ensure dependencies are rebuilt universal when needed, ever since universal variants started being a thing a decade ago.

Also, I have "+universal" in my variants.conf and build most ports universal, but I see the problem on my system too.

I don't know how to diagnose what the problem is.

[mf2k (Frank Schima)]

For reference purposes, here is the complete list of installed ports built entirely from source vs. just normally (i.e. archives from buildbots if available). One interesting difference was that pkgconfig was not installed universal when built from source. Note that I used latest base from git and use +python35 in my variants.conf file.

[ryandesign (Ryan Carsten Schmidt)]

pkgconfig is a build tool. It doesn't matter whether it is installed universal or not; the wine build system simply calls the pkg-config binary and it says what flags to use to link with other libraries.

I don't find the distinction of building from source vs. building from a binary package to be particularly relevant. After all, what do you think the buildbots are doing when a binary package is not available? They're building from source and then making the result available as a binary package.

One possibility that seems unlikely to me is that some port builds itself differently on different CPUs, and that when it is built on the buildbot, it is built in a way that only works on the specific CPU that's in the buildbot systems (which are Xserve3,1 with Xeon E5520 or X5520 CPUs), and that the binary that's produced will fail to work on other CPUs. The only port I know of in wine's dependency chain that's like that is gmp, and it already contains a directive that ensures it will build from source on your system and will not use a binary (see #41614). If there is another port like that, we can add that directive to that port too.

Another perhaps more likely possibility is that some port's library API or ABI changed in an incompatible way, but the authors of the library didn't indicate that by increasing the library's major version number, so we didn't know that we had to rebuild all ports using the library. If they had changed the major version number, rev-upgrade would have immediately noticed that things needed to be rebuilt against the new library.

[dershow]

Perhaps another clue is this: ​https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#GDI32.DLL So, it seems like the problem is how wine is attempting to do low level drawing. Perhaps that helps narrow down which subset of ports could be the problem?

[dershow]

I see that the wine-devel port has upgraded to 2.0rc-6. I upgraded, hoping that it would help with this problem. But the same problem remains that is installs, but doesn't run. This again suggest to me that there is an issue with a required dependency having some runtime issue.

[mf2k (Frank Schima)]

This problem has re-appeared for me on 2 machines that just updated to the latest version of Sierra 10.12.3. The strange thing is that one of the machines was running the betas all along with no problems. That machine was working with the complete source install but now appears to no longer work with this symptom. I will re-try a complete source build on it.

[dershow]

If you have a bit of time, what might help debug the problem is to force uninstall and then reinstall from source, just a few parts at a time. That way we might be able to narrow down which port is causing the problem.

[mf2k (Frank Schima)]

There are too many dependencies for me to even consider that possibility.

[dershow]

I was wondering if it is possible to force uninstall recursively? If so, we could slice it into big pieces. For example uninstalling gdk-pixbuf2 or gtk3 would each remove a large number of the dependencies. Just a thought...

[arietis (Sergei Guselnikov)]

I was able to fix the problem by force uninstalling / installing 'mesa' dependency from the source. Can anyone confirm that? So far it makes sense because the new MacOS update is related to graphics.

[SpikeLightfoot]

Thanks for the suggestion. But the Mesa un/reinstall trick didn't work for me:

>>winecfg
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winemenubuilder.exe" failed, status c0000005
err:module:DelayLoadFailureHook failed to delay load user32.dll.BroadcastSystemMessageW
wine: Call from 0x7b427241 to unimplemented function user32.dll.BroadcastSystemMessageW, aborting
wine: Unimplemented function user32.dll.BroadcastSystemMessageW called at address 0x7b427241 (thread 001f), starting debugger...
err:module:DelayLoadFailureHook failed to delay load shell32.dll.SHGetFolderPathW
wine: Call from 0x7b427241 to unimplemented function shell32.dll.SHGetFolderPathW, aborting
wine: Unimplemented function shell32.dll.SHGetFolderPathW called at address 0x7b427241 (thread 000b), starting debugger...
err:module:DelayLoadFailureHook failed to delay load comctl32.dll.InitCommonControlsEx
wine: Call from 0x7b427241 to unimplemented function comctl32.dll.InitCommonControlsEx, aborting
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winecfg.exe" failed, status c0000005
err:dbghelp_stabs:stabs_parse Unknown stab type 0x0a

[Superlokkus (Markus Klemm)]

Replying to arietis:

I was able to fix the problem by force uninstalling / installing 'mesa' dependency from the source. Can anyone confirm that? So far it makes sense because the new MacOS update is related to graphics.

Did not work for me either.(mesa @12.0.1_2 , MacPorts base version 2.4.0)

[hugo-ribeiro (Hugo Ribeiro)]

Replying to arietis:

I was able to fix the problem by force uninstalling / installing 'mesa' dependency from the source. Can anyone confirm that? So far it makes sense because the new MacOS update is related to graphics.

It didn't work for me either.

However, uninstalling all installed ports and re-installing everything from source did the trick...

[arietis (Sergei Guselnikov)]

Another port I tried to reinstall before 'mesa' is 'fontconfig'. Other than that I didn't modify anything.

[Superlokkus (Markus Klemm)]

Replying to arietis:

Another port I tried to reinstall before 'mesa' is 'fontconfig'. Other than that I didn't modify anything.

After I un and reinstalled mesa I did the same with fontconfig. Didn't help. I guess it could be one of the many sub ports like font-dec-misc and so on. But reinstalling every port sounds cumbersome

[SpikeLightfoot]

I did the whole uninstall/reinstall on all ports, and the problem remained. Then I uninstalled and reinstalled from source all of wine's and winecfg's dependencies. The result was the same:

% winecfg
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\rundll32.exe" failed, status c0000005
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winemenubuilder.exe" failed, status c0000005
err:module:DelayLoadFailureHook failed to delay load user32.dll.CreateDialogParamW
wine: Call from 0x7b427241 to unimplemented function user32.dll.CreateDialogParamW, aborting
wine: Unimplemented function user32.dll.CreateDialogParamW called at address 0x7b427241 (thread 000b), starting debugger...
err:module:DelayLoadFailureHook failed to delay load comctl32.dll.InitCommonControlsEx
wine: Call from 0x7b427241 to unimplemented function comctl32.dll.InitCommonControlsEx, aborting
err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winecfg.exe" failed, status c0000005
\winedevice.exe(34972,0x401fe000) malloc: *** error for object 0x401cf908: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

[mf2k (Frank Schima)]

Did you reboot after the re-install? Try that.

[dershow]

For anyone who just needs a function version of wine, I ended up just downloading the Mac binary from winehq.org. It seems to install and work correctly for me. While not an ideal solution, it does function as a temporary work around.

[kencu (Ken)]

I just built wine-2.0 from macports yesterday, and it works perfectly fine for me.

[SpikeLightfoot]

Replying to mf2k:

Did you reboot after the re-install? Try that.

No, I didn't until just now. No luck. Thanks for the suggestion.

[friguron (friguron)]

Hi, I'm more or less on the same ship...

I was using Wine 1.8.6 without much trouble, until the GDI32.dll error arised after some upgrade I can't remember (couldn't launch wine, couldn't launch winecfg).

I was using sierra 10.12.2, and then wine 2.0 apeared in mac ports. I installed wine 2.0, and then it suddenly came to life again, working charmlessly. Then 2-3 days ago I upgraded to Sierra 10.12.3 and again the dreaded GDI32.dll error at boot time appeared (wine, winecfg, you name it...)

I can't find any additional debug... My wine is a brick.

Tried renaming .wine directory to see if recreating it might help and it didn't.

Some debug this very morning: ​http://i.imgur.com/Ry4Izkc.png

Waiting for a miraculous fix...

Personal perception: wine in the last 6-7 months is really unstable in osx... In the past it was just rock solid and I can't remember so many issues...

Greetings.

[mf2k (Frank Schima)]

The workaround is to install wine and all dependencies from source.

[friguron (friguron)]

That's what I think I did... Or do you mean fully uninstall, fully clean/download, and then fully reinstall ?

A coworker with sierra 10.12.3 had never heard of macports. He installed just wine from 0 (really, it was a macports virgin machine), and wine show's the same faulty symptoms...

[mf2k (Frank Schima)]

I mean:

sudo port uninstall installed
sudo port -s -N install wine

Then reboot.

This can take a long time depending on your computer speed.

[friguron (friguron)]

Replying to mf2k:

I mean:

sudo port uninstall installed
sudo port -s -N install wine

Then reboot.

This can take a long time depending on your computer speed.

I think I understand what these 2 lines do, they seem to just uninstall ALL (!!!) my current packages, and then, from 0, will build just "wine" (from source). Isn't it a bit overkill? I mean, will I lose all my currently installed packages in the process...? If so, why would I want this to happen?

I think I'd better wait for some fix in the meanwhile...

[mf2k (Frank Schima)]

Yes, this is like the Migration process but takes longer because it requires building everything from source for wine. You would also need to then re-install all of the other ports you want.

[SpikeLightfoot]

sudo port uninstall installed
sudo port -s -N install wine

worked for me this time. I don't know why it didn't work for me before. Thanks mf2k.

[friguron (friguron)]

Replying to mf2k:

Yes, this is like the Migration process but takes longer because it requires building everything from source for wine. You would also need to then re-install all of the other ports you want.

I can wait then... As I said before, this is overkill (I have hundreds of ports already installed)...

OTOH, should we expect some kind of future fix for this issue (in case this is an issue) ? Or starting from now the only way to use wine from inside macports will be "installing it from source" ? Will "normal" installation work again?

Thanks.

[ryandesign (Ryan Carsten Schmidt)]

I will try to take some time to figure out what the problem is. Clearly some port(s) need to be revbumped so they're rebuilt, we just need to figure out which one(s) and ideally why.

[mf2k (Frank Schima)]

has duplicate #53506.

[casr (Chris Rawnsley)]

This appears to be working for me after a fresh install. I presume that the buildbot/administrators managed to fix the problem (Thank you!). I tested from a fresh install of MacPorts.

Prior to that, however, I was attempting to go through each dependency tree of wine's direct dependencies to narrow down the problem. I got some promising result when I uninstalled the fontconfig tree and installed from source like:

# from a fresh MacPorts...
sudo port install wine    # ... a binary install
export WINEPREFIX=`mktemp -d`/`date +%H:%m:%s`; winecfg    # -> misc errors and gdi32.dll failed to initialise
sudo port -fp uninstall expat rdepof:expat wine    # I started with expat as it was the first listed dependency.
sudo port -Ns install wine
export WINEPREFIX=`mktemp -d`/`date +%H:%m:%s`; winecfg    # -> misc errors and gdi32.dll failed to initialise
sudo port -fp uninstall fontconfig rdepof:fontconfig wine
sudo port -Ns install wine
export WINEPREFIX=`mktemp -d`/`date +%H:%m:%s`; winecfg   # -> success, winecfg dialogue appears!

I wanted to confirm that it was indeed just the fontconfig dependency tree that was causing the issue but when I reinstalled wine from a fresh MacPorts install everything was working normally. So my investigation was cut short but maybe it could still be of use...

My guess was that it might have been to do with fontconfig or any of its dependencies:

% port echo rdepof:fontconfig
bzip2                           
expat                           
freetype                        
gettext                         
gperf                           
libiconv                        
libpng                          
ncurses                         
pkgconfig                       
xz                              
zlib

[mf2k (Frank Schima)]

Replying to casr:

My guess was that it might have been to do with fontconfig or any of its dependencies:

Based on this, I tried again from scratch. It failed to start as expected. So I only rebuilt fontconfig from source and wine worked! So I think fontconfig is the culprit. If so, it is not surprising because it has caused problems with wine before - see #52029.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mf2k:

So I think fontconfig is the culprit. If so, it is not surprising because it has caused problems with wine before - see #52029.

This is a non-sequitur. #52029 was a specific bug in a new version of fontconfig, which happened to affect wine, which was later fixed by the fontconfig developers and incorporated into MacPorts. It does not follow from that that other problems you encounter in wine are caused by fontconfig, especially when there has not been a new release of fontconfig.

Nevertheless, in this case, I can confirm that rebuilding fontconfig from source allows winecfg to work where before it did not. Before blindly increasing fontconfig's revision to rebuild it, I would like to understand what the difference is between the package from the buildbot and the locally-built one. Maybe fontconfig is missing a dependency. Or maybe one of its dependencies had an incompatible library update which was not indicated as such by the increase of the library version number. I'm trying to investigate.

[Superlokkus (Markus Klemm)]

I just force uninstalled fontconfig and reinstalled it with the from source (-s -N) flags. Now it also installs

pkgconfig

, which wasn't uninstalled by the step before but it seems wasn't installed either. Maybe this was the missing dependency when build not forced by source? Also it had to rebuild some ports, I attach the console log, for further reference.

Replying to ryandesign:

Replying to mf2k:

So I think fontconfig is the culprit. If so, it is not surprising because it has caused problems with wine before - see #52029.

[Usability/usability_presentation] > uninstall -f fontconfig
--->  Unable to uninstall fontconfig @2.12.1_1+universal, the following ports depend on it:
--->  	ghostscript @9.19_0+x11
--->  	Xft2 @2.3.2_0+universal
--->  	qt5-qtbase @5.6.2_0
--->  	font-adobe-100dpi @1.0.3_0
--->  	font-adobe-75dpi @1.0.3_0
--->  	font-adobe-utopia-100dpi @1.0.4_0
--->  	font-adobe-utopia-75dpi @1.0.4_0
--->  	font-adobe-utopia-type1 @1.0.4_0
--->  	font-arabic-misc @1.0.3_0
--->  	font-bh-100dpi @1.0.3_0
--->  	font-bh-75dpi @1.0.3_0
--->  	font-bh-lucidatypewriter-100dpi @1.0.3_0
--->  	font-bh-lucidatypewriter-75dpi @1.0.3_0
--->  	font-bh-ttf @1.0.3_0
--->  	font-bh-type1 @1.0.3_0
--->  	font-bitstream-100dpi @1.0.3_0
--->  	font-bitstream-75dpi @1.0.3_0
--->  	font-bitstream-speedo @1.0.2_0
--->  	font-bitstream-type1 @1.0.3_0
--->  	font-cronyx-cyrillic @1.0.3_0
--->  	font-cursor-misc @1.0.3_0
--->  	font-daewoo-misc @1.0.3_0
--->  	font-dec-misc @1.0.3_0
--->  	font-ibm-type1 @1.0.3_0
--->  	font-isas-misc @1.0.3_0
--->  	font-jis-misc @1.0.3_0
--->  	font-micro-misc @1.0.3_0
--->  	font-misc-cyrillic @1.0.3_0
--->  	font-misc-meltho @1.0.3_0
--->  	font-misc-misc @1.1.2_0
--->  	font-mutt-misc @1.0.3_0
--->  	font-schumacher-misc @1.1.2_0
--->  	font-screen-cyrillic @1.0.4_0
--->  	font-sony-misc @1.0.3_0
--->  	font-sun-misc @1.0.3_0
--->  	font-winitzki-cyrillic @1.0.3_0
--->  	font-xfree86-type1 @1.0.4_0
--->  	cairo @1.14.8_0+quartz+universal+x11
--->  	texlive-bin @2016_4+x11
--->  	wireshark @1.12.8_3+geoip+gnutls+ipv6+libgcrypt+libsmi+rtp+ssl+x11
--->  	poppler @0.51.0_0
--->  	wine-devel @2.1_0
--->  	gd2 @2.2.4_1+x11
--->  	gnuplot @5.0.5_2+aquaterm+luaterm+pangocairo+qt5+wxwidgets+x11
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating fontconfig @2.12.1_1+universal
--->  Cleaning fontconfig
--->  Uninstalling fontconfig @2.12.1_1+universal
--->  Cleaning fontconfig
[Usability/usability_presentation] > quit
Goodbye
^[[AMarkus-MacBook-Pro:usability_presentation markus$ sudo port -s -N install fontconfig
--->  Computing dependencies for fontconfig
--->  Dependencies to be installed: pkgconfig
--->  Fetching distfiles for pkgconfig
--->  Attempting to fetch pkg-config-0.29.1.tar.gz from http://nue.de.distfiles.macports.org/pkgconfig
--->  Verifying checksums for pkgconfig
--->  Extracting pkgconfig
--->  Applying patches to pkgconfig
--->  Configuring pkgconfig
--->  Building pkgconfig
--->  Staging pkgconfig into destroot
--->  Installing pkgconfig @0.29.1_0
--->  Activating pkgconfig @0.29.1_0
--->  Cleaning pkgconfig
--->  Fetching distfiles for fontconfig
--->  Attempting to fetch fontconfig-2.12.1.tar.bz2 from http://nue.de.distfiles.macports.org/fontconfig
--->  Verifying checksums for fontconfig
--->  Extracting fontconfig
--->  Applying patches to fontconfig
--->  Configuring fontconfig
--->  Building fontconfig
--->  Staging fontconfig into destroot
--->  Installing fontconfig @2.12.1_1
--->  Activating fontconfig @2.12.1_1
--->  Cleaning fontconfig
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 35 broken files, matching files to ports     
--->  Found 4 broken ports, determining rebuild order
--->  Rebuilding in order
     Xft2 @2.3.2 +universal
     cairo @1.14.8 +quartz+universal+x11
     pango @1.40.3 +quartz+universal+x11
     gtk3 @3.22.7 +universal+x11
--->  Computing dependencies for Xft2
--->  Dependencies to be installed: fontconfig
--->  Fetching distfiles for fontconfig
--->  Verifying checksums for fontconfig
--->  Extracting fontconfig
--->  Applying patches to fontconfig
--->  Configuring fontconfig
--->  Building fontconfig
--->  Staging fontconfig into destroot
--->  Installing fontconfig @2.12.1_1+universal
--->  Deactivating fontconfig @2.12.1_1
--->  Cleaning fontconfig
--->  Activating fontconfig @2.12.1_1+universal
--->  Cleaning fontconfig
--->  Cleaning Xft2
--->  Computing dependencies for cairo
--->  Cleaning cairo
--->  Computing dependencies for pango
--->  Cleaning pango
--->  Computing dependencies for gtk3
--->  Cleaning gtk3
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.                             
Markus-MacBook-Pro:usability_presentation markus$ 

[mf2k (Frank Schima)]

Replying to ryandesign:

Replying to mf2k:

So I think fontconfig is the culprit. If so, it is not surprising because it has caused problems with wine before - see #52029.

This is a non-sequitur. #52029 was a specific bug in a new version of fontconfig, which happened to affect wine, which was later fixed by the fontconfig developers and incorporated into MacPorts. It does not follow from that that other problems you encounter in wine are caused by fontconfig, especially when there has not been a new release of fontconfig.

Fair enough. However, it is not surprising to me and I should have tried that first. :)

[casr (Chris Rawnsley)]

Replying to mf2k:

Based on this, I tried again from scratch. It failed to start as expected.

Hang on, that is odd. I did a full reinstall as well except wine worked for me. That is why I presented my findings as anecdotal at best. To be clear I did:

sudo port uninstall -fp installed
sudo rm -rf /opt
cd /tmp
curl -LO https://github.com/macports/macports-base/releases/download/v2.4.0/MacPorts-2.4.0.tar.bz2
tar xjf MacPorts-2.4.0.tar.bz2
cd MacPorts-2.4.0
./configure && make
sudo make install
sudo port install wine
export WINEPREFIX=`mktemp -d`/`date +%H:%m:%s`; winecfg

Other things I noticed as odd (but I certainly don't know enough about it) were a series of ports that were reinstalled as +universal. I can't remember if the +universals were a product of the wine install or some other ports though. Can a mix of "fat and thin" binaries affect a build?

[Superlokkus (Markus Klemm)]

May it be related to ​https://bugs.winehq.org/show_bug.cgi?id=42481 ?

[kencu (Ken)]

Replying to casr:

Other things I noticed as odd (but I certainly don't know enough about it) were a series of ports that were reinstalled as +universal.

wine is 32 bit only (see in portfile: supported_archs i386) so all of it deps need to be rebuilt with 32-bit slices for it to work (ie universal).

[ryandesign (Ryan Carsten Schmidt)]

Replying to Superlokkus:

May it be related to ​https://bugs.winehq.org/show_bug.cgi?id=42481 ?

I don't think so. That talks about SIP-related problems. SIP has existed since El Capitan, but we only saw this problem appear recently, so I don't think it's an SIP-related problem. The original report was on Mavericks which does not have SIP.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Superlokkus:

I just force uninstalled fontconfig and reinstalled it with the from source (-s -N) flags. Now it also installs

pkgconfig

, which wasn't uninstalled by the step before but it seems wasn't installed either. Maybe this was the missing dependency when build not forced by source?

No, that's not what I'm talking about. pkgconfig is a declared build dependency. That means it's only needed at build time, not if you install a pre-built package. I'm talking about undeclared library dependencies—libraries which are used if present, but which are not listed in the port's dependencies. I noticed that after rebuilding from source, fontconfig.pc mentions libpng, which it didn't before, since fontconfig doesn't declare a dependency on libpng. I don't know if this relates at all to the problem we're investigating, but it was a difference I observed.

Also it had to rebuild some ports, I attach the console log, for further reference.

You asked MacPorts to uninstall fontconfig (universal), then install it (non-universal). This broke the ports you had installed that relied on fontconfig being installed universal (Xft2, cairo, pango, gtk3, because you have all of them installed with the universal variant, because that's required by wine). MacPorts fixed this for you by reinstalling fontconfig (universal). No bug, just user error.

[friguron (friguron)]

Hi, any solution (apart from building wine from scratch from sources) after 2-3 months of wine not working using the typical installation method?

Greetings...

[ryandesign (Ryan Carsten Schmidt)]

friguron, the workaround seems to be to rebuild fontconfig from source.

sudo port -ns upgrade --force fontconfig

I have not yet figured out why that works or what we need to do to provide a fix in MacPorts.

[friguron (friguron)]

Replying to ryandesign:

friguron, the workaround seems to be to rebuild fontconfig from source.

sudo port -ns upgrade --force fontconfig

I have not yet figured out why that works or what we need to do to provide a fix in MacPorts.

Reading and re-reading this thread many times in the last months, I would have never deducted that reinstalling just fontconfig from source (a really quick fix), wine would become usable again. As I suspected I'm not a MacPorts quirks expert :)

Thanks a lot anyway!!

[casr (Chris Rawnsley)]

Replying to ryandesign:

I have not yet figured out why that works or what we need to do to provide a fix in MacPorts.

(This is certainly not going to satisfy the itch to fix the root cause of this but…) fontconfig has been an unnecessary dependency for Wine on macOS since 1.5.10 when they switched to using Core Text by default.

See ​https://source.winehq.org/git/wine.git/commit/9cb7a97981

[ryandesign (Ryan Carsten Schmidt)]

Replying to casr:

(This is certainly not going to satisfy the itch to fix the root cause of this but…) fontconfig has been an unnecessary dependency for Wine on macOS since 1.5.10 when they switched to using Core Text by default.

There are other tickets and pull requests that cover that aspect.

[casr (Chris Rawnsley)]

Replying to ryandesign:

There are other tickets and pull requests that cover that aspect.

I thought it would be handy to know in case some people were only following this ticket.

[mf2k (Frank Schima)]

I am no longer able to reproduce this problem. I believe that the latest commits that restructured the port fixed it.