dcraw configuration fails when installed ufraw won't run

[dplepage@…]

Installing dcraw on OS 10.6.2 (on a MacBook Pro) fails with the following error message:

$ sudo port install dcraw
--->  Computing dependencies for dcraw
--->  Fetching dcraw
--->  Verifying checksum(s) for dcraw
--->  Extracting dcraw
--->  Configuring dcraw
Error: Target org.macports.configure returned: child killed: trace trap
Error: Status 1 encountered during processing.
Before reporting a bug, first run the command again with the -d flag to get complete output.

The output of $sudo port -d install dcraw is attached.

[dplepage@…]

Debug output

[dplepage@…]

Cc Me!

[jmroot (Joshua Root)]

Please remember to cc the maintainer, and note that you do not need to be in cc when you are the reporter.

[dplepage@…]

Replying to jmr@…:

Please remember to cc the maintainer, and note that you do not need to be in cc when you are the reporter.

Oops, sorry. I also should have mentioned that I'm trying to install dcraw 8.99-20091225135800.

[ryandesign (Ryan Carsten Schmidt)]

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"?

[dplepage@…]

This problem actually first arose when I tried to upgrade ufraw from 0.15_0 to 0.16_0; it tried to install dcraw and produced the error above. When I run ufraw, I get a library error:

$ 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

I upgraded libjpeg recently from 6.2 to 7.0, which I assume is the source of this problem. I'll try deactivating ufraw and then installing dcraw right now.

[dplepage@…]

Sure enough, that worked - after deactivating ufraw, dcraw installed perfectly, and I could then upgrade ufraw without issues. Thanks for your help!

[dweber@…]

Replying to 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

[dweber@…]

A package for try-catch in tcl,

​http://www.wjduquette.com/tcl/trycatch.html

[ryandesign (Ryan Carsten Schmidt)]

To resolve this, I am working on a way for dcraw to detect the version of ufraw without calling the ufraw executable, since a) it might be so old that it's linked with the old libjpeg.62.dylib (which was provided by the jpeg @6b port) and might therefore not run, b) it opens X11 which I don't want to occur while installing a port, and c) the ufraw version detection doesn't actually appear to be working at all anyway.

[ryandesign (Ryan Carsten Schmidt)]

This should be fixed in r63741.