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?