Closed CosmicToast closed 1 year ago
Sounds like (b), but for JSON installs.
Try
HOMEBREW_NO_INSTALL_FROM_API=1 brew install --HEAD tcc
Okay, that does get me through that, but it fails to build (because homebrew explicitly --enable-cross
and tries to build the cross-compilers, which indeed do not work).
So that's a bug that (ideally) would be fixed, then.
As an aside, would it be possible to remove https://github.com/Homebrew/homebrew-core/blob/master/Formula/tcc.rb#L42 conditionally under macos?
(In the meanwhile, I'll just install it manually into /usr/local
, since it has a well-behaved uninstall
make target.)
As an aside, would it be possible to remove https://github.com/Homebrew/homebrew-core/blob/master/Formula/tcc.rb#L42 conditionally under macos?
This used to work on macOS, though, since that's the configuration used to build older bottles, so it seems more like that this is a regression that should be reported upstream.
Also, I can't reproduce your build failure locally. Using the formula as is with brew install --HEAD tcc
works for me.
Yeah dependencies are a bit of a mess right now. It's something that actually stems back to how the JSON was structured initially years ago that we tried to avoid changing for backwards compatibility, but we probably shouldn't do that anymore.
Also, I can't reproduce your build failure locally. Using the formula as is with
brew install --HEAD tcc
works for me.
The specific error is libtcc1.c:624: error: can't cross compile long double constants
.
This could be because of me being on Apple Silicon, or me being on Ventura.
I don't know enough about compilers to diagnose this properly, unfortunately - all I can say is that there's an ifndef for tests that falls into a final else.
Are you running Ventura on an M2?
Are you running Ventura on an M2?
Neither -- but now that I've tested it on my M1 Ventura machine, I've encountered the same error you did. I think @cho-m tested --HEAD
on M1 for #97932, though, so this still does look like a regression somewhere.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
The tcc
build failure is probably upstream. Maybe due to https://repo.or.cz/tinycc.git/commit/19ef024aa9c11a75bc441ed687e60974254c204b
Will probably need someone upstream to help fix macOS.
Anyway, I would recommend using a different means of installing tcc
like your own fork or Formula to pick "good" commits. Homebrew only supports stable releases which tcc
hasn't done in a long time. Projects that still use tcc
usually track/vendor their own copy of mob branch (e.g. vlang
).
I've landed a large change in https://github.com/Homebrew/brew/pull/15566 which fixes this issue of not using the head do
block correctly. It will be a part of 4.0.27 unless any problems arise.
In terms of the specific tcc
build failure, that's something to discuss in a pull request or with upstream.
brew gist-logs <formula>
link ORbrew config
ANDbrew doctor
outputVerification
brew doctor
output" saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
and am still able to reproduce my issue.brew doctor
and that did not fix my problem.What were you trying to do (and why)?
I'm trying to install tcc from HEAD (aka mob branch). While the latest "release" is known not to work on macos >catalina, I know for a fact that it's functioning perfectly well (as I have manually built it with no issues, including running arbitrary programs using it). To do so, I was trying to run
brew install tcc --HEAD
. When this failed to work (see following section), I tried specifying that I do indeed want to build it from source, withbrew install tcc --HEAD -s
. Neither worked.What happened (include all command output)?
What did you expect to happen?
I expected it to build from source and test successfully. This expectation is based on:
depends_on maximum_macos: :catalina
being specified inside of astable
block as per the formula.My presumption is that I'm doing something wrong, but it's odd since I've previously installed HEAD packages the same way. The alternatives I can think of are: a) The recent swap to JSON means that the versioning information is pinned to
stable
and cached in a way that can't be bypassed (I also tried with--force
) b) Thestable
block is leakyStep-by-step reproduction instructions (by running
brew
commands)