[MacPorts] #23594: dcraw configuration fails

[MacPorts]

#23594: dcraw configuration fails
--------------------------------+-------------------------------------------
 Reporter:  dplepage@…          |       Owner:  ryandesign@…           
     Type:  defect              |      Status:  new                    
 Priority:  Normal              |   Milestone:                         
Component:  ports               |     Version:  1.8.2                  
 Keywords:                      |        Port:  dcraw                  
--------------------------------+-------------------------------------------

Comment(by dweber@…):

 Replying to [comment:4 ryandesign@…]:
 > I believe the dcraw port thinks you have the ufraw port installed, and
 is failing when trying to determine its version. If this is the problem,
 you can work around it by deactivating the ufraw port before trying to
 install the dcraw port. Do you have ufraw installed? If so, what happens
 when you run "`ufraw --version`"?


 On OSX 10.5.8, I get the following,
 {{{
 $ which ufraw
 /opt/local/bin/ufraw
 $ ufraw --version
 dyld: Library not loaded: /opt/local/lib/libjpeg.62.dylib
   Referenced from: /opt/local/bin/ufraw
   Reason: image not found
 Trace/BPT trap
 }}}
 No freakin idea how that came to be.  You would think this would be picked
 up by a build failure for ufraw or something?  What about the build
 dependency tree for libjpeg?

 Looks like we have some kind of "cyclic dependency" issue because dcraw is
 trying to test for a specific version of ufraw and it also has dependency
 on a specific version of libjpeg.  So an {{{port upgrade -uR libjpeg}}}
 might first upgrade libjpeg and then try to upgrade ufraw, which deps on
 dcraw and dcraw then checks for the version of ufraw installed by trying
 to run ufraw, but this crashes because the libjpeg is now upgraded.  Is
 that it?  Nasty little dep cycle.


 The current dcraw port file contains a pre-configure section as follows,
 {{{
 pre-configure {
     # ufraw 0.15 and earlier provided its own copy of dcraw, but 0.16 now
     # depends on the dcraw port instead. To prevent activation conflicts
     # when upgrading to ufraw 0.16, ensure an old dcraw-providing ufraw
     # is not active.
     if {[file exists ${prefix}/bin/ufraw]} {
         set ufraw_minimum_version 0.16
         set ufraw_installed_version [exec ufraw --version 2>&1 | awk
 "/^ufraw/ {print \$2}"]
         if {[rpm-vercomp ${ufraw_installed_version}
 ${ufraw_minimum_version}] < 0} {
             return -code error "Please deactivate your currently-installed
 ufraw port, then try again"
         }
     }
 }
 }}}


 So this looks interesting.  First it checks to see if ufraw is installed
 by checking if the file exists in ${prefix}/bin/ufraw - that's a good
 start.

 So it enters the {{{if}}} block, sets min version, then tries to get the
 current installed version with {{{[exec ufraw --version ...]}}}}.  This is
 the point of failure because the ufraw executable has a bad shared library
 link to libjpeg.62.dylib.

 On one of my systems, we have
 {{{
 $ ls -al /opt/local/lib/libjpeg.*
 -rwxr-xr-x 2 root admin 220K Dec 10 12:48 /opt/local/lib/libjpeg.7.dylib*
 -rw-r--r-- 2 root admin 247K Dec 10 12:48 /opt/local/lib/libjpeg.a
 lrwxr-xr-x 1 root admin   15 Dec 10 12:48 /opt/local/lib/libjpeg.dylib ->
 libjpeg.7.dylib*
 -rwxr-xr-x 2 root admin  912 Dec 10 12:48 /opt/local/lib/libjpeg.la*
 }}}

 So the failure to load libjpeg.62.dylib is obvious, it just doesn't exist
 on the system.

 Might need a try-catch in the pre-configure phase?

 It might be handy if ufraw were linked to the generic libjpeg.dylib (which
 is a symlink to the current version).  I dunno how to arrange that without
 a hack in the post-destroot (some such hacks are used in my ports for vtk-
 devel and InsightToolkit to redefine the location of the dylib links).

 Anyhow, that may not be the solution in this case.  Where does
 libjpeg.62.dylib come from?  Is this a hard dependency for dcraw or ufraw?

 Best,
 Darren

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