dave$ brew reinstall graphviz
==> Reinstalling graphviz
==> Downloading https://homebrew.bintray.com/bottles/graphviz-2.40.1_1.high_sier
Already downloaded: /Users/dave/Library/Caches/Homebrew/downloads/2bf5346e72953a60aa26af766451ff7cf1439f4c020c0dc24ee5db10b9795ade--graphviz-2.40.1_1.high_sierra.bottle.tar.gz
==> Pouring graphviz-2.40.1_1.high_sierra.bottle.tar.gz
🍺 /usr/local/Cellar/graphviz/2.40.1_1: 500 files, 11.3MB
I installed graphviz with homebrew. How do I start it after that?
You don't. Graphviz is a tool not a GUI.
To test it you can do something simple like create a simple graph:
digraph "a" {
a -> b
}
and then run dot with it.
$ dot -Tpng -otest.png test.dot
$ open test.png
We also have a Graphviz.app GUI, that is not distributed via Homebrew, or even built in our CI framework on GitLab. I verified last night it still builds and runs and looks ok. The build is extra specially arcane. I'm not sure what to do about this, except it would not be too much trouble to manually package and distribute stable versions on www2.graphviz.org.
I would like to know if Homebrew would take on Graphviz.app (which would mean making the build look more like other GUI programs) but I'm not even sure who to ask.
Related
I've installed Go 1.13.4 in Debian Linux 10 using brew, package golang (previously I've removed golang-1.11 installed via apt). It follows brew info output.
$ brew info golang
go: stable 1.13.4 (bottled), HEAD
Open source programming language to build simple/reliable/efficient software
https://golang.org
/home/linuxbrew/.linuxbrew/Cellar/go/1.13.4 (9,271 files, 408.1MB) *
Poured from bottle on 2019-12-07 at 14:31:52
From: https://github.com/Homebrew/linuxbrew-core/blob/master/Formula/go.rb
==> Requirements
Required: macOS is required âś”
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 1,571 (30 days), 8,628 (90 days), 31,650 (365 days)
install-on-request: 784 (30 days), 4,096 (90 days), 13,267 (365 days)
build-error: 0 (30 days)
When I try to execute go build on a package with code calls native OS functions, GO compiler tells that it's unable to find gcc-5 command as presented below.
$ go build
# _/home/giacomo/src/goproc/process
exec: "gcc-5": executable file not found in $PATH
So I've installed latest GCC (9.2.1) from testing (deb http://ftp.us.debian.org/debian testing main contrib non-free) repository and created a symbolic link to /usr/bin/x86_64-linux-gnu-gcc-9.
This solved the problem. But the question is: is this the correct way to fix the problem? Or is there a place to properly configure the GCC used by golang?
Any clarification very appreciated!
Since it looks like you have installed go with linuxbrew, you can also install gcc-5:
brew install gcc#5
This solves the problem for me cleanly.
got this issue in linuxbrew. to fix run:
go env -w CC=gcc CXX="g++"
This uses the system gcc/g++ instead of the ones from linuxbrew
Another option to try is setting the CC environment variable to gcc.
(Not really an answer as what you asked is hardly a real question—see below.)
There's multiple points which seem wrong with your situation; let's consider them all.
The first thing to consider is that "Go" means two things: a language which has certain syntax and semantics, and one of implementations of it.
Go-the-language has at least two mature implementations: the "reference" one—available from the Go's main site—and another one—a part of the GCC. Stock contemporary Debian distribution (Debian 10, "Buster") ships both of them: golang-go is the former and gccgo is the latter.
As you can see, it's not clear which one you've installed, in the first place.
The second thing to consider is that the reference implementation (dubbed gc by its original developers for the reasons I forgot) is completely free-standing (and even self-bootstrapping) and does not use any C compiler (from GCC or other) to build Go code. Conversely, gccgo naturally uses other parts of the GCC toolchain to build the Go code.
Still, Go code features a special subsystem called cgo which can be use to interface Go code with code written in C (and with compiled libraries adhering to the C API. When building a program which uses cgo, both Go suites do rely on at least a C compiler (and may be linker—I don't know this for sure), and by default gc expects to be able to use a GCC-compatible compiler, and naturally, gccgo uses the C compiler of GCC, too.
Let's now recap a bit.
As you should supposedly see by now, you at least ought to sort several things for you:
What implementation of Go you're talking about (and/or want installed)?
Is what you have installed by brew is really what you intended to get?
Does the code you're trying to build use cgo?
The fourth thing to consider is why on Earth have you decided to use a kludge invented to help Mac users compensate for the lack of package management system on their platform to deal with packages in Debian.
Debian already ships Go; if you're not satisfied with the its packaged version (1.11), it looks simpler to merely grab the latest-and-greatest binary package from https://golang.org/dl, unack it and use.
Another thing to consider is that since version 1.5 Go is self-bootstrapping because it's written in Go, so if you want to have the latest upstream version, you can just apt install golang-go — to have some version of Go installed — and then use it to build the latest one, like this:
Get the Go source code:
$ cd ~
$ mkdir golang
$ git clone https://github.com/golang/go golang
Pick the version you want to build:
$ cd golang
$ git checkout go1.13.5
$ cd src
$ ./make.bash
Then make sure you have /home/user/golang/bin listed in your $PATH.
Note that building Go is lightning-fast: on a laptop with SSD it builds from cold start in under a minute.
An answer based on nemo's answer.
If you have Go installed via the system's package manager
and you installed linuxbrew on that system
and somehow, in my case I installed buf via brew,
linuxbrew's go package was pulled in,
you system's Go package was replaced by brew's Go package.
So in order to use your system's Go package again you have to uninstall brew's Go package.
brew uninstall go
or if you want to keep brew's Go package, do what nemo answered:
go env -w CC=gcc CXX="g++"
I am trying to setup watchman for the mac. As stated on the website, I need to install glibtool.
Can anyone provide a link to where I can download glibtool?
I need to be able to download it from its source and the only solution I can find is by using brew.
I do not want to use brew.
Thank you.
glibtool is "GNU Libtool". It is typically installed as libtool on most systems, but because macOS has its own libtool that has completely different functionality, it is usually installed as glibtool on macOS.
If you can't directly use homebrew to install it, you can duplicate the steps in its recipe, which you can find here: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libtool.rb
For the sake of keeping this answer "working" even if homebrew goes away, the homepage for libtool is https://www.gnu.org/software/libtool/ and you can follow the instructions there for information on how to build and install it.
I've covered similar issues to Wez's answer from a MacPorts perspective; I'll go ahead and assume you can't use that either.
The latest stable version at this time is 2.4.6. Typical best practice is to make a directory, e.g., build in the top level of the source. Add the prefix: g, with --program-prefix=g, the top level installation directory --prefix=PREFIX, or specify more fine-grained installation directories options for bin, include, lib, and share directories.
> mkdir build
> cd build
> ../configure --prefix=/my/install/path --program-prefix=g
> make; make install
You now have glibtool and glibtoolize in $PREFIX/bin.
I'm trying get Homebrew working with Xcode Command Line Tools, and they seem to be having it out with each other... In the words of Rodney King, "Can't we all just get along?"
For some background, when I first got my Mac about a year ago, I had no idea what I was doing. I was also using macports, which was, as the Homebrew website seems to be cognizant, driving me to become a raging alcoholic. As a result, my /usr/local directory got wayyy f-ed up. Eventually, gcc and g++ stopped working, and a lot of other things were breaking. So I did a clean install of OS X, and I want my shiny new installation to stay a little more organized.
Now, I've installed Apple's Command Line Tools, and all the binaries/libraries/etc have ended up in /usr/local. That's fine, but then I try to install homebrew, and it's also putting everything in the /usr/local/ directory. When I run the command
brew doctor
I get the following output (actually, this is just a snippet, but it captures the general spirit of what Homebrew is telling me):
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libatomic.a
/usr/local/lib/libgfortran.a
/usr/local/lib/libgmp.a
/usr/local/lib/libgomp.a
/usr/local/lib/libitm.a
/usr/local/lib/libmpc.a
/usr/local/lib/libmpfr.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libssp.a
/usr/local/lib/libssp_nonshared.a
/usr/local/lib/libstdc++.a
/usr/local/lib/libsupc++.a
I thought I might place Homebrew in a different directory; however, the Homebrew documentation specifically warned against this. They say:
"Do yourself a favor and install to /usr/local. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing to /usr/local. Pick another prefix at your peril!"
The whole point is that I don't want to bother with micro-managing every package I install, and I don't want my filesystem to become an ungodly mess either. Anyone have any suggestions? Do I move command line tools to a different directory and add this to my $PATH? Any tips would be much appreciated.
It's a warning, and the message says why. If you later want to install a Homebrew formula that installs one of those files, it will fail, because it will decline to overwrite those files, and then you will have to delete those files, as the message says.
Specifically, those files appear to belong to an installation of gcc. You might want to research or try to remember why that was installed there. It's probably OK to just delete them and install gcc from Homebrew if you need it.
On OS X cpanm Image::Magick fails with
Magick.xs:60:10: fatal error: 'magick/MagickCore.h' file not found
#include < magick/MagickCore.h>
The file is present though. (That space is from me to have it display here.)
How can I tell cpanm and/or Image::Magick where to find those headers?
(IM is installed from source.)
Workaround: download Module, edit Makefile.PL (add header dir to includes), make, make install as written on the imagemagick homepage.
While the question is rather old, I still ran into this issue recently.
I was able to resolve it with new ImageMagick installed via homebrew (brew install imagemagick which installed version 6.9.5-3), then firing up cpan and installing JCRISTY/PerlMagick-6.89-1.tar.gz package.
It fails in test section. Thus I analysed what tests fails and decided to cheat a bit (I don't need all ImageMagick functions). I manually edited tests files (use look Image::Magick to get into unarchived package) – for me, it was required to completely comment out test for input.miff (reference/filter/Segment.miff) in t/filter.t and tests for MPEG read in t/mpeg/read.t. Then cpan is able to process Image::Magick finally.
I ran my own tests upon set of GIF and PNG images and these are OK. Hope this helps someone.
It's late and I should go to bed and maybe that's why I can't figure this out. I'm on a fedora-13 machine and I just ran
yum install gambit-c
I installed it because I want to follow along in a schemed text book.
but now that it's installed, how do I start the scheme interpreter??
It looks from the RPM listing that the binaries are named gsi, gsix, and gsc, all in /usr/bin. I suspect that gsi is the interpreter.
For more details, there's also the manual entry for gsi.
BTW: I don't know about the Fedora RPM, but I found that the Ubuntu repository's Gambit-C was quite outdated (4.0-ish), with missing features like simple compilation of stand-alone executables. The most recent version is 4.6. If your RPM's version is a few decimal places behind, I'd suggest just installing from source; it's a pretty standard configure -> make -> make install sequence. Just remember the following option when running configure:
./configure --enable-single-host
This speeds things up quite a bit.