You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc #57878
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2011-12-28.13:25:14.009>labels= ['extension-modules']
title='XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc'updated_at=<Date2014-05-13.21:42:05.012>user='https://bugs.python.org/zbysz'
Extended attribute support was added in bpo-12720. Doesn't compile on kfreebsd/debian, which uses eglibc and gcc. The error is that the symbols XATTR_LIST_MAX and XATTR_SIZE_MAX are not defined.
After http://hg.python.org/cpython/rev/f325439d7f84 xattr compilation tests for 'defined(HAVE_SYS_XATTR_H) && defined(GLIBC)', but in this case this test doesn't work. Anyway, XATTR_SIZE_MAX is defined (on Linux) in <linux/limits.h>, and <sys/xattr.h> doesn't know anything about it.
(When defined XATTR_{SIZE,LIST}_MAX to 65536 like on linux to go through with the compilation, and os.listxattr('/') returns 'OSError: [Errno 78] Function not implemented'...)
Yes, it must be, because XATTR_SIZE_MAX is only defined in
linux/limits.h. The problem is that with the kfreebsd kernel,
/usr/include/sys/limits.h doesn't define or include anything that
defines XATTR_SIZE_MAX.
Maybe the test should be 'defined(HAVE_SYS_XATTR_H) &&
defined(XATTR_SIZE_MAX)'?
Is __FreeBSD__ defined on that system?
No. I'm putting the complete list below.
I'm not sure though if we should start supporting hybrid systems.
Actually python2.5-7 and 3.2 is normally packaged by debian for
is arch, so it mostly works.
pino commented on Nov 6, 2012
pinomannequin
Mannequin
More actions
*_MAX constants are usually defined when the system declares that the maximum limit for that option exist and is already known at compile time.
Python should simply not rely on XATTR_LIST_MAX and XATTR_SIZE_MAX being defined, but just grow the buffers as needed until *getxattr / *listxattr succeed or fail with errno != ERANGE; it seems the case already, although the two *_MAX are used as kind of "upper bound" limit.
Instead of using short lists with sizes to try, what about starting from a size (e.g. 128 for getxattr and 256 for listxattr), and grow the buffer by adding the same value each iteration (or doubling the size)?
Activity
zbysz commentedon Dec 28, 2011
Extended attribute support was added in bpo-12720. Doesn't compile on kfreebsd/debian, which uses eglibc and gcc. The error is that the symbols XATTR_LIST_MAX and XATTR_SIZE_MAX are not defined.
After http://hg.python.org/cpython/rev/f325439d7f84 xattr compilation tests for 'defined(HAVE_SYS_XATTR_H) && defined(GLIBC)', but in this case this test doesn't work. Anyway, XATTR_SIZE_MAX is defined (on Linux) in <linux/limits.h>, and <sys/xattr.h> doesn't know anything about it.
(When defined XATTR_{SIZE,LIST}_MAX to 65536 like on linux to go through with the compilation, and os.listxattr('/') returns 'OSError: [Errno 78] Function not implemented'...)
benjaminp commentedon Dec 28, 2011
Are you telling me that XATTR_SIZE_MAX is defined nowhere on eglibc?
zbysz commentedon Dec 28, 2011
Unless I'm completely confused, XATTR_SIZE_MAX is defined by linux kernel headers, not the libc.
On my linux debian box:
$ grep -r XATTR_SIZE_MAX -I /usr
include/linux/limits.h:#define XATTR_SIZE_MAX 65536
$ dpkg -l libc6
libc6 2.11.2-10 Embedded GNU C Library: Shared libraries
$ dpkg -S /usr/include/linux/limits.h
linux-libc-dev: /usr/include/linux/limits.h
On debian/kfreebsd grep XATTR_SIZE_MAX doesn't find anything.
On fedora 16:
$ grep -r XATTR_SIZE_MAX -I /usr
/usr/include/linux/limits.h:#define XATTR_SIZE_MAX 65536
$ rpm -qf /usr/include/linux/limits.h
kernel-headers-3.1.0-0.rc10.git0.1.fc16.x86_64
zbysz commentedon Dec 28, 2011
Forgot to add (on the fedora box):
$ rpm -q glibc
glibc-2.14.90-13.x86_64
(The GNU libc libraries from http://www.gnu.org/software/glibc/)
So the glibc/eglibc split is not important here.
pitrou commentedon Dec 28, 2011
But linux/limits.h is included by the glibc:
zbysz commentedon Dec 28, 2011
Yes, it must be, because XATTR_SIZE_MAX is only defined in
linux/limits.h. The problem is that with the kfreebsd kernel,
/usr/include/sys/limits.h doesn't define or include anything that
defines XATTR_SIZE_MAX.
Maybe the test should be 'defined(HAVE_SYS_XATTR_H) &&
defined(XATTR_SIZE_MAX)'?
skrah commentedon Dec 28, 2011
So the problem occurs on:
http://www.debian.org/ports/kfreebsd-gnu/
Did I get that right? Is __FreeBSD__ defined on that system?
I'm not sure though if we should start supporting hybrid systems.
zbysz commentedon Dec 28, 2011
That's the one.
No. I'm putting the complete list below.
Actually python2.5-7 and 3.2 is normally packaged by debian for
is arch, so it mostly works.
zbysz commentedon Dec 28, 2011
[Why does roundup remove quoted text being replied to???]
On 12/28/2011 06:05 PM, Stefan Krah wrote:
pino commentedon Nov 6, 2012
*_MAX constants are usually defined when the system declares that the maximum limit for that option exist and is already known at compile time.
Python should simply not rely on XATTR_LIST_MAX and XATTR_SIZE_MAX being defined, but just grow the buffers as needed until *getxattr / *listxattr succeed or fail with errno != ERANGE; it seems the case already, although the two *_MAX are used as kind of "upper bound" limit.
Instead of using short lists with sizes to try, what about starting from a size (e.g. 128 for getxattr and 256 for listxattr), and grow the buffer by adding the same value each iteration (or doubling the size)?