Issues with clock_gettime(CLOCK_REALTIME, &wait) pre macOS 10.13

[Ken Cunningham]

Yep, that is exactly what I was thinking as well.

I was pondering a specific include folder like

${prefix}/include/snowleopardfixes

for want of a better title for it, where these could be placed. Then we could just add that folder to the beginning of the system header search queue. (It would in fact be automatic and require no extra include folder spec at all if we used /usr/local/include, but then we lose some control that way. That is exactly why homebrew is both popular and harder to control.)

Maybe we could do all the missing function replacements that way, and not even need a linked in dylib. That would let us control visibility with system blocks and help avoid name collisions when linking.


Ken




On 2018-10-23, at 2:47 PM, Christopher Jones wrote:

> Hi,
> 
>> I have been pondering a good way to make it add the header definition properly ( ? use specific headers such as string.h injected ahead of the system search directory and "include_next", perhaps?) and also possibly to make each definition selectable, or at least OS-version groups blocked off with guards.
> 
> I’ve been experimenting in the direction of the above, and I think there is some milage to this approach.
> 
> I’ve attached a couple files to this mail.
> 
> time.cpp - A basic test application
> 
> time.h - A wrapping header that uses include_next to wrap time.h adding an implementation of clock_gettime for OSX10.11 and older.
> 
> I *think* I have made it reasonably complete, in that if I compare what I get on macOS10.14 (so using the system implementation) to that on OSX10.10 I see
> 
>> ./mac1014.exe 
> CLOCK_REALTIME  1540330516865744000
> CLOCK_REALTIME  1540330516865769000
> CLOCK_REALTIME  1540330516865773000
> CLOCK_REALTIME  1540330516865776000
> CLOCK_REALTIME  1540330516865779000
> CLOCK_REALTIME  1540330516865782000
> CLOCK_REALTIME  1540330516865785000
> CLOCK_REALTIME  1540330516865789000
> CLOCK_REALTIME  1540330516865792000
> CLOCK_MONOTONIC 692301875594000
> CLOCK_MONOTONIC 692301875598000
> CLOCK_MONOTONIC 692301875601000
> CLOCK_MONOTONIC 692301875606000
> CLOCK_MONOTONIC 692301875609000
> CLOCK_MONOTONIC 692301875612000
> CLOCK_MONOTONIC 692301875615000
> CLOCK_MONOTONIC 692301875619000
> CLOCK_MONOTONIC 692301875622000
> 
>> ./mac1010.exe 
> CLOCK_REALTIME  1540330771661752000
> CLOCK_REALTIME  1540330771662759000
> CLOCK_REALTIME  1540330771662770000
> CLOCK_REALTIME  1540330771662776000
> CLOCK_REALTIME  1540330771662783000
> CLOCK_REALTIME  1540330771662789000
> CLOCK_REALTIME  1540330771662795000
> CLOCK_REALTIME  1540330771662801000
> CLOCK_REALTIME  1540330771662807000
> CLOCK_MONOTONIC 3731777139000
> CLOCK_MONOTONIC 3731777145000
> CLOCK_MONOTONIC 3731777151000
> CLOCK_MONOTONIC 3731777157000
> CLOCK_MONOTONIC 3731777162000
> CLOCK_MONOTONIC 3731777168000
> CLOCK_MONOTONIC 3731777174000
> CLOCK_MONOTONIC 3731777180000
> CLOCK_MONOTONIC 3731777186000
> 
> 
> The REALTIME clock is supposed to give values roughly the same in both cases, as these are supposed to be absolute wall clock times since the UNIX epoch. 
> 
> MONOTONIC is allowed to have different values, as its w.r.t. different points for each machine. 
> 
> Compilation is just a case of
> 
>> ls *.h *.cpp
> time.cpp	time.h
>> clang++ -I. time.cpp -o mac1010.exe
>> 
> 
> If you remove the -I. then on 10.10 it correctly fails.
> 
>> clang++ time.cpp -o mac1010.exe
> time.cpp:26:45: error: use of undeclared identifier 'CLOCK_REALTIME'
>    std::cout << "CLOCK_REALTIME  " << time(CLOCK_REALTIME) << std::endl;
>                                            ^
> time.cpp:31:45: error: use of undeclared identifier 'CLOCK_MONOTONIC'
>    std::cout << "CLOCK_MONOTONIC " << time(CLOCK_MONOTONIC) << std::endl;
>                                            ^
> 2 errors generated.
> 
> so the include_next seems to work OK.
> 
> I have tried with a number of gcc and clang compilers, and it seems fine with them all.
> 
> So I *think* we could consider including the wrapper time.h in the snowleopardfixes port, and then as long as builds use -I${prefix}/include then should pick it up without having to patch the code in any way, which is my aim here...
> 
> Chris
> 
> <time.h><time.cpp>