Opened 6 years ago

Last modified 3 years ago

#54939 assigned defect

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

Reported by: pmetzger (Perry E. Metzger) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: highsierra mojave Cc: axet (Alexey Kuznetsov), michaellass (Michael Lass), ENOTTY, chrisminett (Chris Minett), gavaza (Luiz Gavaza), jknockaert (Jasper Knockaert), fleason (Fred Leason), svalgaard (Jens Svalgaard Kohrt), basmac, p-bro, nhojpatrick (John Patrick), dershow, StAlex74 (Alexander), porchy13, majoc-at-astro (majoc-at-astro), Schamschula (Marius Schamschula), hapaguy (Brian Kurt Fujikawa), leondong, Feuermurmel (Michael Schwarz), LizardM4 (Pietro Saccardi), SickTeddyBear, dsedivec, maehne (Torsten Maehne), rlhamil, ryandesign (Ryan Carsten Schmidt)
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 (70)

comment:1 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: highsierra added
Owner: set to drkp
Status: newassigned
Summary: osxfuse not building under High Sierraosxfuse @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 6 years ago by ryandesign (Ryan Carsten Schmidt)

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

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

comment:5 Changed 6 years ago by pmetzger (Perry E. Metzger)

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

comment:6 Changed 6 years ago by axet (Alexey Kuznetsov)

Cc: axet added

comment:7 Changed 6 years ago by michaellass (Michael Lass)

Cc: michaellass added

comment:8 Changed 6 years ago by ENOTTY

Cc: ENOTTY added

comment:9 Changed 6 years 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 6 years ago by hardwhack (previous) (diff)

comment:10 Changed 6 years ago by chrisminett (Chris Minett)

Cc: chrisminett added

comment:11 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: gavaza added

Has duplicate #55093.

comment:12 Changed 6 years 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 6 years 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 6 years ago by jknockaert (Jasper Knockaert)

Cc: jknockaert added

comment:15 in reply to:  9 Changed 6 years 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 6 years 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 6 years 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 6 years 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 6 years ago by fleason (Fred Leason)

Cc: fleason added

comment:20 Changed 6 years ago by svalgaard (Jens Svalgaard Kohrt)

Cc: svalgaard added

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

Cc: ksbeattie added

comment:22 Changed 6 years ago by basmac

Cc: basmac added

comment:23 Changed 6 years 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 6 years ago by p-bro

Cc: p-bro added

comment:25 Changed 6 years 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 6 years ago by nhojpatrick (John Patrick) (previous) (diff)

comment:26 Changed 6 years ago by dershow

Cc: dershow added

comment:27 in reply to:  25 Changed 6 years 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 6 years ago by StAlex74 (Alexander)

Cc: StAlex74 added

comment:29 Changed 6 years ago by 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

comment:30 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: porchy13 added

Has duplicate #55561.

comment:31 Changed 6 years ago by majoc-at-astro (majoc-at-astro)

Cc: majoc-at-astro added

comment:32 Changed 6 years ago by Schamschula (Marius Schamschula)

Cc: Schamschula added

comment:33 Changed 6 years ago by hapaguy (Brian Kurt Fujikawa)

Cc: hapaguy added

comment:34 Changed 6 years ago by kencu (Ken)

has duplicate 55817

comment:35 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: leondong added

Has duplicate #55892.

comment:36 Changed 6 years ago by Feuermurmel (Michael Schwarz)

Cc: Feuermurmel added

comment:37 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: LizardM4 added

Has duplicate #55996.

comment:38 Changed 6 years ago by raimue (Rainer Müller)

Has duplicate #56118.

comment:39 Changed 6 years ago by 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.

comment:40 Changed 6 years ago by SickTeddyBear

Cc: SickTeddyBear added

comment:41 Changed 6 years ago by dsedivec

Cc: dsedivec added

comment:42 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: willbprog127 added

Has duplicate #56316.

comment:43 Changed 6 years ago by 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.

Last edited 5 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:44 Changed 6 years ago by 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.

comment:45 Changed 6 years ago by raimue (Rainer Müller)

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

comment:46 Changed 6 years ago by pmetzger (Perry E. Metzger)

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

comment:47 Changed 6 years ago by yan12125 (Chih-Hsuan Yen)

In 3a645ca0dc0f481394d3b056e710ad196e92be55/macports-ports (master):

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

See also #54939

comment:48 Changed 6 years ago by yan12125 (Chih-Hsuan Yen)

In dcea9ed02b41ebb7d251cd4d8939f6b130432ecd/macports-ports (master):

_ci: apply a workaround for osxfuse on High Sierra

See also #54939

comment:49 Changed 6 years ago by pmetzger (Perry E. Metzger)

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

comment:50 Changed 6 years ago by ksbeattie (Keith Beattie)

Cc: ksbeattie removed

comment:51 Changed 6 years ago by Battant

Cc: Battant added

comment:52 Changed 6 years ago by Battant

Cc: Battant removed

comment:53 Changed 6 years ago by Battant

Cc: Battant added

comment:54 Changed 6 years ago by Battant

Cc: Battant removed

comment:55 Changed 6 years ago by kencu (Ken)

has duplicate 56744

comment:56 Changed 6 years ago by maehne (Torsten Maehne)

Cc: maehne added

comment:57 Changed 6 years ago by yan12125 (Chih-Hsuan Yen)

Cc: yan12125 added

comment:58 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: mojave added

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

comment:59 Changed 5 years ago by 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/

comment:60 Changed 5 years ago by 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

comment:61 Changed 5 years ago by willbprog127 (Will Brokenbourgh)

Cc: willbprog127 removed

comment:62 Changed 5 years ago by 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

comment:63 Changed 5 years ago by rlhamil

Cc: rlhamil added

comment:64 Changed 5 years ago by 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.

comment:65 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign added

comment:66 in reply to:  64 Changed 5 years ago by 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

comment:67 Changed 5 years ago by 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

comment:68 Changed 5 years ago by 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

comment:69 Changed 4 years ago by yan12125 (Chih-Hsuan Yen)

Cc: yan12125 removed

comment:70 Changed 3 years ago by mf2k (Frank Schima)

Owner: drkp deleted
Note: See TracTickets for help on using tickets.