octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave's m4/acx_pthread.m4 & OSX


From: Thomas Treichl
Subject: Re: Octave's m4/acx_pthread.m4 & OSX
Date: Tue, 07 Sep 2010 17:48:13 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Am 07.09.10 16:01, schrieb John W. Eaton:
On  7-Sep-2010, Ben Abbott wrote:

| On Sep 7, 2010, at 7:21 AM, Jarno Rajahalme wrote:
|
|>  On Sep 7, 2010, at 3:30 , ext Ben Abbott wrote:
|>
|>>  I understand the patch is needed for MacOS 10.6, but what of the early 
versions?
|>>
|>>  Thomas / anyone else, can you comment. Is the patch needed for ealier 
versions of MacOS?
|>>
|>>  Also does anyone understand how the ACX_PTHREAD macro can be modified to 
detect the need for the -pthread option?
|>>
|>>  For the details for why the patch is needed on MacOS 10.6, see the link 
below.
|>>
|>>       
https://www-old.cae.wisc.edu/pipermail/bug-octave/2010-January/010241.html
|>>
|>>  Ben
|>
|>  The change is 10.6 is in /usr/include/architecture/i386/math.h:
|>
|>  /*       lgamma and lgammaf are not thread-safe.  The thread-safe variants
|>  *        lgamma_r and lgammaf_r are available on OS X 10.6 and later.
|>  *
|>  *        To use the thread-safe variants, you must define the _REENTRANT 
symbol.
|>  */
|>
|>  The -pthread compiler option causes gcc to define the required _REENTRANT 
symbol. I have not tested whether lgamma_r and lgammaf_r depend on any specific 
threading libraries, but if they do the -pthread option should cause them to be 
linked in.
|>
|>  OSX before 10.6 does not have the _r variants, but it seems to me that 
having the -pthread option set should not break anything. Haven't tested it, 
though.
|>
|>   Jarno
|
| Ok! If the decision is not to detect (by a functional test) that -pthread is 
needed, the case statement should be modified to reflect 10.6 only.
|
| The Darwin version numbers for the various MacOS versions are listed at the 
link below.
|
|       http://en.wikipedia.org/wiki/Darwin_(operating_system)
|
| Would the case statement function properly if it were written as ...
|
| case "${host_cpu}-${host_os}" in
|         *solaris*)
|
|         # On Solaris (at least, for some versions), libc contains stubbed
|         # (non-functional) versions of the pthreads routines, so link-based
|         # tests will erroneously succeed.  (We need to link with 
-pthreads/-mt/
|         # -lpthread.)  (The stubs are missing pthread_cleanup_push, or rather
|         # a function called by this macro, so we could check for that, but
|         # who knows whether they'll stub that too in a future libc.)  So,
|         # we'll just look for -pthreads and -lpthread first:
|
|         acx_pthread_flags="-pthreads pthread -mt -pthread $acx_pthread_flags"
|         ;;
|
|       *-darwin10*)
|
|         # On Darwin 10.x (MacOS 10.x), lgamma and lgammaf are not thread-safe.
|         # The thread-safe variants lgamma_r and lgammaf_r are available on
|         # OS X 10.6 and later. To use the thread-safe variants, you must 
define the
|         # _REENTRANT symbol. The -pthread compiler option causes gcc to define
|         # the required _REENTRANT symbol.
|
|       acx_pthread_flags="-pthread"
|       ;;
| esac
|
| I'm not familiar with the tests done in these macros, but looking at 
lo-specfun.cc:rc_lgamma, It doesn't look to me like creating a test for this is 
straight forward (if I understand correctly a test would depend upon 
HAVE_LGAMMA_R being defined true).
|
| Thoughts anyone? Is there an approach that can detect this problem, or should 
the case statement be modified as done above?

Octave's acx_pthread.m4 file comes from the autoconf macro archive:

   http://ac-archive.sourceforge.net/ac-archive/acx_pthread.html

Any changes to that file should be made upstream so everyone who uses
the file benefits.  I'd prefer to avoid tracking our own modifications
to files from the autoconf macro archive, so please get the changes
made upstream first.  Then once changes are in the autoconf macro
archive, we can copy the changes to the Octave sources.

Thanks,

jwe

Some time ago I have reported this to

  http://ac-archive.sourceforge.net/ac-archive/acx_pthread.html

These changes already are in the original file from ac-archive. I also reported to the maintainers list that these modifications have been made at ac-archives. So the way to go is to get the latest files ;-)

Regards

  Thomas


reply via email to

[Prev in Thread] Current Thread [Next in Thread]