#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