ports/148804: graphics/gdal - Thread support broken

Tom Uffner tom at uffner.com
Wed Jul 21 01:20:04 UTC 2010


>Number:         148804
>Category:       ports
>Synopsis:       graphics/gdal - Thread support broken
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 21 01:20:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Tom Uffner
>Release:        9-current
>Organization:
>Environment:
FreeBSD xiombarg.uffner.com 9.0-CURRENT FreeBSD 9.0-CURRENT #157: Tue Jun  8 03:26:06 EDT 2010     root at xiombarg.uffner.com:/usr/obj/usr/src/sys/XIOMBARG  i386
>Description:
The port makefile has a config knob for "Thread support". When this is enabled, the port fails to build:

cpl_multiproc.cpp:735:2: error: #error "Recursive mutexes apparently unsupported, configure --without-threads"
gmake[1]: *** [cpl_multiproc.o] Error 1
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.6.0/port'
gmake: *** [port-target] Error 2
*** Error code 1

the problem appears to be a Linuxism in cpl_multiproc.cpp where it checks if recursive mutexes are supported. They are (and have been since 1998) but the test fails due to non-portable coding. In BSD derived PThreads implementations, since 1996, pthread mutex types are defined as an enum, not a C pre-processor macro (currently at line 128 of /usr/include/pthread.h). The comment immediatly above implies, though I haven't checked, that this syntax was standardized in SUSv2.

deleting or altering the "#if defined(PTHREAD_MUTEX_RECURSIVE)" test so that the #error is not triggered allows the package to build with thread support.
>How-To-Repeat:
% cd /usr/ports/graphics/gdal
% make config

check the "Thread support" box

% make all

build will fail as shown above
>Fix:
This really should be fixed upstream by the GDAL project since they claim to support BSD, but adding the attached patch to the FreeBSD port is a workaround.

Patch attached with submission follows:

--- port/cpl_multiproc.cpp.orig	2010-07-20 21:06:43.000000000 -0400
+++ port/cpl_multiproc.cpp	2010-07-20 21:07:47.000000000 -0400
@@ -721,19 +721,12 @@
 
     hMutex = (pthread_mutex_t *) malloc(sizeof(pthread_mutex_t));
 
-#if defined(PTHREAD_MUTEX_RECURSIVE)
     {
         pthread_mutexattr_t  attr;
         pthread_mutexattr_init( &attr );
         pthread_mutexattr_settype( &attr, PTHREAD_MUTEX_RECURSIVE );
         pthread_mutex_init( hMutex, &attr );
     }
-#elif defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP)
-    pthread_mutex_t tmp_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
-    *hMutex = tmp_mutex;
-#else
-#error "Recursive mutexes apparently unsupported, configure --without-threads" 
-#endif
 
     // mutexes are implicitly acquired when created.
     CPLAcquireMutex( hMutex, 0.0 );


>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the freebsd-ports-bugs mailing list