[MacPorts] #20531: gdal build fails if pthsem is installed

Uwe Arzt mail at uwe-arzt.de
Sat Aug 8 03:00:06 PDT 2009


Hi all,

correct ;). whenever possible the system libs should be used.

Back to the bug:

On my System (Intel Leopard 10.5.8) gdal builds fine when pthsem and/ 
or pth is installed. Could there be an dependency with other packages?  
What else can/should i try to reproduce the bug (as maintainer of  
pthsem)?

And both libs have different filesets:

ganymed:~ uwe$ sudo port contents pthsem
Port pthsem contains:
   /opt/local/bin/pthsem-config
   /opt/local/include/pthsem.h
   /opt/local/lib/libpthsem.20.0.27.dylib
   /opt/local/lib/libpthsem.20.dylib
   /opt/local/lib/libpthsem.a
   /opt/local/lib/libpthsem.dylib
   /opt/local/lib/libpthsem.la
   /opt/local/man/man1/pthsem-config.1
   /opt/local/man/man3/pthsem.3
   /opt/local/share/aclocal/pthsem.m4
ganymed:~ uwe$ sudo port contents pth
Port pth contains:
   /opt/local/bin/pth-config
   /opt/local/include/pth.h
   /opt/local/lib/libpth.20.0.27.dylib
   /opt/local/lib/libpth.20.dylib
   /opt/local/lib/libpth.a
   /opt/local/lib/libpth.dylib
   /opt/local/lib/libpth.la
   /opt/local/share/aclocal/pth.m4
   /opt/local/share/doc/pth/ANNOUNCE
   /opt/local/share/doc/pth/AUTHORS
   /opt/local/share/doc/pth/ChangeLog
   /opt/local/share/doc/pth/COPYING
   /opt/local/share/doc/pth/HACKING
   /opt/local/share/doc/pth/HISTORY
   /opt/local/share/doc/pth/INSTALL
   /opt/local/share/doc/pth/NEWS
   /opt/local/share/doc/pth/PORTING
   /opt/local/share/doc/pth/README
   /opt/local/share/doc/pth/SUPPORT
   /opt/local/share/doc/pth/TESTS
   /opt/local/share/doc/pth/THANKS
   /opt/local/share/doc/pth/USERS
   /opt/local/share/man/man1/pth-config.1.gz
   /opt/local/share/man/man3/pth.3.gz

Any help apreciated...

BTW: pthsem doesn't even build on 10.4 (There is a bug in Trac for  
that). But have to get a grip on a 10.4 machine, before i can  
reproduce this issue.

:q! Uwe


Am 08.08.2009 um 07:04 schrieb Rainer Müller:

> On 2009-08-08 02:18 , Sean Fulton wrote:
>> One solution from the gdal perspective is to have a variant for
>> pthreads and requite pth.  In most cases I would accept that a  
>> variant
>> is appropriate but here I'm not so sure.  pthreads is the standard
>> library for threads, I think, in the vast majority of OSS and pthsem
>> shouldn't be overriding it.  On the other hand, the gdal port is
>> probably picking up the native OS X pthreads without being asked to.
>
> pthreads is an essential interface on modern systems. On Mac OS X it  
> is
> directly implemented in libSystem against which most binaries have to
> link anyway for the usual BSD library functions.
>
> If I read the description for pth correctly, it is purely  
> implemented in
> user-mode and does not make use of kernel scheduling. Without using  
> the
> kernel scheduler such a library cannot take advantage of multiple
> CPUs/cores. Therefore I would strongly recommend the Mac OS X provided
> pthreads interface.
>
> Rainer
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

:q! Uwe

-- 
mail at uwe-arzt.de
www.uwe-arzt.de



More information about the macports-dev mailing list