acl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Grünbacher
Subject: Re: [Acl-devel] [PATCH] Switch to sys/xattr.h
Date: Wed, 11 Jun 2014 00:27:21 +0200

Christian,

2014-06-11 0:13 GMT+02:00 Cristian Rodríguez <address@hidden>:
> El mar 10 jun 2014 17:34:36 CLT, Andreas Grünbacher escribió:
>> 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 ?

Version A. Even better would be to have aliases to the glibc symbols in
libattr if possible.

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

The glibc guys didn't like it; at some point I just gave up. That was
a long time
ago when arguing about glibc changes was really hard though; a lot has
changed since.

>>> +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.

Okay, thanks.

Andreas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]