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 -~----------~----~----~----~------~----~------~--~---
