I don't agree. Changing to a 64-bit inode version by default would possibly break (badly written) existing file systems that make assumptions about the size of the inode number, and would produce less portable binaries (for those of us that do care about binary compatibility with multiple Mac OS X versions).
It would be better to have a consistent default behaviour across multiple Mac OS X versions, and let the 64-bit inodes be opt-in. - Erik Archie Cobbs wrote: > Yes, that will work. My point is not that no solution/workaround > exists, it's that the whole point of pkg-config is that IF you are not > doing anything fancy (I am not) then getting your CFLAGS and LDFLAGS > from pkg-config should work. It doesn't. The fix is to change the > "-lfuse" to "-lfuse_ino64" on Snow Leopard. > > Thanks, > -Archie > > On Oct 20, 11:20 pm, Erik Larsson <[email protected]> wrote: > >> 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 wrote2009-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 wrote2009-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 -~----------~----~----~----~------~----~------~--~---
