wine, wine-devel: CUPS not functioning

[j.s.steer@…]

On the ports page of wine-devel -- trunk/dports/x11/wine-devel/Portfile​ configure.args is shown to have cups supported (--with-cups) however wine-devel is still failing to detect any printers through CUPS and wine-devel and keeps giving me a message that I need to install a printer before it can print in wine-devel.

[jmroot (Joshua Root)]

Please remember to cc the maintainers.

[ryandesign (Ryan Carsten Schmidt)]

I have no idea how to print from wine or how to configure wine to allow printing. If you can discover the answer, let me know.

[j.s.steer@…]

In my experience of wine from Linux, wine utilizes the CUPS built into the linux distro to emulate printing as if it were an actual print driver that would normally be installed in windows. It seems in the case of wine for macports this isn't happening. Could this be a pathway issue in one of the wine files or is there a way to preconfigure it to enable CUPS beyond the configure.args snippet about CUPS?

[chrisk@…]

Cc Me!

[chrisk@…]

In looking into this problem for myself, I found posts in wine forums pointing to similar issues. There, it was confirmed to be a problem with the dlopen() call used by wine to link libcups.2.dylib. It seems the macports version of wine does not setup wine in such a way as to allow it to link from /usr/lib where lib cups.2.dylib is found.

To fix on my system after doing a fresh update of macports and wine, I set and exported DL_LIBRARY_PATH to /usr/lib and then ran "wine notepad". Inside Notepad, I could then access the printers. Once that was done, wine printing worked fine for other apps. I am not sure all the mechanics at work here, but it seems that link is remembered as the environment variable is not needed once the first successful link has completed.

Further research leads me here where I believe the core problem is the wine wrapper script (from the macports wine.in source file) overrides the normal DYLD_FALLBACK_LIBRARY_PATH value. It seems macports needs to add /usr/lib to the value of DYLD_FALLBACK_LIBRARY_PATH in wine.in (trunk/dports/x11/wine-devel/files/wine.in?rev=40116​).

[ryandesign (Ryan Carsten Schmidt)]

Thanks for this analysis. I can easily change the wrapper script to make this change. However I'm surprised it's necessary. My understanding was that DYLD_FALLBACK_LIBRARY_PATH is the path to look for libraries in if they can't be found in any of the usual library paths, and surely /usr/lib is a usual library path. All mention of DYLD_FALLBACK_LIBRARY_PATH in the ​wine FAQ only mentions setting it to the path where X11 libraries are found, which is exactly what we set it to in our wrapper script.

Could you try the attached patch and let me know if it actually helps? If so I'll be happy to apply it.

The "normal DYLD_FALLBACK_LIBRARY_PATH value", by the way, is the empty string. Without the wrapper script setting this variable, wine was all kinds of broken at the time, and I assume that's still the case.

[ryandesign (Ryan Carsten Schmidt)]

does this patch help?

[chrisk@…]

I believe having an empty value for DYLD_FALLBACK_LIBRARY_PATH actually means "$HOME/lib;/usr/local/lib;/usr/lib" somewhere inside the dlopen() logic. At least that is what I gather from the Apple reference here:

​https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html#//apple_ref/c/func/dlopen

As such, having macports set its own value, seems to not just have the positive effect of adding a new path. It also seems to have a negative effect of causing dlopen() to ignore the standard paths. Based on that assumption, forcing /usr/lib back in as you are doing with your new patch makes sense and is likely the safest approach to solve this problem.

A slightly broader approach for your consideration would be to add a little intelligence to the setting of the FALLBACK value. My thought is to have the wrapper script tack its new path value on the tail end of whatever FALLBACK value is already set. In cases where nothing has been previously set, it would plug in the documented standard system defaults. Something like this:

DYLD_FALLBACK_LIBRARY_PATH="${DYLD_FALLBACK_LIBRARY:-$HOME/lib:/usr/local/lib:/usr/lib}:@PREFIX@/lib"

Thoughts?

[ryandesign (Ryan Carsten Schmidt)]

Replying to chrisk@…:

I believe having an empty value for DYLD_FALLBACK_LIBRARY_PATH actually means "$HOME/lib;/usr/local/lib;/usr/lib" somewhere inside the dlopen() logic. At least that is what I gather from the Apple reference here:

​https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html#//apple_ref/c/func/dlopen

As such, having macports set its own value, seems to not just have the positive effect of adding a new path. It also seems to have a negative effect of causing dlopen() to ignore the standard paths.

Interesting. That document does seem to say that. I would have expected LD_LIBRARY_PATH and/or DYLD_LIBRARY_PATH and/or some internal mechanism to contain the list of standard library paths, and for DYLD_FALLBACK_LIBRARY_PATH to only be used if the library is not found there. But I guess that's not how it works.

Based on that assumption, forcing /usr/lib back in as you are doing with your new patch makes sense and is likely the safest approach to solve this problem.

Instead of just assuming, can you actually test the patch and verify that it fixes the problem you experienced? If it does, I'm happy to commit it.

A slightly broader approach for your consideration would be to add a little intelligence to the setting of the FALLBACK value. My thought is to have the wrapper script tack its new path value on the tail end of whatever FALLBACK value is already set. In cases where nothing has been previously set, it would plug in the documented standard system defaults. Something like this:

DYLD_FALLBACK_LIBRARY_PATH="${DYLD_FALLBACK_LIBRARY:-$HOME/lib:/usr/local/lib:/usr/lib}:@PREFIX@/lib"

We definitely don't want wine to find or use any libraries in /usr/local/lib or $HOME/lib. Also, we would want @PREFIX@/lib to be searched before /usr/lib, as in the patch I already attached. I have no particular interest in extending a value of DYLD_FALLBACK_LIBRARY_PATH the user might already have set; that would only introduce more opportunities for failure; I like that the wrapper script sets its own value that ignores any value the user might have already set.

[chrisk@…]

Replying to ryandesign@…:

Instead of just assuming, can you actually test the patch and verify that it fixes the problem you experienced? If it does, I'm happy to commit it.

I have confirmed your suggested patch to the wine wrapper script does fix the problem.

[ryandesign (Ryan Carsten Schmidt)]

Thanks. I've learned something new about OS X today! I've fixed this in wine in r90731.

I'll fix wine-devel when the next development version of wine is released. Usually they release development versions every two weeks so we shouldn't have long to wait.

I imagine wine-crossover and wine-crossover-games are also affected. New versions of wine-crossover (#33618) and wine-crossover-games (#33055) are already out so this fix could be bundled with those updates.

[ryandesign (Ryan Carsten Schmidt)]

Actually wine-crossover and wine-crossover-games are not affected: it looks like Jeremy already fixed wine-crossover-games in r79679, and wine-crossover was created by copying wine-crossover-games in r79680. I wish I had known about this so we could have fixed wine and wine-devel sooner...

[chrisk@…]

I am glad to see you have internal confirmation of the patch.

Thank you for following this through. All the work you and the rest of the MacPorts group have put into this project is appreciated.

[ryandesign (Ryan Carsten Schmidt)]

wine-devel was updated to 1.5.0 in r90890, and then the DYLD_FALLBACK_LIBRARY_PATH change was made in r90891, without increasing the port's revision. Therefore any users building 1.5.0 from source will receive the fix with this version, but any users installing from our pre-built binaries will not receive it until the next version.