Installing universal boost fails with "Failed changing install name"

[omegahm]

Bug reports:

When reinstalling boost with universal, I get an error with "Failed changing install name"

$ brew reinstall boost --universal
==> Reinstalling boost --universal
==> Using the sandbox
==> Downloading https://downloads.sourceforge.net/project/boost/boost/1.62.0/boost_1_62_0.tar.bz2
Already downloaded: /Users/ohm/Library/Caches/Homebrew/boost-1.62.0.tar.bz2
==> ./bootstrap.sh --prefix=/usr/local/Cellar/boost/1.62.0 --libdir=/usr/local/Cellar/boost/1.62.0/lib --without-icu --without-libraries=python,context,coroutine,mpi
==> ./b2 headers
==> ./b2 --prefix=/usr/local/Cellar/boost/1.62.0 --libdir=/usr/local/Cellar/boost/1.62.0/lib -d2 -j4 --layout=tagged --user-config=user-config.jam install threading=multi,single link=shared,static address-mod
Error: Failed changing install name in /usr/local/Cellar/boost/1.62.0/lib/libboost_chrono-mt.dylib
  from libboost_system-mt.dylib
    to @loader_path/libboost_system-mt.dylib
Error: Failed to fix install linkage
The formula built, but you may encounter issues using it or linking other
formula against it.
==> Caveats

Building of Boost.Context and Boost.Coroutine is disabled as they are
only supported on x86_64.
==> Summary
🍺  /usr/local/Cellar/boost/1.62.0: 12,401 files, 661.7M, built in 25 minutes

Installing boost without the universal binary works "fine", but then I cannot use both x64 and i386 boost, when compiling my own stuff.

I have also tried with various combinations of --with-icu4c, --with-mpi and --universal, which all fails in different ways.

Log-files are present here: https://gist.github.com/anonymous/e1f7a08dc18cc1102608e847a1d2d6c7

[MikeMcQuaid]

CC @woodruffw for thoughts. This may just result in us dropping --universal for boost.

[woodruffw]

I'm building boost now to test this locally, but my bet is that they've just removed i386 support for Boost.Chrono. If that's the case, our options are disabling --universal entirely or just selectively disabling Chrono when --universal is toggled (just as we do with Boost.Context and Boost.Coroutine currently).

[woodruffw]

Interestingly, otool -L shows the correct linkage AFAICT:

$ otool -L /usr/local/Cellar/boost/1.62.0/lib/libboost_chrono-mt.dylib 
/usr/local/Cellar/boost/1.62.0/lib/libboost_chrono-mt.dylib:
	/usr/local/opt/boost/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.4.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

And ruby-macho confirms this:

>> m.linked_dylibs
=> ["@loader_path/libboost_system-mt.dylib", "/usr/lib/libc++.1.dylib", "/usr/lib/libSystem.B.dylib"]

Edit: The inner exception is:

Error: While modifying Mach-O slice 0: No such dylib name: libboost_system-mt.dylib

Since ruby-macho modifies files in non-strict mode for Homebrew, this actually means that both slices failed (i386 and x86_64). Since the output from otool contradicts this, I'm not sure what to make of this.

[MikeMcQuaid]

If that's the case, our options are disabling --universal entirely

This definitely seems like the right option. Having --universal not install modules (which I realise it does currently) feels extremely 😭 to me.

[woodruffw]

Having --universal not install modules (which I realise it does currently) feels extremely 😭 to me.

I agree. Providing only one arch is preferable to providing 1.5 arches. That being said, this error is very perplexing - all the relocations seem to have been performed correctly. I'm going to spend a bit more time trying to get to the bottom of it.

[ilovezfs]

@woodruffw ping on this

[woodruffw]

@ilovezfs @MikeMcQuaid I think we should go ahead and disable --universal here. I haven't found anything that indicates this is a bug in ruby-macho, so my guess is that Boost.Chrono has gone the way of the other non-i386 modules.

I'll open the PR in a bit.

[woodruffw]

Opened #8660.