On Mon, Apr 02 2018, Rafael Sadowski <raf...@sizeofvoid.org> wrote: > Could it be tested in a bulk build please? > > Best regards, Rafael Sadowski > > On Thu Mar 15, 2018 at 05:51:37PM +0100, Rafael Sadowski wrote: >> Update exiv2 to the latest stable version. Only tested with upcoming >> digikam 5.8.0. 14971 jpeg pictures don't cause any problems. >> >> I don't expect any problems but to be on the safe side could someone >> push it into an the next bulk? >> >> ok? Comments?
Looks good to me, a bulk could be a good idea indeed. One nit though, [...] >> Index: patches/patch-src_actions_cpp >> =================================================================== >> RCS file: patches/patch-src_actions_cpp >> diff -N patches/patch-src_actions_cpp >> --- /dev/null 1 Jan 1970 00:00:00 -0000 >> +++ patches/patch-src_actions_cpp 15 Mar 2018 09:28:45 -0000 >> @@ -0,0 +1,14 @@ >> +$OpenBSD$ >> + >> +Index: src/actions.cpp >> +--- src/actions.cpp.orig >> ++++ src/actions.cpp >> +@@ -2049,7 +2049,7 @@ namespace { >> + /* This is the critical section object (statically allocated). */ >> + static pthread_mutex_t cs = PTHREAD_RECURSIVE_MUTEX_INITIALIZER; >> + #else >> +- static pthread_mutex_t cs = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; >> ++ static pthread_mutex_t cs = PTHREAD_MUTEX_INITIALIZER; By default pthread mutexes aren't recursive, this would be a problem if exiv2 actually wants recursive mutexes. With no static initializer for this type of mutex, I'll admit that it's a bit cumbersome to use. Looking more closely, the code in temporaryPath() looks like a hacked up, unsafe mkstemp(3). I'm not sure how this should be handled. >> + #endif >> + #endif >> + -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE