fontforge fails to install, because glibtoolize doesn't respect Homebrew's Library location

Question

fontforge fails to install, because glibtoolize doesn't respect Homebrew's Library location

the-real-tokai opened this issue 9 years ago · 21 comments

I'm not entirely sure what's going on here or how to fix this (except manually hacking glibtoolize):

$ brew install fontforge
==> Downloading https://github.com/fontforge/fontforge/archive/20150824.tar.gz
==> Downloading from https://codeload.github.com/fontforge/fontforge/tar.gz/20150824
######################################################################## 100.0%
==> Cloning git://git.savannah.gnu.org/gnulib.git
Cloning into '/Library/Caches/Homebrew/fontforge--gnulib--git'...
remote: Counting objects: 161863, done.
remote: Compressing objects: 100% (24105/24105), done.
remote: Total 161863 (delta 137719), reused 161829 (delta 137700)
Receiving objects: 100% (161863/161863), 30.41 MiB | 260.00 KiB/s, done.
Resolving deltas: 100% (137719/137719), done.
Checking connectivity... done.
==> ./bootstrap --gnulib-srcdir=/Library/Caches/Homebrew/fontforge--gnulib--git --skip-git

bootstrap:   error: One of these is required:
bootstrap:                 libtoolize glibtoolize
bootstrap: running: --quiet
./bootstrap: line 4287: --quiet: command not found

READ THIS: https://git.io/brew-troubleshooting

glibtoolize (via libtool formula, v2.4.6) is available in the system, but it looks like it's broken and the glibtoolize script links to sed in a location that doesn't exist on my system (my Homebrew stuff is located in /usr/local/homebrew/ and not merged into /usr/local directly, so it should be /usr/local/homebrew/Library/ENV/4.3/sed.)

$ which libtoolize
$ which glibtoolize
/usr/local/bin/glibtoolize

$ glibtoolize --version
/usr/local/bin/glibtoolize: line 406: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 2513: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 2513: /usr/local/Library/ENV/4.3/sed: No such file or directory
 (GNU libtool) 2.4.6
/usr/local/bin/glibtoolize: line 1941: /usr/local/Library/ENV/4.3/sed: No such file or directory

$ brew --cellar
/usr/local/homebrew/Cellar

I guess the broken glibtoolize breaks the build/ bootstrap process of fontforge.

Answer 1 · 2015-09-13T14:04:47.000Z

I manually hacked

/usr/local/homebrew/Cellar/libtool/2.4.6/bin/glibtool line 88 from SED="/usr/local/Library/ENV/4.3/sed" to SED="/usr/local/homebrew/Library/ENV/4.3/sed"

and

/usr/local/homebrew/Cellar/libtool/2.4.6/bin/glibtoolize line 49 from : ${SED="/usr/local/Library/ENV/4.3/sed"} to : ${SED="/usr/local/homebrew/Library/ENV/4.3/sed"}

and the bootstrap stuff of fontforge was able to finish, so the problem is definitely the hardcoded default homebrew paths in glibtool and glibtoolize (from the libtool formula.)

Answer 2 · 2015-11-18T16:45:52.000Z

You could also set the SED environment variable instead of hacking into the installed programs.

export SED=$(brew --cellar)/../Library/ENV/4.3/sed

Or, inline.

SED=$(brew --cellar)/../Library/ENV/4.3/sed glibtoolize --version

Answer 3 · 2015-11-18T17:23:59.000Z

Out of curiosity, did you recently move your HOMEBREW_PREFIX? Homebrew's binary package for libtool uses a placeholder variable that gets filled in with Homebrew's prefix at time of install.

SED="@@HOMEBREW_PREFIX@@/Library/ENV/4.3/sed"

Answer 4 · 2015-11-18T17:48:43.000Z

No, I never moved my Homebrew installation. So nothing changed in this regards on my installation ever. Though I noticed that not using /usr/localdirectly triggers problems sometimes. Seems not many people use and test Homebrew in such way. 😄

Perhaps the problem is that the libtool dependency was brought in as a bottle to my installation:

$ cat /usr/local/homebrew/Cellar/libtool/2.4.6/INSTALL_RECEIPT.json 
{"used_options":[],"unused_options":["--universal"],"built_as_bottle":true,"poured_from_bottle":true,"time":1424152323,"HEAD":"e7d27d600dced77d929c1a80eb72a034552c7f12","stdlib":null,"compiler":"clang","source":{"tap":"Homebrew/homebrew"}}

Therefore someone else's default path setup was used to built the scripts? Just a random guess. Not sure. But then the problem is not the prefix (which is /usr/local on my setup too), but the Cellar location where Homebrew's sed is located:

$ brew --prefix
/usr/local
$ brew --cellar
/usr/local/homebrew/Cellar

In the formula (https://github.com/Homebrew/homebrew/blob/master/Library/Formula/libtool.rb
) it only seems to pass the prefix, but not the cellar location during installation. It probably needs to patch the scripts properly after the installation (no matter if it came from a bottle or was built from source).

Answer 5 · 2015-11-19T16:32:29.000Z

This is how I installed brew.

sudo chown -R $LOGNAME /usr/local
mkdir $HOME/Library/Homebrew
curl -L https://github.com/Homebrew/homebrew/tarball/master | tar xz --strip 1 -C $HOME/Library/Homebrew
ln -s $HOME/Library/Homebrew/bin/brew /usr/local/bin

Then libtool was installed as a dependency of some other formula.

$ cat $HOME/Library/Homebrew/Cellar/libtool/2.4.6/INSTALL_RECEIPT.json
{"used_options":[],"unused_options":["--universal"],"built_as_bottle":true,"poured_from_bottle":true,"time":1441972507,"HEAD":"be2d4a312e173c90f43ec14d1717e7bdfba28ffd","stdlib":null,"compiler":"clang","source":{"path":"/usr/local/Library/Formula/libtool.rb","tap":"Homebrew/homebrew","spec":"stable"}}

Brew prefix and Cellar.

$ brew --prefix
/usr/local
$ brew --cellar
/Users/viotti/Library/Homebrew/Cellar

Answer 6 · 2015-11-20T12:12:42.000Z

@viotti And what does grep 'SED=".*"' $HOME/Library/Homebrew/Cellar/libtool/2.4.6/bin/* prints out in your case?

In my case it would print out the wrong paths to sed:

$ grep 'SED=".*"' /usr/local/homebrew/Cellar/libtool/2.4.6/bin/*
/usr/local/homebrew/Cellar/libtool/2.4.6/bin/glibtool:SED="/usr/local/Library/ENV/4.3/sed"
/usr/local/homebrew/Cellar/libtool/2.4.6/bin/glibtoolize:: ${SED="/usr/local/Library/ENV/4.3/sed"}

(/usr/local/Library/ENV/4.3/sed instead the correct /usr/local/homebrew/Library/ENV/4.3/sed)

I installed my stuff rather similar to your way besides using a different path. 😄 Of course, manually overwriting SED each time might work, but that's just a unnecessary kludge, IMHO. I consider the installed glibtool and glibtoolize files not properly working on my setup. And they probably fail like that for you too, if an incorrect path (that doesn't exists on your installation) is used.

Answer 7 · 2015-11-20T12:19:11.000Z

This command should do more generally: (cd "$(brew --cellar)/libtool/2.4.6/bin" && grep 'SED=".*"' *) (in case anyone else wants to check/ verify 😄 )

Answer 8 · 2015-11-20T13:16:20.000Z

Yep, /usr/local/Library/ENV/4.3/sed.

$  grep 'SED=".*"' $HOME/Library/Homebrew/Cellar/libtool/2.4.6/bin/*
/Users/viotti/Library/Homebrew/Cellar/libtool/2.4.6/bin/glibtool:SED="/usr/local/Library/ENV/4.3/sed"
/Users/viotti/Library/Homebrew/Cellar/libtool/2.4.6/bin/glibtoolize:: ${SED="/usr/local/Library/ENV/4.3/sed"}

I totally agree that overriding SED is not a definitive solution. I proposed it just as a temporary workaround. This is how the tool fails for me.

$ sh autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I config --force -I config
autoreconf: configure.ac: tracing
autoreconf: running: glibtoolize --copy --force
/usr/local/bin/glibtoolize: line 406: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 2513: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 2513: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 3601: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 3845: /usr/local/Library/ENV/4.3/sed: No such file or directory
/usr/local/bin/glibtoolize: line 861: /usr/local/Library/ENV/4.3/sed: No such file or directory
: putting auxiliary files in '.'.
: copying file './ltmain.sh'
/usr/local/bin/glibtoolize: line 3771: /usr/local/Library/ENV/4.3/sed: No such file or directory
autoreconf: running: /Users/viotti/Library/Homebrew/Cellar/autoconf/2.69/bin/autoconf --include=config --force
autoreconf: running: /Users/viotti/Library/Homebrew/Cellar/autoconf/2.69/bin/autoheader --include=config --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:50: installing 'config/compile'
configure.ac:53: installing 'config/config.guess'
configure.ac:53: installing 'config/config.sub'
configure.ac:19: installing 'config/install-sh'
configure.ac:54: error: required file 'config/ltmain.sh' not found
configure.ac:19: installing 'config/missing'
Makefile.am: installing 'config/depcomp'
parallel-tests: installing 'config/test-driver'
autoreconf: automake failed with exit status: 1
autogen.sh: error: autoreconf exited with status 1

OTOH, presetting SED makes autogen.sh work.

$ SED=$(brew --cellar)/../Library/ENV/4.3/sed sh autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I config --force -I config
autoreconf: configure.ac: tracing
autoreconf: running: glibtoolize --copy --force
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
glibtoolize: copying file 'config/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'config'.
glibtoolize: copying file 'config/libtool.m4'
glibtoolize: copying file 'config/ltoptions.m4'
glibtoolize: copying file 'config/ltsugar.m4'
glibtoolize: copying file 'config/ltversion.m4'
glibtoolize: copying file 'config/lt~obsolete.m4'
autoreconf: running: /Users/viotti/Library/Homebrew/Cellar/autoconf/2.69/bin/autoconf --include=config --force
autoreconf: running: /Users/viotti/Library/Homebrew/Cellar/autoconf/2.69/bin/autoheader --include=config --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:50: installing 'config/compile'
configure.ac:19: installing 'config/missing'
Makefile.am: installing 'config/depcomp'
autoreconf: Leaving directory `.'

Answer 9 · 2015-11-24T09:30:23.000Z

my Homebrew stuff is located in /usr/local/homebrew/ and not merged into /usr/local directly, so it should be /usr/local/homebrew/Library/ENV/4.3/sed.)

@the-real-tokai Can you elaborate more about how you have a /usr/local/bin/glibtoolize if your Homebrew is installed into /usr/local/homebrew/?

This is how I installed brew.

@viotti That configuration isn't really supported (and I'd probably rather we just killed it as it's going to be full of bugs as we don't test it).

Answer 10 · 2015-11-24T10:51:03.000Z

@MikeMcQuaid

$ brew --cellar
/usr/local/homebrew/Cellar
$ brew --prefix
/usr/local
$ stat -f '%N -> %Y' -- /usr/local/bin/glibtool
/usr/local/bin/glibtool -> ../homebrew/Cellar/libtool/2.4.6/bin/glibtool
$ stat -f '%N -> %Y' -- /usr/local/bin/glibtoolize 
/usr/local/bin/glibtoolize -> ../homebrew/Cellar/libtool/2.4.6/bin/glibtoolize

brew install <foobar> sets it up like that. It also links the formula directories of Cellar into /usr/local/opt/.

I like it that way, as it keeps the random homebrew directories (Cellar, .git, Library, etc.) cleanly separated into /usr/local/homebrew without causing chaos in /usr/local/ (I have to install other things in there too for multiple users which are not and can't be maintained by brew).

Removing the possibility to install homebrew in such way(s) as workaround for such harmless issues like the broken 'glibtool*' path would be a rather unwelcome step, IMHO. In general it works rather well, and certainly this issue could be fixed directly in the formula, I believe. 😄

Answer 11 · 2015-11-24T10:57:00.000Z

I like it that way, as it keeps the random homebrew directories (Cellar, .git, Library, etc.) cleanly separated into /usr/local/homebrew without causing chaos in /usr/local/ (I have to install other things in there too for multiple users which are not and can't be maintained by brew).

It also means you won't get most binary packages and have weird bugs like this. I'd recommend just adding /usr/local/homebrew/bin to your PATH instead and not putting Homebrew stuff in /usr/local/bin

Answer 12 · 2015-11-24T11:28:26.000Z

@MikeMcQuaid I'm not entirely sure what you mean with 'won't get most binary packages'. But in /usr/local/homebrew/bin there's only the brew binary (nothing else). This is a git maintained directory and having it clearly separated from the user packages stuff is a good thing, IMHO.

Anyway…
I don't think your recommendations would solve the glibtool* path problem either, since the hardcoded sed path in the glibtool* scripts still would miss the extra /homebrew part, I believe.

Answer 13 · 2015-11-24T11:39:46.000Z

@MikeMcQuaid I'm not entirely sure what you mean with 'won't get most binary packages'.

Most of our binary packages only work if you install Homebrew into /usr/local.

Answer 14 · 2015-12-19T01:40:44.000Z

Been using Homebrew for over a year in non-standard directories to avoid privileged installs that increases the chances of compromising a hosting OS. Swapping around HOMEBREW_PREFIX, HOMEBREW_CELLAR, HOMEBREW_LIBRARY_PATH, and HOMEBREW_CACHE in my shell makes it easy to test new packages or combination of pacakges. During several OSX upgrades over the last few years, /usr/local files installed by brew were destroyed. Overall, my experience using this approach has been very satisfying, even with pre-existing binary bottles.

For:

setenv HOMEBREW_PREFIX ~/usr2/local
setenv HOMEBREW_REPOSITORY ~/usr2/local/homebrew
setenv HOMEBREW_CELLAR ~/usr2/local/homebrew/Cellar
setenv HOMEBREW_CACHE ~/usr2/local/cache
setenv HOMEBREW_LIBRARY_PATH ~/usr2/local/homebrew/Library

Adding setenv SED $HOMEBREW_LIBRARY_PATH/ENV/4.3/sed to my ~/.cshrc file and % source ~/.cshrc was a quick and dirty fix that I can live with in the short term.

It is interesting to note that:

brew --prefix     => yields $HOMEBREW_PREFIX
brew --repository => yields $HOMEBREW_REPOSITORY
brew --cellar     => yields $HOMEBREW_CELLAR
brew --cache      => yields $HOMEBREW_CACHE

but note there is no brew --library_path to complement the commands above and those below.

brew --version
brew --config
brew --env

Answer 15 · 2015-12-25T18:21:20.000Z

@skaht We don't support overriding variables like that, just to note. Please don't file issues that arise when using that configuration, thanks.

Answer 16 · 2016-03-21T01:25:04.000Z

@MikeMcQuaid - Point taken concerning using a non-standard HOMEBREW_PREFIX.

However, here is a solution realized today to using bottled libtool binary that definitely has a sed path location issue with a non-standard HOMEBREW_PREFIX. It also is possible to get libtool-2.4.6 to overcome the SED issue above by:

brew update
brew uninstall libtool
setenv HOMEBREW_BUILD_FROM_SOURCE
brew install libtool

Is there a list of bottled binary compatibility issues slowly emerging when people use their own HOMEBREW_PREFIX?

Answer 17 · 2016-03-21T09:54:33.000Z

@skaht To help us debug this issue can you explain:

What you were trying to do (and why)
What happened
What you expected to happen
Step-by-step reproduction instructions (with as minimal input data as possible) using a new, non-/usr/local HOMEBREW_PREFIX (without any of your above customisations) and showing the sed issue.

Answer 18 · 2016-07-20T09:27:49.000Z

I recently have the issue related to/usr/local/Library/ENV/4.3/sed in El Capitan (10.11.5), the issue was mainly caused by /usr/local/Cellar/apr/1.5.2/libexec/build-1/libtool
Edit the file itself then replace from SED="/usr/local/Library/ENV/4.3/sed" to SED="/usr/bin/sed" and installation of httpd22 and mod_fastcgi worked smoothly

Answer 19 · 2016-07-20T15:16:06.000Z

monnoval's solution worked for me just now on el capitan.

Answer 20 · 2016-07-20T19:30:14.000Z

@monnoval For me, brew uninstall libtool && brew install libtool solved the issue on El Capitan.

Answer 21 · 2016-08-10T09:12:24.000Z

Sounds like this is mostly fixed. If not: we'll accept PRs for this but we're not actively working on it at this time.