Time.h typedef redefinition with iOS 10 set as a deployment target

[grabbou]

Hey,

I am working on a Hermes support for React Native and while working on it, I have run into the following issue, when building the React Native project:

React Native has deployment target set to 10.0 for all its parts, including third party pod specs such as RCT-Folly, that it defines to download and compile Folly with pieces that it needs. After changing the deployment target for RCT-Folly specifically from 10.0 to 9.0, the issue goes away.

This is a temporary workaround that we have implemented to unblock the PR.

I believe it is caused by the following code:

#if __MACH__ &&                                                       \
        ((!defined(TARGET_OS_OSX) || TARGET_OS_OSX) &&                \
         (MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_12)) || \
    (TARGET_OS_IPHONE && (__IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_10_0))

#ifdef FOLLY_HAVE_CLOCK_GETTIME
#undef FOLLY_HAVE_CLOCK_GETTIME
#endif

#define FOLLY_HAVE_CLOCK_GETTIME 1
#define FOLLY_FORCE_CLOCK_GETTIME_DEFINITION 1

#endif

The way I read it is - when building for iPhone and targeting iOS versions lower than 10.0 (e.g. 9.0), don't define macros. When building for newer iOS release, such as 10.0, define it. Shouldn't it be the opposite, if the purpose was to provide backwards compatibility?

The issue is being brought up from time to time in various projects - that's where I have learnt about the "deployment target" workaround:

• Catalyst + ReactNative: Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t') error when building for mac target react-native#28810
• [0.62.0-rc.3] Catalyst macOS build issue typedef redefinition with different types react-native#27845
• Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t') when building latest react-native rc with macOS target flipper#834

Here are my questions:

• What was the original intent behind this particular if condition? Where is the "__IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_10_0" requirement coming from?
• Is the workaround applied in our PR a valid fix?

[Orvid]

In general the fixes for clock_gettime on apple platforms have been a bit complicated, but hopefully @chadaustin has some idea if this would be the right fix for iOS.

[hengkx]

same

[chadaustin]

This stuff is always a pain. I'm trying to understand exactly what's going on in your failing case.

We only #define CLOCK_REALTIME if FOLLY_HAVE_CLOCK_GETTIME is 0 (and Apple/Windows).

Would it make sense if

folly/folly/portability/Time.h

Line 46 in b26907e

#if !FOLLY_HAVE_CLOCK_GETTIME && (defined(__MACH__) || defined(_WIN32))

checked FOLLY_FORCE_CLOCK_GETTIME_DEFINITION instead?

Are you asking about the PR that pins back to iOS 9.0? I'd support tweaking these conditions to make them more accurate.

[grabbou]

We only #define CLOCK_REALTIME if FOLLY_HAVE_CLOCK_GETTIME is 0 (and Apple/Windows).

Yeah, and this seems to be only valid when __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_10_0 is false. In other words, you define CLOCK_REALTIME on all iOS that are 10.0 or newer.

Is that correct? If yes, why? My gut feeling would be that any backwards compatibility should be run on older releases of iOS, not newer.

Since React Native targets iOS 10.0 by default, I had to manually set Folly project to 9.0 as a deployment target.

[gaberogan]

This is still an issue for me in May 2021. Is there a plan to fix?

[jwaldrip]

This is an issue for me as well after the 12.5 upgrade. Do we have any idea on a fix timeline? I would PR but I don't want the fix to cause issues with older versions of xcode.

[fierysolid]

set __IPHONE_10_0 to __IPHONE_12_0 inside of Time.h for a temp workaround

[kyle-ssg]

Unfortunately setting __IPHONE_12_0 still throws this for me.

[spencerKitson]

Changing to __IPHONE_12_0 as per @fierysolid's suggestion worked for me.

[emretapci]

I forced the #if macro to evaluate to true by adding 1 || to the following line:

#if 1 || __MACH__ &&                                                       \
        ((!defined(TARGET_OS_OSX) || TARGET_OS_OSX) &&                \
         (MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_12)) || \
    (TARGET_OS_IPHONE && (__IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_10_0))

and it compiled successfully.

[supercranky]

I solved it by adding this to the Podfile:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == "RCT-Folly"
      target.build_configurations.each do |config|
        config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'FOLLY_HAVE_CLOCK_GETTIME=1']
      end
    end
  end
end

By modifiing GCC_PREPROCESSOR_DEFINITIONS for RCT-Folly you don't have to touch the source (and works with a clean install)

[atsuya046]

@supercranky's suggestion worked for me.

[Saadnajmi]

#1688 Might fix this ?

[dennisplucinik]

I solved it by adding this to the Podfile:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == "RCT-Folly"
      target.build_configurations.each do |config|
        config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'FOLLY_HAVE_CLOCK_GETTIME=1']
      end
    end
  end
end

By modifiing GCC_PREPROCESSOR_DEFINITIONS for RCT-Folly you don't have to touch the source (and works with a clean install)

This solved it for me. Running Xcode 13.1 on a Mac Mini M1 macOS v11.6 with React Native 0.66.2

[Saadnajmi]

We can close this?

[NickGerleman]

I updated React Native to a version of Folly with the fix in 4a2410f and we just started seeing the redefinition error again 😅. Going to try to workaround with manually setting FOLLY_HAVE_CLOCK_GETTIME for now...

[Saadnajmi]

I updated React Native to a version of Folly with the fix and we just started seeing the redefinition error for the first time 😅. Going to try to workaround with manually setting FOLLY_HAVE_CLOCK_GETTIME for now...

Oh :(, you might want to undo my earlier change removing the patch then.

[NickGerleman]

Let me try manually setting the availability first. Would rather that then the sed style patching to headers happening before. Though, we should maybe try another spin at fixing feature detection.

Afaict, in a stock CocoaPods XCode 15 setup, __CLOCK_AVAILABILITY is not set, so after the change, we fail the new detection.