This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ECANCELED, errlist.c (was Re: FreeBSD port (11): a new errno)


> On Aug 27, 2002, Roland McGrath <roland@frob.com> wrote:
> 
> > Index: sysdeps/gnu/Versions
> > +  GLIBC_2.3 {
> > +    #errlist-compat	126
> > +    _sys_errlist; sys_errlist; _sys_nerr; sys_nerr;
> > +  }
> > +}
> 
> Any reason why you're setting this limit so low?  Both alpha and mips
> have higher values of errno that would cause the build to break.  I
> guess even for GLIBC_2.2 you'd need it higher, and perhaps even 2.1.

This is not a "limit".  It is the number of entries (i.e. sys_nerr value)
that the symbols in that version set need to have for binary compatibility.
It has to be exact for it to mean anything useful.

It hadn't occurred to me that the errno values would be inconsistent across
Linux platforms (which I frankly find to be obviously insane).  The old
sys_errlist binary compatibility code for Linux was not machine-specific.
It defined the GLIBC_2.0 version of sys_errlist/sys_nerr with 123 entries
on all platforms, and the GLIBC_2.1 default version with however many
entries errlist.c defined.  If other platforms with different values did
not have exactly 123 entries before, then the GLIBC_2.0 compatibility
symbol has always been wrong for them.

It would be straightforward enough to add a configuration tuple pattern to
the magic comments so that different ones apply to different configurations.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]