Maybe I'm confused, but I think the problem is that configure ignores the test result under linux.<br><br>My config.log for otp_src_R13B says:<br><br>configure:19638: checking if clock_gettime can be used to get process CPU time<br>
configure:19682: gcc -o conftest -g -O2 -I/usr/local/src/otp_src_R13B/erts/x86_64-unknown-linux-gnu -D_GNU_SOURCE conftest.c -lrt >&5<br>configure:19686: $? = 0<br>configure:19692: ./conftest<br>configure:19696: $? = 0<br>
configure:19715: result: not stable, disabled<br><br>The compile of the test (line 19682) succeeded (line 19686), the test (line 19692) succeeded (line 19696), but the result of the test is ignored because the ac_local.m4 code mentioned at the start of the thread. That code ignores the result of the test, which is recorded in $erl_clock_gettime, when running linux.<br>
<br> case $host_os in<br> linux*)<br> AC_MSG_RESULT([not stable, disabled])<br> LIBRT=$xrtlib<br> ;;<br> *)<br> case $erl_clock_gettime in<br> true)<br>
AC_DEFINE(HAVE_CLOCK_GETTIME,[],<br> [define if clock_gettime() works for getting process time])<br> AC_MSG_RESULT(using clock_gettime)<br> LIBRT=-lrt<br>
;;<br> *)<br> AC_MSG_RESULT(not working)<br> LIBRT=$xrtlib<br> ;;<br> esac<br> ;;<br> esac<br><br>-- rec --<br>
<br><br><div class="gmail_quote">On Thu, May 14, 2009 at 2:47 AM, mats cronqvist <span dir="ltr"><<a href="mailto:masse@kreditor.se">masse@kreditor.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Joe Williams <<a href="mailto:joe@joetify.com">joe@joetify.com</a>> writes:<br>
<br>
</div><div class="im">> According to the man pages CLOCK_REALTIME, CLOCK_MONOTONIC,<br>
> CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID are supported on<br>
> "sufficiently recent versions of glibc and the Linux kernel". I am<br>
> running the latest Ubuntu which includes 2.6.28 so I would assume that<br>
> this is sufficient.<br>
<br>
</div> like I said earlier, the latest stable Debian does not install the<br>
686-enabled libc automatically. Quite probably true about Ubuntu too.<br>
<br>
Anyways, here's the test(found by greping in erts/configure).<br>
<br>
#include <stdlib.h><br>
#include <unistd.h><br>
#include <string.h><br>
#include <stdio.h><br>
#include <time.h><br>
int main() {<br>
long long start, stop;<br>
int i;<br>
struct timespec tp;<br>
<br>
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp) < 0)<br>
exit(1);<br>
start = ((long long)tp.tv_sec * 1000000000LL) + (long<br>
long)tp.tv_ns$<br>
for (i = 0; i < 100; i++)<br>
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp);<br>
stop = ((long long)tp.tv_sec * 1000000000LL) + (long<br>
long)tp.tv_nse$<br>
if (start == 0)<br>
exit(4);<br>
if (start == stop)<br>
exit(5);<br>
exit(0); return 0;<br>
<div><div></div><div class="h5"> }<br>
<br>
><br>
> mats cronqvist wrote:<br>
>> Joe Williams <<a href="mailto:joe@joetify.com">joe@joetify.com</a>> writes:<br>
>><br>
>><br>
>>> I am seeing issues with this as well. I have some C++ code that uses<br>
>>> clock_gettime and it compiles and seems to work properly. But when I<br>
>>> configure Erlang it complains of it being unstable.<br>
>>><br>
>><br>
>> IIRC, it's not the existence of clock_gettime that is the problem,<br>
>> but which clk_ids it supports. Perhaps CLOCK_PROCESS_CPUTIME_ID.<br>
>><br>
>> mats<br>
>><br>
>><br>
>>> mats cronqvist wrote:<br>
>>><br>
>>>> Adam Kocoloski <<a href="mailto:adam.kocoloski@gmail.com">adam.kocoloski@gmail.com</a>> writes:<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> Hi, it seems to me that cpu_timestamp tracing is automatically<br>
>>>>> disabled on Linux. configure spits out<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>> checking if clock_gettime can be used to get process CPU<br>
>>>>>> time... not stable, disabled<br>
>>>>>><br>
>>>>>><br>
>>>>> and in aclocal.m4 I see<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>> case $host_os in<br>
>>>>>> linux*)<br>
>>>>>> AC_MSG_RESULT([not stable, disabled])<br>
>>>>>> LIBRT=$xrtlib<br>
>>>>>> ;;<br>
>>>>>> *)<br>
>>>>>><br>
>>>>>><br>
>>>>> I'm wondering what the rationale was behind that, and in particular<br>
>>>>> whether newer kernels might have fixed the problem. Does anyone<br>
>>>>> around here know a little more of the backstory? Best,<br>
>>>>><br>
>>>>><br>
>>>> I'm not really familiar with this, so the following is at best partly<br>
>>>> right.<br>
>>>><br>
>>>> configure checks for a syscall;<br>
>>>> <a href="http://www.linuxhowtos.org/manpages/2/clock_gettime.htm" target="_blank">http://www.linuxhowtos.org/manpages/2/clock_gettime.htm</a><br>
>>>><br>
>>>> On linuxen, this needs support from hardware, the kernel and libc.<br>
>>>><br>
>>>> E.g. on debian, with a 2.6 kernel, on i686 HW, you need to install<br>
>>>> libc6-i686. That will give you a variant of clock_gettime that is<br>
>>>> deemed "stable" by configure.<br>
>>>><br>
>>>> mats<br>
>>>> _______________________________________________<br>
>>>> erlang-questions mailing list<br>
>>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>>> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
>>>><br>
>>>><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>