[MacPorts] #30212: wine, wine-devel: CUPS not functioning

MacPorts noreply at macports.org
Tue Mar 13 14:52:08 PDT 2012


#30212: wine, wine-devel: CUPS not functioning
---------------------------------+------------------------------------------
 Reporter:  j.s.steer@…          |       Owner:  ryandesign@…           
     Type:  defect               |      Status:  new                    
 Priority:  Normal               |   Milestone:                         
Component:  ports                |     Version:  1.9.2                  
 Keywords:  haspatch             |        Port:  wine, wine-devel       
---------------------------------+------------------------------------------

Comment(by ryandesign@…):

 Replying to [comment:7 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:
 [[br]]
 > [[br]]
 >
 https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html#//apple_ref/c/func/dlopen
 [[br]]
 > [[br]]
 > 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: [[br]]
 > [[br]]
 >
 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/30212#comment:8>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list