Sorry, my use of Mantis formatting codes did not work as I intended and I don't see a way to edit my report to correct the problem.

I don't have access to OSX 10.11 (or any OSX, beside 10.15 through Azure Pipelines), but I believe the branch issue2007-osx1011-timing on GitHub should fix the problem:
https://github.com/derickr/xdebug/tree/issue2007-osx1011-timing

Can you check that branch yourself to verify this perhaps? And also run the tests (https://github.com/xdebug/xdebug#testing)?

Can you check that branch yourself to verify this perhaps?

This does build on OS X 10.11, thanks. Configure output says:

checking for gettimeofday... yes
checking for clock_gettime... no
checking for clock_gettime_nsec_np... no

and presumably the functionality based on clock_gettime or clock_gettime_nsec_np is not included. How important is this functionality? In MacPorts we have a library of compatibility functions for older systems and we do have an implementation of clock_gettime but don't have clock_gettime_nsec_np yet. If I include that library on 10.11, then configure output says:

checking for gettimeofday... yes
checking for clock_gettime... yes
checking for clock_gettime_nsec_np... no

and the build still succeeds and presumably now uses clock_gettime. Is xdebug better when it can use clock_gettime such that it would be preferable for MacPorts to include this compatibility library?

And also run the tests (https://github.com/xdebug/xdebug#testing)?

I have not run the tests before so I cannot be sure that I'm doing it correctly. On 10.11 with this change I get 47 test failures but on macOS 10.13 without this change (but with more PHP extensions installed) I get 90 test failures (including the same 47 that failed on 10.11) so I do not believe this change causes any new problems.

I had missed that OSX 10.11 does support clock_gettime, as although it is checked for, it is not used for OSX. It instead falls back to gettimeofday. For most purposes, this is totally usable. The ultra high precision of clock_gettime(_nsec_np) is hardly ever goign to be noticable, so I wouldn't worry about including your compatibility library.

Running just the Xdebug tests with "php run-xdebug-tests.php" (and xdebug.so enabled in your standard php.ini (php --ini) with "zend_extension=xdebug.so") should not see any test failures though. So I'm kind of interesting to see the output of that command.

To clarify: macOS 10.12 introduced support for clock_gettime, clock_gettime_nsec_np, and whatever other related defines and functionality exist; OS X 10.11 and earlier do not have them.

MacPorts has a compatibility library that we can insert that provides an implementation of clock_gettime for 10.11 and older but we have not yet written a compatibility implementation of clock_gettime_nsec_np.

Unless I misunderstand, after your changes, and with the MacPorts compatibility library providing clock_gettime on 10.11, your code will follow the "Linux/Unix with clock_gettime" code path and define a xdebug_get_nanotime_rel function that uses clock_gettime. In xdebug_nanotime_init, because defined(CLOCK_MONOTONIC) (it is defined in the modified system headers provided by the MacPorts compatibility library), context.use_rel_time will be set to 1. And in xdebug_nanotime_init and xdebug_get_nanotime, again because defined(CLOCK_MONOTONIC), xdebug_get_nanotime_rel will be called. If we do not include the MacPorts compatibility library, then there will be no clock_gettime function, no CLOCK_MONOTONIC define, and a xdebug_get_nanotime_rel function will not be defined or called, and then you fall back to using xdebug_get_nanotime_abs which calls gettimeofday.

I've attached the test results from 10.11.

I have now merged the PR/branch into master. I did make a few tweaks to use more of HAVE_CLOCK_GETTIME_* to be more consistent, and hopefully more portable. It compiles and works on macOS 10.15 as per CI, but if you could give it one more go, that'd be appreciated.

I also had a look at your test failures, and it seems to me that the tests were not run against the newly built .so file, as there are test failures, and changes in output, that are present in the new code in the master branch, but not in older versions. I am going to guess you didn't run a "make install" before running the tests. That's no big deal, but it would probably explain why you have so many failures.

I had the same issue when trying to install the latest xdebug version (3.0.X) on my OS X 10.11 Mac with Homebrew.

I now tested the 3.1 beta release (3.1.0beta2).
I get a different error with the new changes:
<pre>
/private/tmp/pear/temp/xdebug/src/lib/timing.c:120:6: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration]
if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
^
/private/tmp/pear/temp/xdebug/src/lib/timing.c:120:20: error: use of undeclared identifier 'CLOCK_MONOTONIC'
if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
^
1 warning and 1 error generated.
</pre>

@MergeMarc:

1. Did you use fresh sources? If not, please do a new GitHub checkout, and try in there
2. What is the output of "./configure" and config.log? (Please attach as file)
3. Can you also try the following patch, if 1 doesn't work.

<pre>
diff --git src/lib/timing.c src/lib/timing.c
index 269072b7..3194e771 100644
--- src/lib/timing.c
+++ src/lib/timing.c
@@ -22,6 +22,12 @@

include <sys/time.h>

#endif

+#if HAVE_CLOCK_GETTIME
+# if defined(__APPLE)
+# include <time.h>
+# endif
+#endif
+
#if HAVE_CLOCK_GETTIME_NSEC_NP

if defined(__APPLE)

include <mach/mach_time.h>

</pre>

FWIW, if any of you are interested in this being fixed, I do need to some assistance, for example by answering my questions. Xdebug 3.1 is going to be released next week, and it would be a shame if this issue wasn't addressed.

@derick
Sorry for the delayed response. I’m not that proficient with make yet as pecl usually does that all for me.

I cloned the repo so I could try building current master. The build failed in the same way. I attached the output of configure as well as the configure.log.

I then applied your diff and ran phpize, configure and make again. Sadly, make exited with the same error as described previously (Maybe not relevant but make also seemed to error out much faster than before applying the diff). I also attached the output of configure and configure.log of that try (see files with -withdiff suffix).

Error output with the diff applied (just the line numbers changed):
<pre>
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:126:6: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration]
if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
^
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:126:20: error: use of undeclared identifier 'CLOCK_MONOTONIC'
if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
^
1 warning and 1 error generated.
</pre>

Your config.log includes:

<pre>
configure:4607: checking for clock_gettime
configure:4607: cc -o conftest -g -O2 -I/usr/local/Cellar/php/8.0.10/include/php -I/usr/local/Cellar/php/8.0.10/include/php/main -I/usr/local/Cellar/php/8.0.10/include/php/TSRM -I/usr/local/
Undefined symbols for architecture x86_64:
"_clock_gettime", referenced from:
_main in conftest-79309a.o
…
configure:4607: result: no
</pre>

And your configure-output file:
<pre>
checking for clock_gettime... no
checking for clock_gettime_nsec_np... no
</pre>

Which seems plausible. If this is not found, then HAVE_CLOCK_GETTIME should not be set. The code that you say ("I cloned the repo so I could try building current master.") doesn't compile has this in the "master" branch at the moment:

<pre>
115 #elif HAVE_CLOCK_GETTIME
116 static uint64_t xdebug_get_nanotime_rel(xdebug_nanotime_context nanotime_context)
117 {
118 struct timespec ts;
119
120 if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
121 return (uint64_t)ts.tv_sec NANOS_IN_SEC + (uint64_t)ts.tv_nsec;
122 }
123
124 return 0;
125 }
126 #endif
</pre>

Line 126 (where you see your error), doesn't have a clock_gettime line, and it also should never try to compile this code because HAVE_CLOCK_GETTIME is not set.

Something seems wrong on your side.

Can you show all the exact steps, from the beginning, with a cleanly checked out GIT repository in a new directory?

Thank you for looking into my reported details of the issue.

The error output of make I provided in my last comment was WITH the provided patch for src/lib/timing.c applied. The patch added 6 lines to the file hence the line with “clock_gettime” is offset by 6 lines (Line 126 instead of 120) when compared to master. I kept calling the patch “diff” in my previous comment, I’m sorry if that caused any confusion.

I will follow up with a step by step description of my process with a freshly cloned repo (and no patch) shortly.

Here are the step by step instructions of what I’m doing (also see the attachments for the full outputs):

<pre>
$ mkdir /tmp/xdebug3
$ cd /tmp/xdebug3
$ git clone git://github.com/xdebug/xdebug.git
$ cd xdebug
$ git log -1
commit b9dbb8163c8f74a7d26e2805f900c63d638683b6 (HEAD -> master, origin/master, origin/HEAD)
Merge: 9f34d187 85192199
Author: Derick Rethans <github@derickrethans.nl>
Date: Wed Sep 22 11:07:43 2021 +0100

Merge branch 'xdebug_3_1'

$ phpize
$ ./configure
$ make
</pre>

Ok, besides the different line numbers... this is still baffling as configure output says:

<pre>
checking for clock_gettime... no
checking for clock_gettime_nsec_np... no
</pre>

Which means that HAVE_CLOCK_GETTIME does not get defined, but your preprocessor still doesn't remove the bit that uses clock_gettime, which is keyed for by HAVE_CLOCK_GETTIME.

Would you mind zipping/tarring up the current state of /tmp/xdebug3, and attaching that?

I found where HAVE_CLOCK_GETTIME is defined but I cannot make much sense of it.

I managed to figure out that HAVE_CLOCK_GETTIME was, in fact, set to 1.
I used the following snipped to figure this out:
<pre>
#define STRING2(x) #x
#define STRING(x) STRING2(x)
#pragma message(STRING(HAVE_CLOCK_GETTIME))
</pre>

I then laced some relevant files with this snipped trying to figure out where HAVE_CLOCK_GETTIME was being set.
I ended up in php_xdebug.h. HAVE_CLOCK_GETTIME was set after these php headers(?) where included:
<pre>
28: #include "php.h"
</pre>

Since these don’t exist in the project I searched my php installations. I found the file that set HAVE_CLOCK_GETTIME: /usr/local/Cellar//php/8.0.10/include/php/main/php_config.h
<pre>
445 / /
446 / #undef HAVE_CLI0EXT_H /
447
448 / do we have clock_gettime? /
449 #define HAVE_CLOCK_GETTIME 1
450
451 / do we have clock_get_time? /
452 / #undef HAVE_CLOCK_GET_TIME /
453
454 / /
455 / #undef HAVE_CODBC /
</pre>

Changing that line to the following let make compile xdebug without an issue.
<pre>
449 / #undef HAVE_CLOCK_GETTIME /
</pre>

With that the problem lies somewhat out of the scope of xdebug I think. But I don’t understand why this was set in my PHP installation in the first place.
Running “pecl install xdebug-3.1.0beta2” also ran after this manual fix with no errors.

Thanks for doing that investigation. I think I might have a way to solve this without having to "hack" the PHP include files.

I've prepared the "better-clock-checks" branch, which I think should solve this problem. Could you:

1. revert the change that you've made to /usr/local/Cellar//php/8.0.10/include/php/main/php_config.h (line 449, I think)
2. check out the better-clock-checks branch
3. run: phpize && ./configure && make && make install
4. If that compiles, run: php -r 'xdebug_info();' | grep Clock
5. show the output of: grep -r XDEBUG_CLOCK config.h

Thank you for the update.
I removed my xdebug installation, reverted my changes in php_config.h and cloned the repo into a fresh directory and switched to branch "better-clock-checks".

Make built successfully with only one warning (see attachments for full outputs):
<pre>
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:154:22: warning: implicit declaration of function 'xdebug_get_nanotime_rel' is invalid in C99
[-Wimplicit-function-declaration]
context.start_rel = xdebug_get_nanotime_rel(&context);
^
1 warning generated.
</pre>
But even doe xdebug was successfully compiled, after enabling it, php was throwing the following error whenever called:
<pre>
dyld: lazy symbol binding failed: Symbol not found: _xdebug_get_nanotime_rel
Referenced from: /usr/local/lib/php/pecl/20200930/xdebug.so
Expected in: flat namespace

dyld: Symbol not found: _xdebug_get_nanotime_rel
Referenced from: /usr/local/lib/php/pecl/20200930/xdebug.so
Expected in: flat namespace

Trace/BPT trap: 5
</pre>

Output of the grep command (step 5):
<pre>
config.h:/ #undef HAVE_XDEBUG_CLOCK_GETTIME /
config.h:#define HAVE_XDEBUG_CLOCK_GETTIME_NSEC_NP 0
</pre>

I think I have just pushed a fix for this. Could you check again with the same steps? There is an extra commit on the branch, so a "git pull" should fetch that.

It'd be great of you could have a look @MergeMarc — I'd love to have this in this week's Xdebug 3.1.0 release.

Sorry for the delayed response. I just started college and it can take me a few days sometimes to test things again.

I pulled the changes. Sadly, make now outputs a bunch of errors:
<pre>
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:170:15: error: no member named 'use_rel_time' in 'struct _xdebug_nanotime_context'
if (context->use_rel_time) {

/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:171:14: warning: implicit declaration of function 'xdebug_get_nanotime_rel' is invalid in C99 [-Wimplicit-function-declaration]
                nanotime = xdebug_get_nanotime_rel(context);
                           ^
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:173:27: error: no member named 'last_rel' in 'struct _xdebug_nanotime_context'
                if (nanotime < context->last_rel + NANOTIME_MIN_STEP) {
                               ~~~~~~~  ^
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:174:13: error: no member named 'last_rel' in 'struct _xdebug_nanotime_context'
                        context->last_rel += NANOTIME_MIN_STEP;
                        ~~~~~~~  ^
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:175:24: error: no member named 'last_rel' in 'struct _xdebug_nanotime_context'
                        nanotime = context->last_rel;
                                   ~~~~~~~  ^
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:177:12: error: no member named 'last_rel' in 'struct _xdebug_nanotime_context'
                context->last_rel = nanotime;
                ~~~~~~~  ^
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.c:178:56: error: no member named 'start_rel' in 'struct _xdebug_nanotime_context'; did you mean 'start_abs'?
                nanotime = context->start_abs + (nanotime - context->start_rel);
                                                                     ^~~~~~~~~
                                                                     start_abs
/Users/USERNAME/Documents/Projekte/xdebug/src/lib/timing.h:29:11: note: 'start_abs' declared here
        uint64_t start_abs;
                 ^
1 warning and 6 errors generated.
make: *** [src/lib/timing.lo] Error 1
</pre>
New outputs and logs attached.
Thank you for still looking into this.

OK, that was my bad and I forgot to update a line. I suppose I couldn't have temporary access to a user account if the commit that I've just pushed didn't resolve this?

I pulled the fix. The compilation and install works fine now! I also tested line by line debugging with it and that also works without any issues.

Here are the answers to questions you asked earlier:

Output of “php -r 'xdebug_info();' | grep Clock”:
<pre>
Clock Source => gettimeofday
</pre>
Output of “grep -r XDEBUG_CLOCK config.h”:
<pre>
config.h:/ #undef HAVE_XDEBUG_CLOCK_GETTIME /
config.h:#define HAVE_XDEBUG_CLOCK_GETTIME_NSEC_NP 0
</pre>

Excellent! I'll merge and close this then.

https://github.com/xdebug/xdebug/pull/790