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

[Chris Jones]

Hi,

> On 23 Oct 2018, at 11:26 pm, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
> 
> 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.)

I see no reason to not just place them directly in the main MacPorts include prefix, i.e. normally /opt/local/include. Placing them anywhere else requires that specific folder to be included as well, which is a complication I dont see the need for. As long as these headers are written properly, they should be completely safe and transparent to use. Either they just include the primary header in cases where it is complete, or they add the missing methods in cases where they are required, but only where they are required. 

> 
> 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.

I was thinking that as well. If the need for libraries can be avoid it makes things much simpler to handle. I actually suspect all of what you currently have in snowleopardfixes could be reimplemented in this way, and then largely avoid the need for the additional options you then have to add to all compilations in the portgroup.

Also because of the above I now think it is probably better to not add this to the existing snowleopardfixes port and instead start a new one for this. For one thing the name is misleading once it used for more systems ;) but, more seriously what I am imagining is a port that could simply be depended on as required, which just installs these wrapper headers and then which are hopefully just picked up by the builds through automatically, because they should already be including the MP prefix include dir. all the additional compilation of the portgroup should I think just go away.

Chris

> 
> 
> 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>
>