New formulas: fuse4x and fuse4x-kext #7371

afds · 2011-09-01T19:30:48Z

Potential fix for issue #6185

Sharpie · 2011-09-02T20:22:58Z

Library/Formula/fuse4x-kext.rb

+  def caveats
+    <<-EOS.undent
+      Install kernel extension to the system:
+      sudo cp -rfX #{prefix}/fuse4x.kext /System/Library/Extensions


Perhaps we should suggest /Library/Extensions instead? That is where VirtualBox places it's stuff and it keeps /System/Library/Extensions untouched---so only things provided by Apple live there.

Ahh. Never mind, seems /System/Library/Extensions is the only folder OS X will check during boot:

http://daringfireball.net/2003/08/the_one_and_only_mac_os_x_extensions_folder

/Library/Extensions is commonly used for extensions that specific Applications load when they start up.

Sharpie · 2011-09-02T21:30:56Z

Looking good, was able to compile and use SSHFS from:

https://github.com/fuse4x/sshfs

The only change I might consider is merging fuse4x-kext into fuse4x as a sub-formula---unless there is a reason someone would want to install one without the other.

@mxcl @adamv @MikeMcQuaid @jacknagel

I don't think we've done a kernel extension before---any thoughts or caveats we should add?

MikeMcQuaid · 2011-09-02T22:36:57Z

Presumably it's just a matter if copying the file to the right location?

Sharpie · 2011-09-02T22:58:47Z

Yeah, just the user following a caveat that they need to sudo-copy the .kext to /System/Library/Extension. I guess the only additional issue that sets kernel extensions apart from launchd scripts is that the realm of possible bugs is expanded to include kernel panics.

But that's the risk you take.

Sharpie · 2011-09-02T23:26:07Z

Also looks like it the MacPorts guys have rigged things so that the kernel extension is auto-loaded by the library:

https://trac.macports.org/browser/trunk/dports/fuse/fuse4x-kext/Portfile

We may want to look into that instead of copying to /System/Library/Extension---easier to un-install.

afds · 2011-09-03T05:44:33Z

To load the kernel extension it must be chowned by root, so we can't simply leave fuse4x.kext somewhere under #{HOMEBREW_PREFIX}. The macport guys give load_fuse4x utility a setuid bit; that utility helps to load the kernel extension. When the kernel extension is not under /System, the loading is possible only for root.

man kextload provides following information:

The kextload program is used to explicitly load kernel extensions (kexts). For most kexts, kextload must run as the superuser (root). Kexts installed under /System/ with an OSBundleAllowUserLoad property set to true may be loaded via kextload by non-root users.

So, if we want to put fuse4x.kext into /Library/Extension we need to issue two sudo commands: one for copying and one to setup setuid on load_kext4x.

Regarding definition of a fuse4x-kext as a sub-formula, well, I've not used sub-formulas before, what if fuse4x-kext gets updated, but fuse4x not? When we have two formulas, it is clear, that only one needs to be updated.

Sharpie · 2011-09-03T16:29:10Z

To load the kernel extension it must be chowned by root, so we can't simply leave fuse4x.kext somewhere under #{HOMEBREW_PREFIX}. The macport guys give load_fuse4x utility a setuid bit; that utility helps to load the kernel extension. When the kernel extension is not under /System, the loading is possible only for root.

Allright, guess we'll just leave it alone and go with the caveat recommending a sudo-copy to /System/Library/Extensions. Chowning things in the keg to root will definitely break uninstallation.

Regarding definition of a fuse4x-kext as a sub-formula, well, I've not used sub-formulas before, what if fuse4x-kext gets updated, but fuse4x not? When we have two formulas, it is clear, that only one needs to be updated.

It looks like the version number of both formulae are locked together---but it is totally conceivable that they may drift apart due to a hotfix in one or the other. I guess keeping them separate does make it easier to hack on one of the components while leaving the other alone---which is a good thing. I suppose my main concern is that fuse4x-kext gets installed first which means that the caveat explaining how to activate it can get pushed out of the way by the installation of fuse4x and users won't see it. I would add a caveat to fuse4x that reminds users to run brew info fuse4x-kext and follow the instructions there.

Last issue that pops up in my mind:

The MacPorts portfile makes some substitutions that change the name of the library from libfuse4x to just libfuse. This makes sense as the library is called libfuse on Linux and most FUSE-based applications will be expecting it to be called libfuse. Since we don't have a formula for MacFUSE, I think it may be a good idea to go with the same substitution to reduce the amount of patching that would have to be done to other software. We can do similar substitutions using inreplace.

@anatol

It would be great if there was a configure argument that controlled the naming of the library.

afds · 2011-09-03T17:47:55Z

The MacPorts portfile makes some substitutions that change the name of the library from libfuse4x to just libfuse. This makes sense as the library is called libfuse on Linux and most FUSE-based applications will be expecting it to be called libfuse. Since we don't have a formula for MacFUSE, I think it may be a good idea to go with the same substitution to reduce the amount of patching that would have to be done to other software. We can do similar substitutions using inreplace.

Sounds good, but I'm not sure about it. Some points:

MacFUSE libraries are whitelisted in homebrew.
Before installation we need to check that no MacFUSE is installed.
There are about 4 formulas in the homebrew that reference MacFUSE in caveat: djmount, encfs, ifuse, s3-backer. We need to change caveat in these formulas, so that either MacFUSE or fuse4x must be installed.

adamv · 2011-09-03T17:51:44Z

Remember that various versions of VMWare Fusion will install FUSE libraries directly into /usr/local, hence the whitelisting.

Sharpie · 2011-09-03T17:55:49Z

Remember that various versions of VMWare Fusion will install FUSE libraries directly into /usr/local, hence the whitelisting.

Hrm. Well that's nice of them. Perhaps we should stick with libfuse4x then. Either way, something will need to be done about the formulae that depend on MacFUSE as they currently won't work on anything running a 64 bit kernel.

afds · 2011-09-03T18:17:28Z

@Sharpie I already made a change for encfs formula, but it is out of this pull request. You could check it here.

Sharpie · 2011-09-03T18:23:59Z

Allright, I guess I will merge this as-is with a few caveat modifications---it will require changes to other formulae but it also avoids stepping on other people's toes which is a good thing. Thanks for your hard work and patience!

Sharpie · 2011-09-03T20:06:10Z

I'm getting a build failure on 10.5.8 with XCode 3.1.4 even though this post suggests that fuse4x supports Leopard since 0.8.7:

https://groups.google.com/forum/#!topic/fuse4x/vUVA0mstyi4

I tried restricting it to a single-architecture install by passing ARCHS=i386 ONLY_ACTIVE_ARCH=NO to xcodebuild but it also failed.

Full build logs here:

https://gist.github.com/1191673/eb276ef1feb5a1776e9521af6ddc2efcc78c2045

mxcl · 2011-09-04T11:17:19Z

If I understand things correctly. You can chown things to root, as long as another user owns that directory the file can still be deleted.

cd ~
sudo touch foo
rm -f foo

afds · 2011-09-05T05:39:53Z

@mxcl True, but it does not work with homebrew

$ sudo chown -R root:wheel /usr/local/Cellar/fuse4x-kext/0.8.11/fuse4x.kext
$ brew uninstall -vd fuse4x-kext
Uninstalling /usr/local/Cellar/fuse4x-kext/0.8.11...
Error: Operation not permitted - /usr/local/Cellar/fuse4x-kext/0.8.11/fuse4x.kext
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1217:in `chmod'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1217:in `chmod'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:895:in `chmod_R'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:1325:in `traverse'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:893:in `chmod_R'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:892:in `each'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/fileutils.rb:892:in `chmod_R'
/usr/local/Library/Homebrew/extend/pathname.rb:90:in `chmod_R'
/usr/local/Library/Homebrew/keg.rb:21:in `uninstall'
/usr/local/Library/Homebrew/cmd/uninstall.rb:9:in `uninstall'
/usr/local/Library/Homebrew/cmd/uninstall.rb:6:in `each'
/usr/local/Library/Homebrew/cmd/uninstall.rb:6:in `uninstall'
/usr/local/bin/brew:82:in `send'
/usr/local/bin/brew:82

afds · 2011-09-05T05:43:51Z

@Sharpie Unfortunately I could not help you with build on 10.5.8. I asked @anatol for support.

mxcl · 2011-09-05T08:41:18Z

We can fix that with a force remove if it will improve things.

afds · 2011-09-05T08:53:15Z

One more thing, fuse4x.kext is a directory, not a file.

~$ sudo mkdir foo
~$ sudo touch foo/bar
~$ rm -rf foo
rm: foo/bar: Permission denied
rm: foo: Directory not empty

anatol · 2011-09-05T16:33:20Z

@Sharpie the error says that it cannot build kernel extension for 64bit architecture. It looks like osx10.5 & the old xcode does not support compilation for 64bit kernels.

Could you please add "-arch i386" flag to xcode (line 12) and send me the output?

fuse4x should build/work fine on osx10.5. At least it builds on macports.

anatol · 2011-09-06T14:52:35Z

I tried restricting it to a single-architecture install by passing ARCHS=i386 ONLY_ACTIVE_ARCH=NO to xcodebuild but it also failed.

It failed on this line:

CopyStringsFile /tmp/homebrew-fuse4x-kext-0.8.11-oanO/build/Release/fuse4x.kext/Content==> Exit Status: 1

I believe that i386 build fine finished successfully but failed to copy this dir.

In any case 10.5 SDK does not support 64bit kernel and we should not try to build x86_64 architecture. There should be arch restriction something like

if MACOS_VERSION < "10.6" do
params += "-arch"
if ppc do
params += "ppc"
else
params += "i386"
end
end

Sharpie · 2011-09-06T15:36:10Z

@anatol

Sorry, some critical information got left out of the log for some reason. When installing with ARCHS=i386 ONLY_ACTIVE_ARCH=NO, the critical error was the following:

=== BUILDING NATIVE TARGET load_fuse4x OF PROJECT kext WITH CONFIGURATION Release ===

Checking Dependencies...
Invalid value 'com.apple.compilers.llvm.clang.1_0' for GCC_VERSION
Unable to determine concrete GCC compiler for file /tmp/homebrew-fuse4x-kext-0.8.11-3MD0/load_fuse4x.c of type sourcecode.c.c.

It appears that the default for "Compiler Version" in kext.xcodeproj is set to com.apple.compilers.llvm.clang.1_0---which means to use Clang. Clang is not included with XCode 3.1.4, the latest version available for Leopard, so the build falls over.

I was able to install the kext manually by opening the project in XCode, setting "Compiler Version" to "GCC System Version" and then running xcodebuild.

Do you know if there is a way to pass this information directly to xcodebuild without opening the XCode project?

anatol · 2011-09-06T16:23:26Z

@Sharpie Ah, good point. fuse4x should use the default compiler, not the custom one.

I have a fix in my private repo, I am testing it now. anatol/kext@892ec01 It should be available in the next fuse4x version (0.8.12).

Currently the only way is to remove "clang" from pbxproj file using inreplace.

Sharpie · 2011-09-06T16:48:27Z

@anatol

I am also having trouble compiling the fuse4x library on Leopard due to the way configure.in sets CFLAGS and LDFLAGS:

CFLAGS="$CFLAGS  -DUNNAMED_SEMAPHORES_NOT_SUPPORTED -D_POSIX_C_SOURCE=200112L -D__DARWIN_64_BIT_INO_T=1 -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5"
LDFLAGS="$LDFLAGS -arch i386 -arch x86_64 -framework CoreFoundation"

The problem is with -isysroot /Developer/SDKs/MacOSX10.6.sdk. This is not a good idea because:

Leopard users don't have the 10.6 SDK.
Not all users install XCode to /Developer.

After fixing configure.in, I am getting a compile error related to PAGE_SIZE:

https://gist.github.com/1191673/eb276ef1feb5a1776e9521af6ddc2efcc78c2045#file_fuse4x_lib_install.log

anatol · 2011-09-06T17:14:58Z

Hi

On Tue, Sep 6, 2011 at 9:48 AM, Sharpie <
reply@reply.github.com>wrote:

@anatol

I am also having trouble compiling the fuse4x library on Leopard due to the
way configure.in sets CFLAGS and LDFLAGS:
CFLAGS="$CFLAGS  -DUNNAMED_SEMAPHORES_NOT_SUPPORTED
-D_POSIX_C_SOURCE=200112L -D__DARWIN_64_BIT_INO_T=1 -arch i386 -arch x86_64
-isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5"
LDFLAGS="$LDFLAGS -arch i386 -arch x86_64 -framework CoreFoundation"
The problem is with -isysroot /Developer/SDKs/MacOSX10.6.sdk. This is not
a good idea because:

Leopard users don't have the 10.6 SDK.

Not all users install XCode to /Developer.

So what is the best choice? Just to remove isysroot flag from configure and
let xcode to find the best available SDK?

After fixing configure.in, I am getting a compile error related to
PAGE_SIZE:

It is weird. Could you please add "#include <machine/param.h>" to
the lib/mount_darwin.c and see if it helps.

https://gist.github.com/1191673#file_fuse4x_lib_install.log

Thanks for doing it!

Sharpie · 2011-09-06T18:30:36Z

So what is the best choice? Just to remove isysroot flag from configure and let xcode to find the best available SDK?

Yeah, I wouldn't force a particular isysroot on people---if they need it, they can pass it using CFLAGS.

It is weird. Could you please add "#include <machine/param.h>" to the lib/mount_darwin.c and see if it helps.

That didn't work. Adding #include <mach/vm_param.h> to include/fuse_param.h seems to have done the trick.

anatol · 2011-09-06T20:00:24Z

On Tue, Sep 6, 2011 at 11:30 AM, Sharpie <
reply@reply.github.com>wrote:

So what is the best choice? Just to remove isysroot flag from configure
and let xcode to find the best available SDK?

Yeah, I wouldn't force a particular isysroot on people---if they need it,
they can pass it using CFLAGS.

Ok, it will be in the official repo sson.

It is weird. Could you please add "#include <machine/param.h>" to the
lib/mount_darwin.c and see if it helps.

That didn't work. Adding #include <mach/vm_param.h> to
include/fuse_param.h seems to have done the trick.

That file already includes "#include <sys/vmparam.h>" I assumed that it
includes <mach/vm_param.h> transiently. It seems not true on 10.5. Anyway I
am going to replace <sys/vmparam> with <mach/vm_param.h>.

Reply to this email directly or view it on GitHub:
#7371 (comment)

Sharpie · 2011-09-06T20:51:38Z

Sounds good, let me know which patches need to be applied.

anatol · 2011-09-06T21:09:10Z

Hi

On Tue, Sep 6, 2011 at 1:51 PM, Charlie Sharpsteen <
reply@reply.github.com>wrote:

Sounds good, let me know which patches need to be applied.

Meanwhile you can try to build fuse4x from HEAD. I'll test it for day or two
and if there are any issues I'll tag it as 0.8.12.

https://github.com/fuse4x

anatol · 2011-09-06T23:48:23Z

While we are here I would like to discuss the library and *.pc names. I suggest to change it from libfuse4x to libfuse, the same way as macports does.

The reason why it worth doing is that most of the filesystems use "libfuse" name. If you apply changes as above then you don't need to change filesystems (similar to what afds did for encfs).

afds · 2011-09-07T06:35:05Z

@anatol We already discussed this, could you please check following items and tell us what do you think.

Start with this comment and follow 3 comments below.
Check this commit message.

anatol · 2011-09-07T18:42:27Z

@afds Personally I am in favor of using "libfuse", it is what most filesystems expect. And I like your idea where you said "install fuse4x if no macfuse installed".

If a user already installed some macfuse flavor (e.g Google,Tuxera, osxfuse or BrianPhams') then there is no reason to install one more (fuse4x). In this case Homebrew can just use installed macfuse flavor. Otherwise Homebrew should do the best possible thing - install fuse4x.

Sharpie · 2011-09-07T22:19:21Z

The other corner case to worry about are things like VMware Fusion installing a libfuse in /usr/local/lib---such installations are not guaranteed to come with header files that would make the library usable for building additional software. Plus, I'm not sure we want to support FUSE filesystems that will build against "some random libfuse we found in HOMEBREW_PREFIX". I guess there are two options:

Use the name libfuse and have the fuse4x formula abort with an error if HOMEBREW_PREFIX/lib/libfuse already exists.
Use the name libfuse4x and make sure that any formula depending on fuse4x as a FUSE implementation knows how to deal with the name change.

MikeMcQuaid · 2011-09-08T08:54:00Z

The second one feels more Homebrewy to me.

mxcl · 2011-09-08T08:58:08Z

You can get the Xcode prefix with: MacOS.xcode_prefix.

anatol · 2011-09-10T01:24:30Z

Hey,

I just pushed a new tag 0_8_12 to fuse4x project. This version contains fixes for issues discovered during working on the Homebrew formula. @Sharpie @afds please update formula and let me know if any other issues left.

Sharpie · 2011-09-11T03:23:29Z

@anatol

fuse4x/fuse4x@fuse4x_0_8_12 is still failing on Leopard due to PAGE_SIZE being undeclared. This is because include/fuse_param.h is using machine/param.h instead of mach/vm_param.h.

anatol · 2011-09-12T01:23:25Z

Do'h, I pushed a wrong commit as a tag. I repushed the correct tag. Please test it once again... Sorry about that.

Sharpie · 2011-09-12T03:41:25Z

Looks good. Adding to master.

Thanks to everyone for the hard work and input!

anatol · 2011-09-12T03:47:21Z

Thank to all of you for doing this.

In case if you'll see any issues with fuse4x, fuse4x-kext do not hesitate to contact me.

Provides libraries required to build and run programs that use FUSE filesystems. Note that this formula installs `libfuse4x` instead of the traditional `libfuse` in order to avoid clashing with MacFUSE and other `libfuse` distributions---such as the one bundled with VMWare Fusion. Configure scripts for software expecting to link against `libfuse` will need to be modified accordingly. Closes Homebrew#7371. Closes Homebrew#6185. Signed-off-by: Charlie Sharpsteen <source@sharpsteen.net>

afds added 2 commits September 1, 2011 13:56

New formula: fuse4x 0.8.11

30b8042

New formula: fuse4x-kext 0.8.11

fd8a951

Sharpie reviewed Sep 2, 2011
View reviewed changes

Sharpie closed this in 6748b16 Sep 12, 2011

Homebrew locked and limited conversation to collaborators Feb 16, 2016

New formulas: fuse4x and fuse4x-kext #7371

New formulas: fuse4x and fuse4x-kext #7371

Conversation

afds commented Sep 1, 2011

Sharpie Sep 2, 2011

Choose a reason for hiding this comment

Sharpie Sep 2, 2011

Choose a reason for hiding this comment

Sharpie commented Sep 2, 2011

MikeMcQuaid commented Sep 2, 2011

Sharpie commented Sep 2, 2011

Sharpie commented Sep 2, 2011

afds commented Sep 3, 2011

Sharpie commented Sep 3, 2011

afds commented Sep 3, 2011

adamv commented Sep 3, 2011

Sharpie commented Sep 3, 2011

afds commented Sep 3, 2011

Sharpie commented Sep 3, 2011

Sharpie commented Sep 3, 2011

mxcl commented Sep 4, 2011

afds commented Sep 5, 2011

afds commented Sep 5, 2011

mxcl commented Sep 5, 2011

afds commented Sep 5, 2011

anatol commented Sep 5, 2011

anatol commented Sep 6, 2011

Sharpie commented Sep 6, 2011

anatol commented Sep 6, 2011

Sharpie commented Sep 6, 2011

anatol commented Sep 6, 2011

Sharpie commented Sep 6, 2011

anatol commented Sep 6, 2011

Sharpie commented Sep 6, 2011

anatol commented Sep 6, 2011

anatol commented Sep 6, 2011

afds commented Sep 7, 2011

anatol commented Sep 7, 2011

Sharpie commented Sep 7, 2011

MikeMcQuaid commented Sep 8, 2011

mxcl commented Sep 8, 2011

anatol commented Sep 10, 2011

Sharpie commented Sep 11, 2011

anatol commented Sep 12, 2011

Sharpie commented Sep 12, 2011

anatol commented Sep 12, 2011