Making rsync compile under Mac OS X 10.3.9 with extended attributes

[Vitorio Machado]

Normally all the infos to correctly setup gcc with carbon should be  
here:
http://developer.apple.com/documentation/MacOSX/Conceptual/ 
BPFrameworks/Tasks/IncludingFrameworks.html
I'll carefully read it tomorrow... By now I need some sleep ;)
Good night folks!

Le 13 févr. 08, à 22:13, LaG' a écrit :

> Hello,
>
> Today I worked on a real 10.3 mac. I'm attaching a patch based on  
> rsync 3.0.0pre9 with flags and crtimes patches. I hope I did it right,  
> I used this command:
> diff -rPC2 ../rsync-3.0.0pre9/ .>../patch2.diff
>
> So, from 3.0.0pre9 this patch includes the work on my server (  
> http://shared.and.free.fr ), Matt modifications from yesterday and  
> from today:
>
> 1) Patched ACL configure.in (don't know if I did it the right way) to  
> don't say it can use ACL on a Panther system.
> Changed
> !     darwin*)
> to
> !     darwin[[0-38-9]].*)
> So on PreTiger systems it doesn't set ACL by default. The system  
> doesn't handle it anyway. From ./configure:
> before:
> checking sys/acl.h usability... no
> checking sys/acl.h presence... no
> checking for sys/acl.h... no
> checking acl/libacl.h usability... no
> checking acl/libacl.h presence... no
> checking for acl/libacl.h... no
> checking for _acl... no
> checking for __acl... no
> checking for _facl... no
> checking for __facl... no
> checking whether to support ACLs... Using OS X ACLs
>
> after patching:
> checking sys/acl.h usability... no
> checking sys/acl.h presence... no
> checking for sys/acl.h... no
> checking acl/libacl.h usability... no
> checking acl/libacl.h presence... no
> checking for acl/libacl.h... no
> checking for _acl... no
> checking for __acl... no
> checking for _facl... no
> checking for __facl... no
> checking whether to support ACLs... running tests:
> checking for acl_get_file in -lacl... no
> checking for ACL support... no
> checking ACL test results... No ACL support found
>
> I think maybe the patch should be corrected to don't even go into the  
> cases if it doesn't find the headers it expects, but this goes beyond  
> my knowledge.
>
> 2) Matt: I put * instead of 3.9 to try to make the option work on  
> pre-Tiger systems other than 10.3.9.
> Unfortunately this doesn't works:
> gcc -std=gnu99 -I. -I. -I  
> /Developer/SDKs/MacOSX10.*.sdk/Developer/Headers/CFMCarbon/ -g -O2  
> -DHAVE_CONFIG_H -Wall -W -I./popt  -c lib/sysxattrs.c -o  
> lib/sysxattrs.o
> gcc: cannot specify -o with -c or -S and multiple compilations
> make: *** [lib/sysxattrs.o] Error 1
>
> So I reverted the path, but this will also have to change because the  
> inclusion isn't good (see next point).
>
> 3) We still have a conflict between Carbon inclusion and other  
> headers. I'm starting to google around, and already found some people  
> that has the same problem. With some luck they already found a  
> solution. The conflicts look like this:
>
> gcc -std=gnu99 -I. -I. -I  
> /Developer/SDKs/MacOSX10.3.0.sdk/Developer/Headers/CFMCarbon/ -g -O2  
> -DHAVE_CONFIG_H -Wall -W -I./popt  -c lib/sysxattrs.c -o  
> lib/sysxattrs.o
> In file included from rsync.h:236,
>                  from lib/sysxattrs.c:21:
> /usr/include/stdio.h:81: error: parse error before "fpos_t"
> /usr/include/stdio.h:143: error: parse error before "fpos_t"
> /usr/include/stdio.h:160: error: parse error before "_offset"
> /usr/include/stdio.h:164: error: parse error before "__sF"
>
> GCC finds errors on existing headers. Seems like same types are  
> defined twice or something like this. I'll now look here for  
> something:
> http://www.google.com/search?client=safari&rls=fr- 
> fr&q=framework+Carbon+header+conflict&ie=UTF-8&oe=UTF-8
> If you find a more relevant site/keywords, please share it :)
>
> PS: Thanks for the strncpy correction.
>
> Vitorio
>
> Le 13 févr. 08, à 03:26, Matt McCutchen a écrit :
>
>> On Tue, 2008-02-12 at 15:24 +0100, Vitorio Machado wrote:
>>> I'm trying to figure out how to modify the makefile to say to compile
>>> sysxattrs.c with the -I /Developer/SDKs/MacOSX10.3.9.sdk/Developer/
>>> Headers/CFMCarbon/
>>> in the case of HAVE_PRE_TIGER_OSX_ATTRS is true.
>>> Is somebody skilled on makefile to give me some help?
>>
>> I did some work on top of your rsync10.3xattr_support080211 files.  I
>> added code to configure.in and Makefile.in that should get the
>> appropriate -I option passed for lib/sysxattrs.c in the case of
>> HAVE_PRE_TIGER_OSX_ATTRS.  You can modify the option in configure.in  
>> if
>> necessary.  I put * instead of 3.9 to try to make the option work on
>> pre-Tiger systems other than 10.3.9.
>>
>> I also think I figured out why the configure script was refusing to
>> enable HAVE_PRE_TIGER_OSX_ATTRS.  First, every time you change
>> configure.in, you need to run "autoconf -o configure.sh" to update
>> configure.sh (the underlying configure script for which ./configure  
>> is a
>> simple wrapper).  The ./configure wrapper will invoke autoconf to
>> generate configure.sh if it doesn't exist, but once it exists, you  
>> have
>> to regenerate it yourself as necessary.  Second, the [] characters in
>> "darwin[4-7]*" in configure.in are recognized by autoconf as quoting
>> characters and stripped out, so configure.sh says "darwin4-7*" , which
>> obviously won't match.  I changed configure.in to say  
>> "darwin[[4-7]]*" ;
>> autoconf strips only the outer pair to leave the desired  
>> "darwin[4-7]*"
>> in configure.sh.
>>
>> I also neatened up the code in other places and finished your strncpy
>> call.  A patch with my proposed changes on top of your files is
>> attached.
>>
>> Matt
>> <rsync10.3xattr_support.matt20080212.diff>
>
>  --
> To unsubscribe or change options:  
> https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read:  
> http://www.catb.org/~esr/faqs/smart-questions.html