osxfuse @3.7.1: Library not loaded: @rpath/libclang.dylib (LoadError)

[pmetzger (Perry E. Metzger)]

osxfuse won't build under High Sierra. I get the following error near the end of my main.log:

:info:build /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': dlopen(/System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle, 9): Library not loaded: @rpath/libclang.dylib (LoadError)
:info:build   Referenced from: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle
:info:build   Reason: image not found - /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle

This is especially weird because the file /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle is definitely there.

[ryandesign (Ryan Carsten Schmidt)]

Yes, /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle is there. But, unlike on macOS Sierra, on High Sierra the bridgesupportparser.bundle links with libclang.dylib, and that's what it thinks doesn't exist ("Library not loaded: @rpath/libclang.dylib (LoadError)"), at least not in whatever directory "@rpath" expands to in this context. I see libclang.dylib in the following locations on High Sierra:

• /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib
• /Applications/Xcode.app/Contents/Frameworks/libclang.dylib
• /Library/Developer/CommandLineTools/usr/lib/libclang.dylib

[ryandesign (Ryan Carsten Schmidt)]

What version of Xcode are you using? For High Sierra, you'll need at least Xcode 9.

[pmetzger (Perry E. Metzger)]

I'm on Xcode 9. Everything is fresh and up to date. Which isn't to say that I might not be doing something else wrong.

[ryandesign (Ryan Carsten Schmidt)]

I can confirm the problem on our buildbot worker:

​https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/613/steps/install-port/logs/stdio

Slightly different wording of the error:

/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': dlopen(/System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle, 0x0009): required dylib '@rpath/libclang.dylib' not found, needed by '/System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle'.  Did try: file not found '/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.13.xctoolchain/usr/lib/libclang.dylib', file not found '/usr/lib/libclang.dylib', file not found '/usr/local/lib/libclang.dylib' - /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle (LoadError)
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.rb:6:in `<top (required)>'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /usr/bin/gen_bridge_metadata:65:in `<main>'
Command /bin/sh failed with exit code 1

Here is the osxfuse bug report about this problem:

​https://github.com/osxfuse/osxfuse/issues/416

Sounds like they are considering it a bug in macOS or Xcode.

[pmetzger (Perry E. Metzger)]

Looks hard to fix inside the MacPorts codebase, too. Thoughts?

[hardwhack]

Found a workaround until a real fix comes along. According to link given above (comment:4) which in turn links to: ​https://github.com/amirrajan/rubymotion-applied/issues/18

Can fix/workaround using:

cd /Applications/Xcode.app/Contents/Developer/Toolchains
sudo ln -s XcodeDefault.xctoolchain OSX10.13.xctoolchain

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #55093.

[kencu (Ken)]

This is a minor macOS bug. The rpath in /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle points towards a non-existant path in the released version of Xcode 9, and there is no copy of libclang.dylib in the default search paths /usr/lib and /usr/local/lib

$ otool -l /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 96
         path /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.13.xctoolchain/usr/lib (offset 12)

but

$ cd /Applications/Xcode.app/Contents/Developer/Toolchains
$ ls
XcodeDefault.xctoolchain

You should be able to fix it by adding or replacing the rpath, like this for exampe:

$ sudo install_name_tool -add_rpath /Applications/Xcode.app/Contents/Frameworks/ /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle

but SIP, presumably, stops you:

error: install_name_tool: can't open input file: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle for writing (Operation not permitted)
error: install_name_tool: can't lseek to offset: 4096 in file: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle for writing (Bad file descriptor)
error: install_name_tool: can't write new headers in file: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle (Bad file descriptor)
error: install_name_tool: can't lseek to offset: 151552 in file: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle for writing (Bad file descriptor)
error: install_name_tool: can't write new headers in file: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle (Bad file descriptor)
error: install_name_tool: can't close written on input file: /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle (Bad file descriptor)

I thought that setting the fallback path might work:

post-patch {
    system "export DYLD_FALLBACK_LIBRARY_PATH=/Applications/Xcode.app/Contents/Frameworks/"
}

but it doesn't seem to, for some reason. That would be our main hope of fixing in the current Portfile.

Making the symbolic link as noted above fixes the missing path, so it works. SIP doesn't stop you from messing in the XCode directory.

I suspect this will be fixed in some soon-to-be-released macOS update.

Another method of making the libclang.dylib available without disabling SIP is to symlink it into the default rpath search path:

sudo mkdir /usr/local/lib
sudo ln -s /Applications/Xcode.app/Contents/Frameworks/libclang.dylib /usr/local/lib/libclang.dylib

I don't immediately see how to fix this in the Portfile, though.

[kencu (Ken)]

Aha: any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

<​https://developer.apple.com/library/content/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html>

That would be why setting the fallback doesn't work any more. The portfile could make the symlink, build the port, and then delete the symlink I guess. Or we can wait for Apple's no-doubt-upcoming fix, which is what I assume we'll be doing :>

[RafalLukawiecki (Rafal Lukawiecki)]

Replying to hardwhack:

Found a workaround until a real fix comes along. According to link given above (comment:4) which in turn links to: ​https://github.com/amirrajan/rubymotion-applied/issues/18

Can fix/workaround using:

cd /Applications/Xcode.app/Contents/Developer/Toolchains
sudo ln -s XcodeDefault.xctoolchain OSX10.13.xctoolchain

For what it is worth, I can confirm that this workaround has worked for me. After installing osxfuse I was able to delete the symlink and I am able to use the newly installed osxfuse. I hope that ensures things work automatically when the issue has been fixed upstream. Thank you for sharing.

[pmetzger (Perry E. Metzger)]

Note that XCode 9.0.1 came out today, and the bug still seems to be there, so we probably need to assume it may be a while before Apple fixes it. Is there any possible workaround we can put into the Portfile on our own?

[kencu (Ken)]

Sure, it would be possible to make the symlink in the portfile in a post-extract block maybe, build and install the port, and then perhaps delete the symlink in a post-destroot block, but it's pretty hacky to do that.

Any reason not to just make the symlink as noted above yourself, then build the port with the portfile as it is? Anything else that uses /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle is broken until that gets fixed anyway, not just this port...

[pmetzger (Perry E. Metzger)]

I've already built it myself. This isn't for my benefit as such. I don't like leaving ports broken. But I assume that short of the symlink there's no fix here, yes? And that doesn't seem like a good answer.

[basmac]

Causes others to fail
--->  Computing dependencies for sshfs
--->  Dependencies to be installed: osxfuse
--->  Building osxfuse
Error: Failed to build osxfuse: command execution failed

[nhojpatrick (John Patrick)]

just to confirm, i did the symlink and it then build and installed.

$ cd /Applications/Xcode.app/Contents/Developer/Toolchains
$ sudo ln -s XcodeDefault.xctoolchain OSX10.13.xctoolchain
$ sudo port install sshfs
--->  Computing dependencies for sshfs
The following dependencies will be installed:  osxfuse
Continue? [Y/n]: y
--->  Building osxfuse
--->  Staging osxfuse into destroot
Warning: osxfuse installs files outside the common directory structure.
--->  Installing osxfuse @3.7.1_0
--->  Activating osxfuse @3.7.1_0
--->  Cleaning osxfuse
--->  Fetching archive for sshfs
--->  Attempting to fetch sshfs-2.10_0.darwin_17.x86_64.tbz2 from https://packages.macports.org/sshfs
--->  Attempting to fetch sshfs-2.10_0.darwin_17.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/sshfs
--->  Attempting to fetch sshfs-2.10_0.darwin_17.x86_64.tbz2 from http://lil.fr.packages.macports.org/sshfs
--->  Fetching distfiles for sshfs
--->  Attempting to fetch sshfs-2.10.tar.gz from https://distfiles.macports.org/sshfs
--->  Attempting to fetch sshfs-2.10.tar.gz from http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/sshfs
--->  Attempting to fetch sshfs-2.10.tar.gz from http://lil.fr.distfiles.macports.org/sshfs
--->  Attempting to fetch sshfs-2.10.tar.gz from http://nue.de.distfiles.macports.org/sshfs
--->  Attempting to fetch sshfs-2.10.tar.gz from http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/sshfs
--->  Attempting to fetch sshfs-2.10.tar.gz from https://github.com/libfuse/sshfs/tarball/sshfs-2.10
--->  Verifying checksums for sshfs
--->  Extracting sshfs
--->  Applying patches to sshfs
--->  Configuring sshfs
--->  Building sshfs
--->  Staging sshfs into destroot
--->  Installing sshfs @2.10_0
--->  Activating sshfs @2.10_0
--->  Cleaning sshfs
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  Some of the ports you installed have notes:
  osxfuse has the following notes:
    When upgrading, unmount all FUSE filesystems and then unload the kernel extension.
    Unloading can be done via: sudo kextunload -b com.github.osxfuse.filesystems.osxfuse
    Alternatively (or if this fails), just reboot your computer now.
$

[fleason (Fred Leason)]

Replying to nhojpatrick:

just to confirm, i did the symlink and it then build and installed.

Worked for me. Thanks.

[nbenm]

It worked for me too.
What will happen when the issue will be solved? I think I will not remember to remove the symlink.
Thanks

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #55561.

[kencu (Ken)]

has duplicate 55817

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #55892.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #55996.

[raimue (Rainer Müller)]

Has duplicate #56118.

[kencu (Ken)]

I assume there is a radar item for this bug. I would have guessed a fix to be rolled out by this point, as there have been several Xcode updates since this was identified.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #56316.

[TauSodan]

PhaseScriptExecution BridgeSupport\ Metadata build/OSXFUSE.build/Release/OSXFUSE.build/Script-28D525C40EA8076400B7CF7B.sh
    cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-431bdc5/framework
    /bin/sh -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-431bdc5/framework/build/OSXFUSE.build/Release/OSXFUSE.build/Script-28D525C40EA8076400B7CF7B.sh
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': dlopen(/System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle, 0x0009): required dylib '@rpath/libclang.dylib' not found, needed by '/System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle'.  Did try: file not found '/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.13.xctoolchain/usr/lib/libclang.dylib', file not found '/usr/lib/libclang.dylib', file not found '/usr/local/lib/libclang.dylib' - /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.bundle (LoadError)
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /System/Library/BridgeSupport/ruby-2.3/bridgesupportparser.rb:6:in `<top (required)>'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /usr/bin/gen_bridge_metadata:65:in `<main>'
Command /bin/sh failed with exit code 1

This:

/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.13.xctoolchain/

Does not exist. The Toolchains directory only contains:

XcodeDefault.xctoolchain

The rest of that directory structure is the same.

EDIT: Made a symlink. Build worked.

[pmetzger (Perry E. Metzger)]

See: ​https://github.com/macports/macports-ports/pull/1749 which proposes a workaround for this bug for the medium term, in the form of a slightly hacky patch for the CI system and a message alerting users to the workaround if they attempt to install osxfuse on the problematic macOS versions.

[raimue (Rainer Müller)]

Upstream ​closed the issue with "working now". What was their solution? Isn't there any change we could backport?

[pmetzger (Perry E. Metzger)]

I have no idea how they may have fixed it. Maybe the latest OS X or Xcode update did something?

[yan12125 (Chih-Hsuan Yen)]

In 3a645ca0dc0f481394d3b056e710ad196e92be55/macports-ports (master):

osxfuse: add notes about the workaround for building on High Sierra

See also #54939

[yan12125 (Chih-Hsuan Yen)]

In dcea9ed02b41ebb7d251cd4d8939f6b130432ecd/macports-ports (master):

_ci: apply a workaround for osxfuse on High Sierra

See also #54939

[pmetzger (Perry E. Metzger)]

yan12125's workaround has now been applied. However, I think this should remain open until the underlying problem gets fixed.

[kencu (Ken)]

has duplicate 56744

[ryandesign (Ryan Carsten Schmidt)]

The second fix—the one added to the notes in [b4e61d9f372b7ec38201038e15c6eb713482d7e6/macports-ports]—is needed on macOS Mojave.

[svalgaard (Jens Svalgaard Kohrt)]

After an upgrade to Xcode 10.0 building osxfuse failed - I tried all 3 fixes mentioned above. Rebooting the mac made it work.

I used the fix mentioned by ryandesign above, i.e.,

    mkdir -p /usr/local/lib/
    sudo ln -s "$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib" /usr/local/lib/

[ztalbot2000 (John Talbot)]

I came across the exact same error building with High Sierra, but the workaround of "ln -s XcodeDefault.xctoolchain OSX10.13.xctoolchain" was not enough. Like many developers I have multiple versions of Xcode installed as Xcode7.3.1.app, Xcode8.3.3.app, Xcode9.4.1.app and Xcode10.0.app. None of which are Xcode.app. xcode-select points to Xcode9.4.1.

I also had to create the symbolic link of Xcode9.4.1..app -> Xcode.app for osxfuse to build.

I'm just pointing this out in case others still have the issue.

John Talbot

[ryandesign (Ryan Carsten Schmidt)]

In 2f27b9efd9e35826ea04c615281f5bfc653f3f49/macports-ports (master):

osxfuse: Apply gen_bridge_metadata workaround on Mojave

The problem still exists on Mojave, so include that in the check.

The problem will cause a build failure, so don't even try to build if
the workaround has not been performed.

Clean up the suggested workaround commands.

Move the detection of the problem from post-extract to pre-build since
that's where it's actually needed.

See: #54939

[ryandesign (Ryan Carsten Schmidt)]

Since Apple still hasn't fixed it and it still affects High Sierra and Mojave, I reported the bug to Apple as rdar://46511701. Looks like yan12125 previously reported it as rdar://40649128.

[yan12125 (Chih-Hsuan Yen)]

Replying to ryandesign:

Since Apple still hasn't fixed it and it still affects High Sierra and Mojave, I reported the bug to Apple as rdar://46511701. Looks like yan12125 previously reported it as rdar://40649128.

Yep, I've also copied the report to ​https://openradar.appspot.com/40649128

[ryandesign (Ryan Carsten Schmidt)]

In b66d28709bf066163009ac7160ed3bf90a27373e/macports-ports (master):

Travis: Generalize gen_bridge_metadata fix

Generalize the workaround for the broken gen_bridge_metadata /
bridgesupportparser.bundle since it affects both High Sierra and Mojave.

Decide when to apply the workaround not based on OS_MAJOR but based on
whether gen_bridge_metadata works or not.

See: #54939

[yan12125 (Chih-Hsuan Yen)]

In be38d386c05c02383bc50c054c219a2930123146/macports-ports (master):

osxfuse: don't build BridgeSupport metadata by default

Building BridgeSupport metadata is broken on High Sierra or newer due to
an macOS and/or Xcode bug [1]. As the workaround breaks building iTerm2
[2], I'd like to skip the fragile step instead playing more with Xcode
and macOS.

[1] #54939
[2] ​https://github.com/macports/macports-ports/pull/3525#issuecomment-458799559