[SOLVED] Failure when trying to rebuild ufraw

kgha · 01-05-2020, 04:44 AM

Occasionally I edit raw pics and have used ufraw for this. After upgrading lensfun to Eric's 0.3.95 version, ufraw stopped working (no liblensfun.so.1). I tried to rebuild ufraw but make ended with

Code:

dcraw_api.cc: In function ‘void dcraw_finalize_raw(dcraw_data*, dcraw_data*, int*)’:
dcraw_api.cc:692:13: error: ‘pixels’ not specified in enclosing ‘parallel’
  692 |             for (int i = 0; i < pixels; i++) {
      |             ^~~
dcraw_api.cc:689:21: error: enclosing ‘parallel’
  689 |             #pragma omp parallel for schedule(static) default(none) \
      |                     ^~~
dcraw_api.cc:695:77: error: ‘black’ not specified in enclosing ‘parallel’
  695 |                gint32 p = (gint64)(get_pixel(h, dark, i, cc, pixels) - black) *
      |                                                                        ^~~~~

dcraw_api.cc:689:21: error: enclosing ‘parallel’
  689 |             #pragma omp parallel for schedule(static) default(none) \
      |                     ^~~
dcraw_api.cc:705:13: error: ‘pixels’ not specified in enclosing ‘parallel’
  705 |             for (int i = 0; i < pixels; i++) {
      |             ^~~
dcraw_api.cc:702:21: error: enclosing ‘parallel’
  702 |             #pragma omp parallel for schedule(static) default(none) \
      |                     ^~~
In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9,
                 from /usr/include/glib-2.0/glib/gtypes.h:32,
                 from /usr/include/glib-2.0/glib/galloca.h:32,
                 from /usr/include/glib-2.0/glib.h:30,
                 from uf_glib.h:20,
                 from dcraw_api.cc:27:
dcraw_api.cc:709:82: error: ‘black’ not specified in enclosing ‘parallel’
  709 |                                         ((gint64)h->raw.image[i][cc] - black) *
      |                                                                        ^~~~~

/usr/include/glib-2.0/glib/gmacros.h:805:23: note: in definition of macro ‘MIN’
  805 | #define MIN(a, b)  (((a) < (b)) ? (a) : (b))
      |                       ^
dcraw_api.cc:708:47: note: in expansion of macro ‘MAX’
  708 |                     h->raw.image[i][cc] = MIN(MAX(
      |                                               ^~~
dcraw_api.cc:702:21: error: enclosing ‘parallel’
  702 |             #pragma omp parallel for schedule(static) default(none) \
      |                     ^~~
make[2]: *** [Makefile:886: dcraw_api.o] Error 1
make[2]: Leaving directory '/tmp/SBo/ufraw-0.22'
make[1]: *** [Makefile:1026: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/ufraw-0.22'
make: *** [Makefile:581: all] Error 2

Not sure how to interpret this. I rebuilt dcraw, but no change.

Managed to build rawtherapee-5.7 using the SBo buildscript, so I'm still able to dabble with raw files. Maybe I should just accept that dcraw and ufraw no longer works on -current?

kgha · 01-05-2020, 08:07 AM

After some googling I found three different patches that solved the build problems:
https://bugs.gentoo.org/685138
https://sourceforge.net/p/ufraw/bugs/425/

EDIT: Spoke too soon... package builds ok, starts ok, but when trying to open a raw file it segfaults...

kgha · 01-06-2020, 04:02 AM

Well, this is a first: don't think I ever have posted about a problem without getting good advice or elucidating information. My premature marking SOLVED may of course have contributed to this.
Well, in a way it is solved - rawtherapee works fine. I also tried darktable-3.0.0 which builds and runs fine, but I found the GUI a bit unfriendly. The sweet and simple GUI is the only thing I miss, having to ditch ufraw.
Found the nufraw fork of ufraw, and with a couple of patches I managed to build that one too, but once again it segfaulted (with no additional info) when trying to open a raw file.

TracyTiger · 01-06-2020, 09:26 AM

Quote:

Originally Posted by kgha

Well, this is a first: don't think I ever have posted about a problem without getting good advice or elucidating information.

Look at the lack of response as an opportunity. You continued to put out effort and solved more of the problems. You may expand your discovery of Internet resources such as looking for assistance on the Slackware chat channel. It's an opportunity to expand your use of resources.

I've found that when I'm not "handed" the answer to a technical problem that I can usually figure it out or get the answer from other Internet sources, usually it's a combination of both. I then realize that I was just being lazy by asking for help before I had fully explored the problem on my own (not calling you lazy).

When we are "ignored" in a forum we learn that next time we need to pick a problem/question that is more interesting to other forum members.

Note that I know nothing about "ufraw".

kgha · 01-06-2020, 11:01 AM

Cheers, TracyTiger, good points.
I don't feel ignored, nor disappointed - only slightly surprised. And yes, I have learnt something from my searches.
It was probably a mistake upgrading lensfun to 0.3.95 from https://slackware.nl/alien-kde/curre...t/x86_64/deps/ since I don't have his Plasma5 installed, even if I have some stuff from his kde /deps/ section installed. I can see that every other distro that have ufraw in their repos include lensfun-0.3.2. It might be that someone will solve the issue when the next lensfun version takes dominance.
I could of course have created a dirty symlink from liblensfun.so.2 to so.1, but that's an emergency solution and I ususally avoid it in order to prevent new problems in the future.
So I've reverted to theprevious lensfun version, reinstalled my old ufraw package, and also rebuilt rawtherapee - everything's fine now.