This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: Move include/stubs-biarch.h to sysdeps/generic
On Fri, 16 Mar 2012, H.J. Lu wrote:
> On Fri, Mar 16, 2012 at 10:37 AM, Roland McGrath <email@example.com> wrote:
> >> This patch moves include/stubs-biarch.h to sysdeps/generic so that
> >> each arch can override it with sysdeps/cpu/stubs-biarch.h. ?OK to
> >> install?
> > It seems like stubs-biarch.h and the whole special case for it could be
> > replaced by the genericized logic for multi-variant header generation we
> > talked about for bits/syscall.h and the like. ?That seems like the right
> > thing to do instead.
> As I indicated in my reply to multi-variant header generation. they are
> tied with soversion.i and soversion.mk. It is much bigger changes than
> I feel comfortable with.
I think stubs.h is probably simpler than lib-names.h - but a proper fix
may require doing both.
I wonder if shlib-versions files are really doing too much. Defining the
details of SONAMEs and symbol versions, for a given ABI, makes sense for
them. But perhaps the WORDSIZE and ABI lines give information that should
be given elsewhere. WORDSIZE we've found isn't really adequate - after
all, for x32 you want three variants of this information, not two (and
it's certainly better to have something generic rather than ad hoc
architecture-specific code). As for the ABI lines - shouldn't all the
other information, such as SONAMEs, be written as a function of the ABI
name rather than of a regular expression?
So my model might be this: either a makefile, or a configure fragment,
sets a variable that gives the canonical ABI name for a particular
configuration. This name may look similar to a GNU target triplet, but
need not be identical to one. These are the same names as presently used
for baseline files in scripts/data/ - if two builds use the same name,
they must have the same symbol versions, the same SONAMEs, use the same
directories for libraries and it won't be possible to put both of them
inside a single root filesystem because filenames would conflict. (They
might still be incompatible in other ways, e.g. big and little endian.)
This ABI name is then what goes on the left of lines in shlib-versions.
The information that's presently on WORDSIZE lines would be replaced by
additional information in makefiles, listing the names of the alternate
ABIs alongside the other information presently listed for bits/syscall.h.
(Maybe there would be separate variables for the CPU part of the ABI name
and the OS part.)
In any case, if it's concluded that such a cleanup should be done
separately after the port (with a more ad hoc approach) is in then an
issue should be filed in Bugzilla to track the desired future cleanup.
Joseph S. Myers