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

Folly DistributedMutex using unavailable methods. #1527

Open
exception opened this issue Feb 18, 2021 · 16 comments
Open

Folly DistributedMutex using unavailable methods. #1527

exception opened this issue Feb 18, 2021 · 16 comments

Comments

@exception
Copy link

Using the latest XCode beta with a React Native app, Folly is failing to build due to an unavailable method being called within DistributedMutex-inl.h, as shown below.

image

@daidai21
Copy link

The reason for the gcc/clang version?

https://en.cppreference.com/w/cpp/atomic/atomic_notify_one since C++20

@gaberogan
Copy link

Happening for me too. Please address this. Xcode release is coming out like tomorrow.

@ivanmoskalev
Copy link

React Native builds are also broken because of this.

@Orvid
Copy link
Contributor

Orvid commented Mar 1, 2021

Do you know which commit triggered this? The line of code you're referring to has been there for more than 2 years now.

@gaberogan
Copy link

@Orvid Like we said it's not a commit it's the Xcode Beta itself that breaks this.

@aary
Copy link
Contributor

aary commented Mar 2, 2021

Apologies for addressing this a bit late. We have a potential fix, working on it...

facebook-github-bot pushed a commit that referenced this issue Mar 8, 2021
Summary:
`std::atomic_wait()` and `std::atomic_notify_one()` are marked as unavailable.
Not really sure what that means, but it seems to be breaking some open source
builds #1527.  Explicitly qualify the
calls into those functions to try and fix the build break.

Since we cannot conditionally import either of the above (because they are
marked as unavailable), we can't rely on the standard implementations.  To
prevent ADL from kicking in when the standard-library defines these, we fully
qualify these and use `tag_invoke` for the customization points used in tests.

Reviewed By: davidtgoldblatt

Differential Revision: D26742072

fbshipit-source-id: 9f44bbfd37530f5ecffa3e03d673cfb1df953299
dotconnor pushed a commit to 5448C8/folly that referenced this issue Mar 19, 2021
Summary:
`std::atomic_wait()` and `std::atomic_notify_one()` are marked as unavailable.
Not really sure what that means, but it seems to be breaking some open source
builds facebook#1527.  Explicitly qualify the
calls into those functions to try and fix the build break.

Since we cannot conditionally import either of the above (because they are
marked as unavailable), we can't rely on the standard implementations.  To
prevent ADL from kicking in when the standard-library defines these, we fully
qualify these and use `tag_invoke` for the customization points used in tests.

Reviewed By: davidtgoldblatt

Differential Revision: D26742072

fbshipit-source-id: 9f44bbfd37530f5ecffa3e03d673cfb1df953299
@lucasjohnston
Copy link

lucasjohnston commented Apr 27, 2021

Xcode 12.5 has been released. Is there a workaround for this? I can't build anything right now 😬
After a prompt last night upgraded my iPhone to iOS 14.5, and was subsequently forced by Xcode to upgrade to 12.5 today, now I can't work at all

Happy to help where I can but don't know my way around the RN codebase particularly well, it's pretty daunting!

Edit: If anyone else comes across this, looks like a fix has been pushed but not released yet. Workaround in the meantime - facebook/flipper#2215 (comment)

@Orvid
Copy link
Contributor

Orvid commented Apr 27, 2021

8477e25 should have fixed this

@AlexHooperDev
Copy link

Manually editing the Flipper-Folly pod file just pushes the compile error onto a subsequent Flipper pod, and does not fix the issue for me :-( When I try to disable Flipper in the podfile, I get this when trying to build the app:

CompileC /Users/alex.hooper/Library/Developer/Xcode/DerivedData/Espresso-brgntaoyjolqyfdzcsunjlqtzzum/Build/Intermediates.noindex/Espresso.build/Debug-iphoneos/Espresso.build/Objects-normal/arm64/AppDelegate.o /Users/alex.hooper/Documents/figloo-bank-mobile/ios/Espresso/AppDelegate.m normal arm64 objective-c com.apple.compilers.llvm.clang.1_0.compiler

So I'm pretty stuck right now, any suggestions massively appreciated as I think a lot of people are in this situation.

@edrreisp
Copy link

edrreisp commented Apr 27, 2021

The solutions that worked for me was comment out the flipper part on the Podfile

use_flipper!({ 'Flipper' => '0.86.0' })
post_install do |installer|
flipper_post_install(installer)
end

@roncodes
Copy link

Now facing this issue, commenting out flipper post install portion does not work for me. Started happening after I upgraded Xcode this morning.

@roncodes
Copy link

roncodes commented Apr 28, 2021

I managed to resolve this by removing flipper altogether. As some suggested to remove the flipper post install hook.

This alone did not resolve the issue. For iOS I went ahead and removed every reference to flipper, namely the InitializeFlipper function and it's imports.

UPDATE:

I did more digging and was able to restore Flipper and get everything to build successfully with this workaround found here #31441 (comment)

Back in business.

@PrimulaX
Copy link

Can't build on xCode 12.5, why commenting out flipper in pod file doesn't work?

@Orvid
Copy link
Contributor

Orvid commented Apr 30, 2021

Upstream flipper podspecs should be updated.

@aprilmintacpineda
Copy link

This is happening to me. I updated from 0.63.4 to 0.64.1. I don't even have flipper enabled. I think it doesn't have anything to do with flipper.

I managed to resolve this by removing flipper altogether. As some suggested to remove the flipper post install hook.

This alone did not resolve the issue. For iOS I went ahead and removed every reference to flipper, namely the InitializeFlipper function and it's imports.

UPDATE:

I did more digging and was able to restore Flipper and get everything to build successfully with this workaround found here #31441 (comment)

Back in business.

How about in CI?

@aprilmintacpineda
Copy link

8477e25 should have fixed this

Has that been released?

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