Opened 3 months ago

Last modified 10 days ago

#54939 assigned defect

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

Reported by: pmetzger (Perry E. Metzger) Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version:
Keywords: highsierra Cc: axet (Alexey Kuznetsov), michaellass (Michael Lass), ENOTTY, chrisminett (Chris Minett), gavaza (Luiz Gavaza), jknockaert (Jasper Knockaert), fleason (Fred Leason), svalgaard (Jens Svalgaard Kohrt), ksbeattie (Keith Beattie), basmac, p-bro, nhojpatrick (John Patrick), dershow, StAlex74 (Alexander)
Port: osxfuse

Description

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.

Change History (28)

comment:1 Changed 3 months ago by ryandesign (Ryan Schmidt)

  • Keywords highsierra added
  • Owner set to drkp
  • Status changed from new to assigned
  • Summary changed from osxfuse not building under High Sierra to osxfuse @3.7.1: Library not loaded: @rpath/libclang.dylib (LoadError)

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

comment:2 Changed 3 months ago by ryandesign (Ryan Schmidt)

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

comment:3 Changed 3 months ago by 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.

comment:4 Changed 3 months ago by ryandesign (Ryan 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.

comment:5 Changed 3 months ago by pmetzger (Perry E. Metzger)

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

comment:6 Changed 2 months ago by axet (Alexey Kuznetsov)

  • Cc axet added

comment:7 Changed 2 months ago by michaellass (Michael Lass)

  • Cc michaellass added

comment:8 Changed 2 months ago by ENOTTY

  • Cc ENOTTY added

comment:9 follow-up: Changed 2 months ago by 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
Last edited 2 months ago by hardwhack (previous) (diff)

comment:10 Changed 2 months ago by chrisminett (Chris Minett)

  • Cc chrisminett added

comment:11 Changed 2 months ago by ryandesign (Ryan Schmidt)

  • Cc gavaza added

Has duplicate #55093.

comment:12 Changed 2 months ago by 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.

comment:13 Changed 2 months ago by 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 :>

comment:14 Changed 2 months ago by jknockaert (Jasper Knockaert)

  • Cc jknockaert added

comment:15 in reply to: ↑ 9 Changed 2 months ago by 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.

comment:16 Changed 2 months ago by 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?

comment:17 Changed 2 months ago by 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...

comment:18 Changed 2 months ago by 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.

comment:19 Changed 8 weeks ago by fleason (Fred Leason)

  • Cc fleason added

comment:20 Changed 7 weeks ago by svalgaard (Jens Svalgaard Kohrt)

  • Cc svalgaard added

comment:21 Changed 6 weeks ago by ksbeattie (Keith Beattie)

  • Cc ksbeattie added

comment:22 Changed 5 weeks ago by basmac

  • Cc basmac added

comment:23 Changed 4 weeks ago by basmac

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

comment:24 Changed 4 weeks ago by p-bro

  • Cc p-bro added

comment:25 follow-up: Changed 4 weeks ago by nhojpatrick (John Patrick)

  • Cc nhojpatrick added

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.
$
Last edited 4 weeks ago by nhojpatrick (John Patrick) (previous) (diff)

comment:26 Changed 2 weeks ago by dershow

  • Cc dershow added

comment:27 in reply to: ↑ 25 Changed 2 weeks ago by fleason (Fred Leason)

Replying to nhojpatrick:

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

Worked for me. Thanks.

comment:28 Changed 10 days ago by StAlex74 (Alexander)

  • Cc StAlex74 added
Note: See TracTickets for help on using tickets.