I don't see what you think is so complicated about this. Just use the 
supplied pkg-config file and define -D__DARWIN_64_BIT_INO_T=0 when 
compiling on Mac OS X.
Problem solved, and it'll build on all supported Mac OS X versions. :) 
Maybe the definition should be in the .pc file's cflags... or maybe not. 
Either way adding this compile-time define to their makefile / autoconf 
setup shouldn't present any major challenge to anyone.

If you want to specifically take advantage of the 64-bit inode version 
of the library, then you have to move out of the safe haven of 
pkg-config and manually add -lfuse_ino64 and the necessary includes and 
defines, but as you're saying you don't care about that, I guess there's 
no real point in doing it as it also breaks compatibility with Mac OS X 
10.4.

- Erik

Archie Cobbs wrote 2009-10-20 22.41:
> OK, I admit I am confused about all this. My apologies for asking so 
> many questions.
>
> Here are the facts:
>
>    1. Yes, I expect Mac users to compile the software themselves. I
>       don't supply binaries for Macs (though someone else is free to
>       of course).
>    2. I want the software to compile and work on both Leopard and Snow
>       Leopard. That is, it will be compiled on one of these types of
>       Macs, and it needs to successfully function only on the machine
>       it was actually compiled on.
>    3. I don't care which version of the stat structure gets used.
>
> The other thread states:
>
> /If you're going to run your file system binary on both Leopard and 
> Snow Leopard, then you'll be compiling it with Leopard compatibility 
> anyway (-mmacosx-version-min=10.5). Otherwise, use the ino64 library.
> /
>
> From my reading of what you're saying, the "-mmacosx-version-min=10.5" 
> compile flag is only required when compiling a single binary that you 
> want to run on both Leopard and Snow Leopard... but this is not the 
> case with me (see #2).
>
> So I'm not exactly sure which case I fall into here. I guess: "use the 
> ino64 library". Well, then I have to hack fuse.pc because it says 
> "-lfuse" instead of "-lfuse_ino64". Or, not use pkg-config at all.
>
> I'm still curious why the contents of fuse.pc are (seemingly) 
> inconsistent. It seems like we need to change "-lfuse" to 
> "-lfuse_ino64" in there in the Snow Leopard version (or, alternately, 
> add " -D__DARWIN_64_BIT_INO_T=0"). I understand pkg-config has 
> limitations, and may not work for people who want something other than 
> what it defaults to, but at least what it does have in there should be 
> self-consistent, shouldn't it?
>
> Thanks,
> -Archie
>
> On Tue, Oct 20, 2009 at 12:21 PM, Amit Singh <[email protected] 
> <mailto:[email protected]>> wrote:
>
>
>     No, "customizing" (or "hacking") fuse.pc is not the right way to do
>     it. It's not necessary either.
>
>     What you're missing is the following: there are no 2 separate sets of
>     MacFUSE components for Leopard and Snow Leopard. It's a single set of
>     binaries that works on both versions of the OS.
>
>     On Leopard, you need to set certain flags to get the larger stat
>     structure. By default, you get the smaller stat structure. This is for
>     all cases and not just those involving MacFUSE.
>
>     On Snow Leopard, you need to set certain flags to get the smaller stat
>     structure. By default, you get the larger stat structure. This is for
>     all cases and not just those involving MacFUSE.
>
>     Most developers who use MacFUSE expect the following behavior:
>
>     1) If possible, there shouldn't be multiple sets of binaries of
>     MacFUSE for different OS versions.
>     2) If possible, they shouldn't have to provide multiple sets of
>     binaries of their own applications for different OS versions.
>
>     MacFUSE is doing the "right" thing for it to be compatible with both
>     Leopard and Snow Leopard while still giving the developer the choice
>     to use either the larger or the smaller stat structure.
>
>     First, you need to decide if you want your application to be Snow
>     Leopard only, or if you want it to also work on Leopard.
>
>     If you want it to be Leopard-compatible, you should use "-mmacosx-
>     version-min=10.5" in your compile-time flags. I already mentioned this
>     in the thread I pointed you to. Then, if you want to use the smaller
>     stat structure, you need to do nothing further. If you want to use the
>     larger stat structure, you need to specify -D__DARWIN_64_BIT_INO_T=1
>     and link against the ino64 library.
>
>     If you want your application to be Snow Leopard only, you need to deal
>     with the fact that MacFUSE is not Snow Leopard only. So you need to
>     explicitly link against the library variant (ino64) that will work on
>     Snow Leopard. You shouldn't specify the -mmacosx-version-min=10.5 flag
>     so you'll get the Snow Leopard version of the stat structure by
>     default.
>
>     By the way, you keep saying that your users will have to hack this and
>     work around that, etc. Are you requiring your *end users* to *compile*
>     your software (say, as opposed to providing them with precompiled
>     binaries)?
>
>     Amit
>
>     On Oct 20, 9:48 am, Archie Cobbs <[email protected]
>     <mailto:[email protected]>> wrote:
>     > Thanks. Indeed, I'd rather not guess.
>     >
>     > If what you're saying is true, then why doesn't the MacFUSE
>     installer put
>     > "-D__DARWIN_64_BIT_INO_T=1" in the "Cflags" line of fuse.pc? The
>     "-lfuse"
>     > and the lack of "-D__DARWIN_64_BIT_INO_T=1" in fuse.pc is
>     inconsistent, at
>     > least on Snow Leopard. On 10.4, it could use different settings
>     of course...
>     > maybe the installer is just not currently capable of customizing
>     fuse.pc?
>     > Seems like that wouldn't be hard.
>     >
>     > In any case, what I would like is a set of simple instructions for
>     > developers, e.g. "do this and MacFUSE will work". I admit I have
>     not done
>     > the necessary research to find these magic instructions, and
>     that as the
>     > developer it's my job to figure this stuff out.
>     >
>     > So I'm not complaining, just sighing :-)
>     >
>     > I have a documented workaround that I'm including with the
>     software so Mac
>     > users have a set of instructions that they can follow even if
>     it's not
>     > pretty (they have to hack fuse.pc). That's good enough for now.
>     >
>     > -Archie
>     >
>     >
>     >
>     >
>     >
>     > On Tue, Oct 20, 2009 at 9:48 AM, Erik Larsson <[email protected]
>     <mailto:[email protected]>> wrote:
>     >
>     > > Archie Cobbs wrote 2009-10-20 15.58:
>     > > > #3. If stuff doesn't work, edit
>     /usr/local/lib/pkgconfig/fuse.pc and
>     > > > change "-lfuse" to "-lfuse_ino64", then repeat step #2 and
>     rebuild
>     >
>     > > Instead of guessing between '-lfuse' and '-lfuse_ino64' you
>     could of
>     > > course explicitly define which version of struct stat you want
>     to use in
>     > > the program, and then simply link to the corresponding fuse
>     library.
>     >
>     > > If you open sys/stat.h, you'll see that if you define
>     > > __DARWIN_64_BIT_INO_T to 1 before including the header, you'll
>     get the
>     > > 64-bit inode version of struct stat (and so you can link with
>     > > -lfuse_ino64), and when you define __DARWIN_64_BIT_INO_T to 0,
>     you will
>     > > get the old stat structure with 32-bit inode numbers (and so
>     you can
>     > > link with -lfuse).
>     >
>     > > For compatibility with Mac OS X 10.4 you would need to use the
>     32-bit
>     > > inodes version.
>     >
>     > > Regards,
>     >
>     > > - Erik
>     >
>     > --
>     > Archie L. Cobbs
>
>
>
>
> -- 
> Archie L. Cobbs
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MacFUSE" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/macfuse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to