osxfuse @3.8.3: Assertion 'common_is_variable DEFAULT_SDK_10_15_ARCHITECURES' failed

[andrey-popov (Andrey Popov)]

Build of osxfuse @3.8.3 fails by SIGTERM on macOS 10.15 with Xcode 11.1. Here is the (somewhat?) relevant part from the log:

:info:build ^[[1;31mAssertion 'common_is_variable DEFAULT_SDK_10_15_ARCHITECURES' failed^[[0m
:info:build ^[[1;31mat common_variable_clone (./build.d/lib/common.sh, line 501)^[[0m
:info:build ^[[1;31mat common_variable_clone (./build.d/lib/common.sh, line 514)^[[0m
:info:build ^[[1;31mat build_target_invoke (./build.sh, line 657)^[[0m
:info:build ^[[1;31mat build_main (./build.sh, line 943)^[[0m
:info:build ^[[1;31mat main (./build.sh, line 951)^[[0m
:info:build ^GTerminated: 15
:info:build ^[[0;37mReceived signal: SIGTERM^[[0m
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-48bc246"    && ./build.sh -t packagemanager -a build -v 5 --build-directory="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/ work" -- -a x86_64 --framework-prefix="/opt/local" --fsbundle-prefix="/opt/local" --library-prefix="/opt/local"
:info:build Killed by signal: 15
:error:build Failed to build osxfuse: command execution failed

I'm attaching the full log. This doesn't seem to be the same problem as in #54939 as the log doesn't mention LoadError.

[knightjp]

Main - 2

[knightjp]

I am facing issues in getting osxfuse installed. The package I was hoping to install is ntfs-3g and osxfuse is a vital dependency.

Of course I'm not a developer, but if I were to think about it, I am guessing the change to zsh by Catalina does have an effect on the current scripts.

[yan12125 (Chih-Hsuan Yen)]

Per ​https://github.com/osxfuse/osxfuse/releases, Catalina support is available since 3.10.0, while the one in MacPorts is kept at 3.8.x as osxfuse is no longer an open source project since version 3.9.0 (1).

(1) ​https://github.com/osxfuse/osxfuse/issues/590.

[knightjp]

Replying to yan12125:

Per ​https://github.com/osxfuse/osxfuse/releases, Catalina support is available since 3.10.0, while the one in MacPorts is kept at 3.8.x as osxfuse is no longer an open source project since version 3.9.0 (1).

(1) ​https://github.com/osxfuse/osxfuse/issues/590.

Why doesn't my current install of Macports detect that I have FUSE installed?

[knightjp]

FUSE not getting detected as installed

[pmininni (Pablo Mininni)]

I was able to build ntfs-3g in Catalina by installing the latest version of OSXFuse (3.10.3) from ​https://github.com/osxfuse/osxfuse/releases, and then doing:

sudo ln -s /usr/local/lib/pkgconfig/fuse.pc /opt/local/lib/pkgconfig/fuse.pc
sudo port install ntfs-3g

The ntfs-3g port doesn't seem to require OSXFuse from Macports to build, just the fuse.pc file. I was able to build and install the ntfs-3g port, but I am not sure whether ntfs-3g is fully functional yet. If it works, maybe the portfile can be modified to look for fuse.pc in /usr/local/lib/pkgconfig, where the recent version of OSXFuse (needed for Catalina) places this file.

[knightjp]

Replying to pmininni:

I was able to build ntfs-3g in Catalina by installing the latest version of OSXFuse (3.10.3) from The ntfs-3g port doesn't require OSXFuse from Macports to build, just the fuse.pc file. I was able to build and install the ntfs-3g port, and it seems to work fine. Maybe the portfile can be modified to look for fuse.pc in /usr/local/lib/pkgconfig, where the recent version of OSXFuse (needed for Catalina) places this file.

If you installed ntfs-3g, how did you get around perl5.28? I understand that it has issues as well.

[pmininni (Pablo Mininni)]

Replying to knightjp:

If you installed ntfs-3g, how did you get around perl5.28? I understand that it has issues as well.

I had no problem with perl5.28 (@5.28.2_0). From what I can see, the latest Portfile already has implemented the "use_parallel_build no" fix reported in #59207. Try cleaning the port and reinstalling.

[knightjp]

Replying to pmininni:

I was able to build ntfs-3g in Catalina by installing the latest version of OSXFuse (3.10.3) from ​https://github.com/osxfuse/osxfuse/releases, and then doing:

sudo ln -s /usr/local/lib/pkgconfig/fuse.pc /opt/local/lib/pkgconfig/fuse.pc
sudo port install ntfs-3g

I have FUSE (3.10.3) installed. I tried the command that you mentioned. It doesn't work. All I get is

ln: /opt/local/lib/pkgconfig/fuse.pc: No such file or directory

Any ideas?

[knightjp]

Replying to pmininni:

Replying to knightjp:

If you installed ntfs-3g, how did you get around perl5.28? I understand that it has issues as well.

I had no problem with perl5.28 (@5.28.2_0). From what I can see, the latest Portfile already has implemented the "use_parallel_build no" fix reported in #59207. Try cleaning the port and reinstalling.

After installing ntfs, I have another issue with using the commands on this link.

wiki:howto/Ntfs3gFinder

When I use this command,

sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig

I get this error.

mv: rename /sbin/mount_ntfs to /sbin/mount_ntfs.orig: Read-only file system

[pmininni (Pablo Mininni)]

Replying to knightjp:

After installing ntfs, I have another issue with using the commands on this link.

wiki:howto/Ntfs3gFinder

When I use this command,

sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig

I get this error.

mv: rename /sbin/mount_ntfs to /sbin/mount_ntfs.orig: Read-only file system

This is caused by the security changes in Catalina. The system is now in a read-only file system. You can manually mount NTFS filesystems from the command line. Or, if you want to have NTFS filesystems showing up automatically in Finder (with write permission), you have to do some extra work. Besides disabling (temporarily) SIP with the command "csrutil disable", you also have to unlock the volume so you can write to it. The following link explains how to do it:

​https://github.com/osxfuse/osxfuse/wiki/NTFS-3G#auto-mount-ntfs-volumes-in-read-write-mode-on-macos-1015-catalina

I haven't tried it yet, but I would follow these instructions only to enable writing to the filesystem (i.e., disabling SIP, unlocking the volume, and re-enabling SIP). I would not do a symbolic link ("ln -s") as suggested there, as linking to a file outside /sbin can create a security issue. Instead, I will do what is suggested in wiki:howto/Ntfs3gFinder: You back-up /sbin/mount_ntfs and then create a new /sbin/mount_ntfs with the script provided in wiki:howto/Ntfs3gFinder.

[raulofpandora]

Same happens here trying to install encfs using macports, it needs osxfuse, but doesn't compile.

I installed FUSE for macOS 3.10.3 from its page, created the suggested soft links, but encfs doesn't detect it and macports try to compile osxfuse unsuccessfully.

Any thoughts?

[ryandesign (Ryan Carsten Schmidt)]

Replying to yan12125:

Per ​https://github.com/osxfuse/osxfuse/releases, Catalina support is available since 3.10.0, while the one in MacPorts is kept at 3.8.x as osxfuse is no longer an open source project since version 3.9.0 (1).

(1) ​https://github.com/osxfuse/osxfuse/issues/590.

This does not seem to be a valid justification to avoid updating the port in MacPorts. On Mavericks and later, we already download and install the signed binary from the developer, and don't build from source. There's no reason why we can't update to the latest version and continue to do that for Mavericks and later (or whatever minimum OS versions the latest release supports) and change the license to "Restrictive", while perhaps continuing to use the older BSD/APSL-licensed release for older macOS versions if needed.

[mike-kfed (Michael Kefeder)]

I found a mailinglist post with a hint how to fix the build

1. run port install osxfuse (it will fail)
2. open the file build.d/defaults.sh in your temporary build-dir e.g. sudo vim /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-48bc246//build.d/defaults.sh

3. copy the 10.14 declarations and change to 10.15

   declare -ra DEFAULT_SDK_10_15_ARCHITECURES=("i386" "x86_64")
   declare -r  DEFAULT_SDK_10_15_COMPILER="com.apple.compilers.llvm.clang.1_0"
   
   declare -ra DEFAULT_SDK_SUPPORTED=("10.9" "10.10" "10.11" "10.12" "10.13" "10.15")
   

4. save the file and
5. run port install osxfuse again

[mike-kfed (Michael Kefeder)]

Replying to mike-kfed: side note: I only needed it to install at all to build encfs (to have headers and stuff of osxfuse on my system). I uninstalled macports osxfuse and used their v3.10 binary provided at ​https://osxfuse.github.io/ for my catalina system. macports should provide a osxfuse-3.10 port

[tsjk (Tamas Jantvik)]

On 10.15.4 with XCode 11.4, not only did I need to change defaults.sh, add

declare -ra DEFAULT_SDK_10_15_ARCHITECURES=("x86_64")
declare -r  DEFAULT_SDK_10_15_COMPILER="com.apple.compilers.llvm.clang.1_0"

and change to

declare -ra DEFAULT_SDK_SUPPORTED=("10.9" "10.10" "10.11" "10.12" "10.13" "10.14" "10.15")

I also had to patch /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-48bc246/build.d/lib/xcode.sh

line 93: sdk_version="`DEVELOPER_DIR="${xcode_path}" xcodebuild -version -sdk ${sdk_name} SDKVersion 2>&4`"

to drop the minor version output for sdk version, so it becomes sdk_version="`DEVELOPER_DIR="${xcode_path}" xcodebuild -version -sdk ${sdk_name} SDKVersion 2>&4 | cut -d'.' -f1-2`"

After these changes it installed successfully.

[tsjk (Tamas Jantvik)]

I thought I was done, but to actually get it to work I also had to:

( cd "/opt/local/Library/Filesystems/osxfuse.fs/Contents/Extensions" && { [[ -d "10.15" ]] || sudo ln -sv "10.11" "10.15"; } ) && \
( cd "/Library/Extensions" && { [[ -d "osxfuse.kext" ]] || sudo ln -sv "/opt/local/Library/Filesystems/osxfuse.fs/Contents/Extensions/10.15/osxfuse.kext"; } ) && \
sudo kextcache -update-volume /

I guess the build/install scripts could be fixed to do that. After all this it seems to work. My use cases are rar2fs and encfs-devel (from github.com:tsjk/macports), which both work.

[d7gonzo (Ryan E. Johnson)]

I can confirm that the fix reported by tsjk in comment 25 fixes the compilation error. The follow-up posted in comment 26 does not appear necessary for me to use osxfuse for my purposes with the testdisk port.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #60460.

[someuser12]

I can confirm that the fix reported by tsjk in comments 25 and 26 works for me. For my purpose (the sshfs port), the first of the two symbolic links in comment 26 was necessary.

[ballapete (Peter "Pete" Dyballa)]

Diff output to patch build.d/defaults.sh to work on Catalina, macOS 10.15.6

[ballapete (Peter "Pete" Dyballa)]

Diff output to patch build.d/lib/xcode.sh to work on Catalina, macOS 10.15.6

[ballapete (Peter "Pete" Dyballa)]

I am not completely understanding Xcode. The build ends here:

RegisterExecutionPolicyException /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/framework/OSXFUSE.framework (in target 'OSXFUSE' from project 'OSXFUSE')
    cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-48bc246/framework
    builtin-RegisterExecutionPolicyException /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/framework/OSXFUSE.framework

Touch /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/framework/OSXFUSE.framework (in target 'OSXFUSE' from project 'OSXFUSE')
    cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-48bc246/framework
    /usr/bin/touch -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/framework/OSXFUSE.framework

** BUILD SUCCEEDED **

T:framework          | ^[[mCompleted action build^[[0m
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-48bc246/build.d/targets/packagemanager.sh: line 148: -bINSTALL_PATH=/opt/local/Library/Frameworks: No such file or directory
T:framework          | ^[[mSource target framework^[[0m
T:framework          | ^[[mInvoke action install^[[0m

I presume the text "INSTALL_PATH=" should be a SPACE character…

[ballapete (Peter "Pete" Dyballa)]

Corrected version of diff output to patch build.d/targets/release.sh to work on Catalina, macOS 10.15.6

[ballapete (Peter "Pete" Dyballa)]

By adding to the post-extract clause the line

system -W ${workpath}/pkg/Core.pkg/Library/Filesystems/osxfuse.fs/Contents/Extensions "ln -s 10.11 ${workpath}/pkg/Core.pkg/Library/Filesystems/osxfuse.fs/Contents/Extensions/10.15"

a missing sym-link is created. This can also be corrected by updating the osxfuse-3.8.3.dmg archive. It's a bit old and not prepared for Catalina. The missing sym-link

/Library/Extensions/osxfuse.kext -> /opt/local/Library/Filesystems/osxfuse.fs/Contents/Extensions/10.15/osxfuse.kext

obviously cannot be created by port because it lies outside /opt.

[ylluminarious (George Plymale II)]

Replying to ballapete:

I tried your patches for macOS 10.15.6 and none of them have worked for me on 10.15.7.

Have you updated them for the new 15.7 minor release? I'd like to be able to upgrade osxfuse if possible. Also, does anyone know when this issue might get fixed?

[ballapete (Peter "Pete" Dyballa)]

Replying to ylluminarious:

Have you updated them for the new 15.7 minor release? I'd like to be able to upgrade osxfuse if possible. Also, does anyone know when this issue might get fixed?

That's bad! Last weekend I upgraded to Big Sur – and here I am fighting to get a TeX Live without old Python 2.7 and without old Perl 5.28.

[kencu (Ken)]

This is all to be expected.

For a workflow-important system, you might wait three or six months to update to a new OS version.

My Ubuntu systems don't even show a new upgrade to LTS users who don't go looking for it until three months has gone by.

[doeringudh]

I got it to work on macOS 10.15.7. The root cause for the breakage seems to be the release of Xcode 12.3. It introduces SDK 11.1, the version for Big Sur, I presume, and this one is now the default SDK even on Catalina. Besides the usual changes in osxfuse for additional SDKs there is a change of semantics for the "PAGE_SIZE" C macro.

"PAGE_SIZE" is no longer a constant but instead points to a variable now, so it cannot be used to initialize global variables any more. The compiler error message hints at this, and I found the definition in "/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/mach/i386/vm_param.h". I opted for changing the code in osxfuse accordingly (if a little hacky), since I regard this as more future-proof. Or one could also define the macro "__MAC_OS_X_VERSION_MIN_REQUIRED" to be lower than "101600" to get the old semantics.

Instead of adding more individual patch files to this thread and thereby increasing the confusion about what is needed and what isn't to get it working, I will add an attachment with the complete modified port structure. Plug-and-Play. I set it up on my Mac as a local repo, according to these instructions: ​https://guide.macports.org/chunked/development.local-repositories.html. For the complete picture, make a recursive diff between the ports in the macports and the local repo. The only thing that still has to be done manually is creating the symlink in "/Library/Extensions".

[doeringudh]

Complete port structure for macOS 10.15.7

[kencu (Ken)]

the current release of osxfuse is 4.04. It is closed source now, so can't be built in MacPorts.

All users on current systems should uninstall MacPorts old osxfuse and go install the binary if they want a current fuse.

Whether there is a reason to keep this old fuse version around at all for older systems is unclear.

[doeringudh]

All good and well, but before all other ports depending directly on the "osxfuse" port (e.g. "encfs") instead of the presence of the respective shared library get reworked, installing the proprietary version is not enough. The scope of my patch is to only fix the breakage that macOS 10.15.7, or rather Xcode 12.3, have caused. Everything else is up to the official macports maintainers.

[kencu (Ken)]

There are no official macports maintainers for osxfuse any more -- the port is now abandoned.

I see there are a number of modules that depend on osxfuse. This is an issue now. Assuming those modules are still useful, we would have to -- most likely -- come up with a binary-only install of osxfuse like homebrew did, and install that to support those ports.

I don't use osxfuse much -- ideally someone who did would take this project up -- but in the absence of anyone stepping forward, making a port that installs the binary is usually not too hard.

[doeringudh]

I myself certainly do not have the time to officially take over the maintainership of this port. I am not a macOS developer. Professionally, I am rooted in the UNIX/Linux server realm. Close enough, but still not the same. However, if someone could point me to another port where such a binary-only install gets done already, I might be able to adapt it, without first having to wade through MacPorts' port building documentation, and contribute it once.

[ra1nb0w]

doeringudh maybe you see this port ​https://github.com/macports/macports-ports/blob/master/science/SDRplay3/Portfile

[ylluminarious (George Plymale II)]

Has anyone made any progress on this? Not trying to sound antsy, just wondering. I use the testdisk port and it relies on a working osxfuse port. This port seems to be rather abandoned at this point, so I've made a convenience alias which always skips upgrading osxfuse or its dependents during every upgrade that I run, but this feels increasingly brittle. It would be nice if someone was able to actually fix the underlying problem here, or could at least recommend another solution such that I can still use testdisk without having to install the Homebrew package instead.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #62226 and #63820.

It would be nice if someone was able to actually fix the underlying problem here

Yes, it would. MacPorts is a volunteer project. Anyone may volunteer to take ownership of an issue or a port and submit fixes. Pull requests are the best way to do so.

[czo]

Testdisk, ntfs-3g and sshfs still works for me under 12.0.1 without any macports related macfuse installation. To compile things which are depending on macfuse simply install the binary macFUSE distribution (which are still contains the files for development too) and simply create a symlink from the binary installed pkgconfig file (/usr/local/lib/pkgconfig/fuse.pc) to the macports dependent/checked file (/opt/local/lib/pkgconfig/fuse.pc). The path of the files can be differ depending on the installation.

All of the port which are i tried will be happy when fuse.pc can be found in the right place. (like the mentions comment #5​https://trac.macports.org/ticket/59316#comment:5)

[ra1nb0w]

This should be closed since there is macfuse that it is working fine on 10.15. right?