Am 07.09.10 18:12, schrieb bpabbott:
> 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
Oh yes, sorry, I forgot. acx_pthread.m4 no longer exists. It's name has
been changed to ax_pthread.m4 A link where you can find a more
up-to-date version is here
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_pthread.m4
Then search for the line "*-darwin*)" and find the new flag "-pthread"
in there ;-)
I also think that John's link is wrong, not the
sf.net website keeps the
latest m4 macro sources but savannah.gnu.org. This should be checked
Regards
Thomas
changeset-m4.patch