Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Build failure on systems that don't support clock_gettime / clockid_t #1501

Closed
ryandesign opened this issue Jul 31, 2023 · 4 comments
Closed

Comments

@ryandesign
Copy link
Contributor

ryandesign commented Jul 31, 2023

Describe the issue

Expected successful build but got:

[ 63%] Building CXX object absl/log/CMakeFiles/log_initialize.dir/initialize.cc.o
In file included from /tmp/abseil-cpp/absl/synchronization/internal/kernel_timeout.cc:15:
/tmp/abseil-cpp/absl/synchronization/internal/kernel_timeout.h:94:45: error: unknown type name 'clockid_t'; did you mean 'clock_t'?
  struct timespec MakeClockAbsoluteTimespec(clockid_t c) const;
                                            ^~~~~~~~~
                                            clock_t
/usr/include/sys/types.h:223:26: note: 'clock_t' declared here
typedef __darwin_clock_t        clock_t;
                                ^
[ 64%] Building CXX object absl/flags/CMakeFiles/flags_marshalling.dir/marshalling.cc.o
[ 64%] Building CXX object absl/log/CMakeFiles/log_internal_format.dir/internal/log_format.cc.o
[ 64%] Built target random_seed_sequences
/tmp/abseil-cpp/absl/synchronization/internal/kernel_timeout.cc:152:58: error: unknown type name 'clockid_t'; did you mean 'clock_t'?
struct timespec KernelTimeout::MakeClockAbsoluteTimespec(clockid_t c) const {
                                                         ^~~~~~~~~
                                                         clock_t
/usr/include/sys/types.h:223:26: note: 'clock_t' declared here
typedef __darwin_clock_t        clock_t;
                                ^
[ 64%] Linking CXX static library libabsl_examine_stack.a
/tmp/abseil-cpp/absl/synchronization/internal/kernel_timeout.cc:165:18: error: use of undeclared identifier 'clock_gettime'
  ABSL_RAW_CHECK(clock_gettime(c, &now) == 0, "clock_gettime() failed");
                 ^

Steps to reproduce the problem

Build abseil on OS X 10.11 or earlier

What version of Abseil are you using?

f324c90 (c9c0fd5 plus the fix for #1500)

What operating system and version are you using?

ProductName:	Mac OS X
ProductVersion:	10.8.5
BuildVersion:	12F2560

What compiler and version are you using?

clang version 16.0.6
Target: x86_64-apple-darwin12.6.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-16/bin

What build system are you using?

cmake version 3.24.4

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Additional context

clock_gettime and clockid_t did not exist in macOS prior to macOS 10.12. Can you use alternate code on earlier systems? You did not used to require clock_gettime prior to 1a72ea7.

@derekmauro
Copy link
Member

@derekmauro derekmauro closed this as not planned Won't fix, can't repro, duplicate, stale Jul 31, 2023
@barracuda156
Copy link

@derekmauro How about fixing the bug instead of ignoring it?

@derekmauro
Copy link
Member

@derekmauro How about fixing the bug instead of ignoring it?

If you want my respect you need to communicate professionally. Our support policy does not include this platform. If you would like to make the case that we should change the policy, that is fine, but comments like this are not appropriate.

@barracuda156
Copy link

@derekmauro I apologize for my comment. You make a fair point.

Regarding the support: it is perfectly understandable that abseil developers may not have resources (time and hardware) to provide any dedicated support for older macOS. However if a passive support can be considered, that would be helpful. We got a number of ports which use abseil, and those ports work on old systems. Whatever can be fixable from our end we can handle, provided the upstream is ready to accept reasonable PRs.

Technical details: it is a common, but inaccurate assumption that what is actually supported on a given macOS version is what Apple decided to support in its last Xcode version for that OS. In reality, all Intel systems back to 10.6 can use modern libc++ and latest Clangs, and PowerPC systems back to 10.5 can use the latest libstdc++ and latest GCC (as of now, at least: I can confirm that at least GCC 13 builds and works on 10.6 ppc). SDK does impose certain limitations, indeed, but to a considerable extent those can be and are de facto overcome. Macports uses legacysupport library for that, which among other stuff provides implementation of clock_gettime. As a matter of fact, most of modern C/C++ software builds, works and passes tests on old systems (where by old I mean including Leopard, but excluding Tiger). Perhaps one problem which is indeed often non-trivial to fix or unfixable is Obj C stuff, but in those cases generic Unix fallbacks usually work. In majority of cases there are no technical reasons to deny support to older OS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants