Tiger PPC fuse_operations struct size mismatch

[GoogleCodeExporter]

1) Take hello world file system.
2) Before #include <fuse.h>, add 
#define __FreeBSD__ 10
3) compile with gcc -arch ppc -mmacosx-version-min=10.4
4) run exe on Tiger (10.4) powerpc system

expected output: nothing, hello.txt readable from mount point

actual output: fuse: warning: library too old, some operations may not not
work, random errors, including grey screens

Original issue reported on code.google.com by rfistman@gmail.com on 19 Oct 2008 at 4:00

[GoogleCodeExporter]

Compiled and linked versions are both 2.7.

Hello world compiled on Intel Leopard.

Intel version does not complain if I define __FreeBSD__=10.

Original comment by rfistman@gmail.com on 19 Oct 2008 at 4:04

[GoogleCodeExporter]

First off, __FreeBSD__=10 isn't optional. If you are manually compiling 
something MacFUSE-based, you *have* to have that in 
your CFLAGS. Note how the hello.c file itself says it should be compiled:

/* gcc -Wall `pkg-config fuse --cflags --libs` hello.c -o hello */

This works because pkg-config fuse --cflags will give you:

-D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64 -I/usr/local/include/fuse

Now, as to the other things you're saying:

* Which specific MacFUSE version (2.7 is not the MacFUSE version--it's merely 
the user-space library's version) is installed on 
your Intel Leopard Machine?

* Which MacFUSE version is installed on Tiger PowerPC?

* When you say "Intel version does not complain", do you mean it's an Intel 
binary or do you mean it's a PowerPC binary you 
compiled on the Intel machine?

Original comment by si...@gmail.com on 19 Oct 2008 at 6:56

[GoogleCodeExporter]

* The Intel Leopard machine has MacFUSE version 1.7 (the DMG released June 30, 
2008)

* Idem for the PowerPC Tiger machine. 

* The non-complaining Intel version is an Intel binary
  compiled and run on the Intel Leopard machine.

Original comment by rfistman@gmail.com on 19 Oct 2008 at 7:11

[GoogleCodeExporter]

Sorry, my mistake, all machines are running MacFUSE 1.7.1.

Original comment by rfistman@gmail.com on 19 Oct 2008 at 7:32

[GoogleCodeExporter]

> Sorry, my mistake, all machines are running MacFUSE 1.7.1.

That's not possible. MacFUSE versioning is explained here: 
http://code.google.com/p/macfuse/wiki/MACFUSE_VERSIONING. 1.7.1 would be the 
MacFUSE version on Leopard. The equivalent Tiger version would be 1.7.0.

Anyway, can you try the latest developer release and see if it works better for 
you? See the last section of http://code.google.com/p/macfuse/wiki/AUTOINSTALL 
to know how to enable developer releases. What you're seeing might be a 
transitional issue 
in MacFUSE-1.7.

Original comment by si...@gmail.com on 20 Oct 2008 at 11:13

[GoogleCodeExporter]

Also, what do you mean by "random errors, including grey screens"?

The warning message "library too old, some operations may not not work" will be 
there, I can see that. However, 
this is a benign warning. Things should still work. I just did a test and a 
binary compiled on Leopard/MacFUSE-
1.7.1 does work (with the warning message) on Tiger/MacFUSE-1.7.0.

Can you give examples of the random error you're talking about? What's a "grey 
screen"?

Original comment by si...@gmail.com on 20 Oct 2008 at 11:26

[GoogleCodeExporter]

This is really embarassing. I just doubled checked the machine
and it's not actually a PowerPC, it's an Intel. I was feeding
it PowerPC binaries, and so this is just another manifestation
of the Rosetta non-support. 

However non-support and crashing (see issue 390) are two
different things. Any chance of a graceful exit if someone
accidently makes a cross arch call to MacFUSE? In the meantime
I'll add a "No Rosetta, thanks" check to my MacFUSE init code. 

I'm not sure how a library is supposed to tell if it's being
called from an emulated app but I imagine that first byteswapped
opcode would be a pretty good hint.

Anyway, sorry!

Original comment by rfistman@gmail.com on 21 Oct 2008 at 12:22

[GoogleCodeExporter]

Rosetta doesn't work with MacFUSE, but fat binaries do. Rather than adding a 
"No Rosetta, thanks", why wouldn't 
you just build your application fat?

Original comment by si...@gmail.com on 21 Oct 2008 at 12:27

• Changed state: Invalid

[GoogleCodeExporter]

The random errors were segfaults, messages about
disconnected sockets and a dialog box saying that
the a fuse volume I had never seen wasn't responding
and did I want to eject (sorry, going from vague memory). 

A grey screen is the mac version of the blue screen of death.
It's a kernel panic, I think. A bad situation.

Anyway, this is what happens to me when I accidentally call
MacFUSE from Rosetta emulation. It's a confusing situation,
because I think the Rosetta emulated app links directly to
the PowerPC part of the libfuse dylib, but that talks to
an Intel kext. However, an error message would be way preferable
to kernel panics.

Original comment by rfistman@gmail.com on 21 Oct 2008 at 12:31

[GoogleCodeExporter]

My applications are fat.

Let me start anew.

1) My Intel app DID give the size mismatch error (MacFUSE 1.7.1)

2) In a misguided attempt to give a concise bug report
   I accidently built a PowerPC helloworld fuse fs which
   exhibited my problem and many more.

3) The latest developer release (1.9.2? 1.9.1?) fixed the original problem 
(THANKS!)

So, in reality, no problems. Any ETA on the next stable release?

Ta,
RF.

Original comment by rfistman@gmail.com on 21 Oct 2008 at 12:35

[GoogleCodeExporter]

Final update: the intel app on tiger was, of course, MacFUSE 1.7.0.

I'm tired. Sorry about the runaround.

Original comment by rfistman@gmail.com on 21 Oct 2008 at 12:36

[GoogleCodeExporter]

> 1) My Intel app DID give the size mismatch error (MacFUSE 1.7.1)

As I said earlier, that's not an error, but a benign warning. It should still 
work.

> 2) In a misguided attempt to give a concise bug report
>    I accidently built a PowerPC helloworld fuse fs which
>   exhibited my problem and many more.

Since Rosetta doesn't work at all with MacFUSE, the specific problems don't 
matter. Well, like you said, it should still not panic the 
kernel. I'm not aware of a failed attempt to run a MacFUSE application under 
Rosetta causing a kernel panic. It should fail on the very 
first operation (init) and wouldn't even finish mounting. After that, the 
user-space file system should "hang". You can kill it or ctrl-c 
it. Can you reproduce an actual kernel panic this way? If so, can you post how 
to do that?

> 3) The latest developer release (1.9.2? 1.9.1?) fixed the original problem 
(THANKS!)

It's 1.9.15 as of this writing. You can run 
/Library/Filesystems/fusefs.fs/Support/autoinstall-macfuse-core -p to see.

Original comment by si...@gmail.com on 21 Oct 2008 at 1:54