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: bpabbott
Subject: Re: Octave's m4/acx_pthread.m4 & OSX
Date: Tue, 07 Sep 2010 16:12:10 +0000 (GMT)

On 07 Sep, 2010,at 11:48 AM, Thomas Treichl <address@hidden> wrote:

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 106 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
 
Thanks Thomas,

Unfortuntely, I can't find a version of acx-pthread.m4 that is newer than 4 yrs old. 

http://ac-archive.cvs.sourceforge.net/viewvc/ac-archive/ac-archive-5/ac-archive/

Where are the latest files located? ... or is your patch in limbo?

Ben


reply via email to

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