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

brew install fail: C compiler cannot create executables #114

Closed
sahrens opened this issue Jun 24, 2015 · 3 comments
Closed

brew install fail: C compiler cannot create executables #114

sahrens opened this issue Jun 24, 2015 · 3 comments

Comments

@sahrens
Copy link

sahrens commented Jun 24, 2015

I was getting the "ERROR Watcher took too long to load" issue in React Native, and the troubleshooting said to uninstall and re-install watchman --head. First thing I noticed was watchman wasn't installed via brew - maybe an fb chef issue?

06/24/2015 10:18:19 sahrens-mbp : ~/src/fbobjc-hg/Libraries/FBReactKit
% watchman version
{
    "version": "3.2.0"
}
06/24/2015 10:19:01 sahrens-mbp : ~/src/fbobjc-hg/Libraries/FBReactKit
% brew uninstall watchman
Error: No such keg: /usr/local/Cellar/watchman

Then I tried installing anyway:

06/24/2015 10:20:17 sahrens-mbp : ~/src/fbobjc-hg/Libraries/FBReactKit
% brew install --HEAD watchman
==> Installing dependencies for watchman: autoconf, automake, pkg-config, pcre
...
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/private/tmp/watchman20150624-8275-1epq85s':
configure: error: C compiler cannot create executables
See `config.log' for more details

And I saw this in config.log:

ld: building for iOS Simulator, but linking against dylib built for MacOSX file '/usr/lib/libSystem.dylib' for architecture x86_64

(full config.log: https://gist.github.com/sahrens/162598cd4070965eb604)

Tried googling, installed latest Xcode Command Line Tools, tried setting HOMEBREW_CC=gcc-5 (broke in a different way), no dice.

% gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.2.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix

brew doctor complains about some static libs and dylibs, maybe from chef? https://gist.github.com/61f6bb44e839c7fdddc4

@sahrens
Copy link
Author

sahrens commented Jun 24, 2015

I have Xcode 6.3.2

@wez
Copy link
Contributor

wez commented Jun 24, 2015

The build problems are almost certainly a local to your machine issue; we haven't changed anything with the watchman build machinery in some time, and I just tried rebuilding and installing via homebrew just now; it worked fine. Perhaps worth noting, although I doubt it is significant, I had an update to the xcode cli tools that got installed last night.

Separately from that, both brew and the FB deployment system are shipping 3.2. We tagged 3.3 this week but there have been no changes to the service since then that might impact the "took too long to load" error.

However, we did release fb-watchman 1.0.0 to npm yesterday that switches the nodejs client for watchman from using JSON to use our BSER encoding which resolves a dramatic quadratic-wrt-size-of-response perf problem in a JSON stream module that we were using. Perhaps that will quash that class of error? #113 has more on that.

My suggestion is to either let chef keep you on 3.2 or just do a brew install watchman and let brew download the bottled watchman binary.

I can't help you resolve your local build issue I'm afraid; I'm just not intimate enough with the FB specifics to give you helpful advice.

@wez
Copy link
Contributor

wez commented Jun 30, 2015

Closing this out as a local build/tooling problem

@wez wez closed this as completed Jun 30, 2015
dgrnbrg-meta added a commit to dgrnbrg-meta/watchman that referenced this issue Mar 11, 2022
Summary:
X-link: facebook/fboss#114

X-link: facebook/fb303#27

When using getdeps inside of a container, Python's urllib isn't able to download from dewey lfs (see this post for details https://fb.workplace.com/groups/systemd.and.friends/permalink/2747692278870647/).

This allows for getdeps to use `libcurl` to fetch dependencies, which allows for a getdeps build to work inside the container environment.

Reviewed By: mackorone

Differential Revision: D34696330

fbshipit-source-id: 57855716f40d758d5e39f09d09d11ef6556a8a82
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

2 participants