Re: [Acl-devel] [PATCH] Switch to sys/xattr.h

[Cristian Rodríguez]

El mar 10 jun 2014 17:34:36 CLT, Andreas Grünbacher escribió:
> Christian,
>
> 2014-05-28 23:28 GMT+02:00 Cristian Rodríguez <address@hidden>:
>> Since a very long time (over ten years) the xattrs functions
>> that libacl uses have been provided by libc.
>> This commit switches the code to use libc and leave libxattr
>> behind.
>
> Well, instead, the syscall stubs really should be removed from libattr.

I have a patch to do that as well.. I posted this one first...I have it 
in two forms

a) It keeps the syscall stubs in libattr but only available in ATTR_1.0 
so existing binaries keep working.
   but it is no longer present in the default version, just like glibc 
does.. This only works for shared libraries.

b) Removing them all together, would require bumping the library 
version and all applications will require recompilation/relinking.

What form do you prefer ?

> In addition, to get rid of attr/xattr.h, we really need to get the
> ENOATTR == ENODATA alias into glibc. (Similar aliases like
> EWOULDBLOCK == EAGAIN and EDEADLOCK == EDEADLK
> exist already.)
>

Do you know why it was never added ?

> Huh? We cannot simply duplicate the header, it's part of the public interface
> of perm_copy_{fd,file}(). Also, we would end up with a duplicate definition of
> the same struct in libattr and libacl.

Ouch... at the first read that didn't compute in my head.. now that I 
look it again, you are right, error_context will become an unknown type 
...


>> +libacl_la_LDFLAGS = -no-undefined \
>>         -Wl,--version-script,$(top_srcdir)/exports \
>>         -version-info $(LTVERSION)
>
> Why is this needed?

Because gcc alllows undefined symbols in shared libraries by 
default..this is not the behaviour we want..we need a build failure 
instead.



--
Cristian
"I don't know the key to success, but the key to failure is trying to 
please everybody."