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

[Chris Jones]

FWIW I have tested the basic idea back as far as OSX 10.6, and it works 
fine there with the system gcc 4.2.1

MacVM106 /Volumes/VMware Shared Folders/Projects/Test > g++ -I. time.cpp 
-o mac106.exe
MacVM106 /Volumes/VMware Shared Folders/Projects/Test > ./mac106.exe
0 CLOCK_REALTIME  1540375323758611000
0 CLOCK_REALTIME  1540375323758750000
0 CLOCK_REALTIME  1540375323758772000
0 CLOCK_REALTIME  1540375323758791000
0 CLOCK_REALTIME  1540375323758808000
0 CLOCK_REALTIME  1540375323758826000
0 CLOCK_REALTIME  1540375323758844000
0 CLOCK_REALTIME  1540375323758861000
0 CLOCK_REALTIME  1540375323758879000
0 CLOCK_MONOTONIC 1329176161010324
0 CLOCK_MONOTONIC 1329176161027572
0 CLOCK_MONOTONIC 1329176161044815
0 CLOCK_MONOTONIC 1329176161061733
0 CLOCK_MONOTONIC 1329176161078708
0 CLOCK_MONOTONIC 1329176161095875
0 CLOCK_MONOTONIC 1329176161112940
0 CLOCK_MONOTONIC 1329176161130299
0 CLOCK_MONOTONIC 1329176161147827
MacVM106 /Volumes/VMware Shared Folders/Projects/Test > g++ --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


so the `include_next` directive is fine that far back...

OSX 10.6 is the oldest I can test, but it would be interesting to see if 
it also works on 10.5 (PPC)....

Chris

On 24/10/18 10:17, Chris Jones wrote:
> Hi,
> 
>> I am interested in working on this, as I think it would ease some 
>> issues in a few ports I have stumbled over recently. Let me try and 
>> put something to test together.
> 
> I have started to put something together for this. I have a little new 
> project in github
> 
> https://github.com/cjones051073/macports-legacy-support
> 
> and then a new port that installs the headers from this repo.
> 
> <https://github.com/cjones051073/macports-ports/commit/f1b25a6dea9e895ae6d1d14411099b6cd43153ea> 
> 
> 
> I have run a first quick test, building xrootd, and the signs are 
> positive in that as I hoped it fixed the issues I was seeing with xrootd 
> completely transparently, without having to patch the port or code in 
> anyway. Obviously much more testing is needed though, so please if you 
> are interested (Ken?) checkout my ports branch above and give it a try 
> yourself.
> 
> Also, if you have any suggestions for additional header fixes to add, 
> let me know (or make a PR against the project...). ( Longer term, if 
> this idea has legs, I think the git repo should move from my account to 
> the main MacPorts area, but this can wait. )
> 
> Chris