Re: [Patches] Differences between glibc and EGLIBC

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Mon, 8 Jul 2013, Mark Hatle wrote:

> > Miscellaneous changes (that should not be too much effort to get in)
> > include the following (as usual, look at the current version in EGLIBC
> > after merges from upstream and any bugfixes made in EGLIBC, which may
> > differ from the originally committed version).  In some cases, if it
> > can clearly be justified that the change is no longer relevant, it
> > should be reverted.
> > 
> > 1. powerpc 8xx cache line workaround (r2503).
> 
> Are 8xx processors still being actively used with new versions of glibc?  I'm
> guessing the answer is no on this.  So bringing forward a workaround is fine,
> but I'm really not sure that there are any users.

I've no idea whether such processors are being used or not.

> > 2. Robustness for ldd with non-bash shells (really only makes sense if
> >     properly converted to be a POSIX shell script).  Patches making ldd
> >     a POSIX shell script, and generally avoiding $"" in installed
> >     scripts (glibc bug 13853), were posted to libc-alpha in November
> >     2012, but will need a copyright assignment to be completed before
> >     they can go in; that was apparently
> >     <http://sourceware.org/ml/libc-alpha/2013-06/msg01150.html> sent in
> >     June 2013, but hasn't yet appeared in copyright.list (as of
> >     2013-07-04).
> 
> If a copyright assignment can't be done.  Then someone needs to re-invent
> this.  Having ldd require bash is just wrong, especially for embedded systems.

There are no updates in copyright.list at all since 2 June.  I think it's 
fair to suppose that the assignment was indeed sent in, but that the 
person processing assignments is on holiday / off sick.

> > 6. e500 port.  I thought for a while that this should involve
> >     rearranging powerpc32/fpu/ files in glibc in a similar way to the
> >     m68k port, to reflect the different incompatible floating-point
> >     implementations for the architecture.  But while that makes a
> >     certain logical sense, there's much less in common between the two
> >     than there is between the m68k FPU variants.  So my preferred
> >     option now is as described at
> >     <http://www.eglibc.org/archives/patches/msg01286.html>: treating
> >     the port as an optimized variant of soft-float powerpc and making
> >     it use exactly the same ABI as soft-float powerpc.
> 
> I saw your other message on this.  The one question I had was, previously were
> any of the SPE 'registers' used for passing data?  If not, then I agree with
> the approach -- stick with the soft-float ABI and keep the e500 optimizations
> internal.

The SPE registers are only used for argument-passing of SPE vector types, 
which is not relevant to any glibc function.  Apart from that, the 
argument-passing ABI is already the same as soft-float; the differences 
are just about the SPE PIM functions, symbol versions and FE_* exception 
macro values as I described in 
<http://www.eglibc.org/archives/patches/msg01291.html>.

> > 8. Cross-localedef.  (Multiple parts; maybe the support for options to
> >     localedef to specify endianness and uint32_t alignment would be the
> >     least controversial, and also the largest so most valuable to
> >     merge.  It's not clear if support for non-glibc hosts is useful any
> >     more or whether it would be sufficient for cross-localedef users to
> >     build the relevant glibc version for their host and then run the
> >     new localedef with the new glibc, so support for building out of
> >     the glibc build tree wouldn't be needed.)
> 
> I still think cross-localedef is needed.  My users won't be able to (or want
> to) build a newer glibc for their host, just to generate localedef for their
> target.
> 
> Keeping the localedef as something that can run externally of the glibc build
> itself is highly useful.  My only concern is keeping it external also makes it
> more of a maintenance issue.

The external build is a massive pain to maintain and frequently breaks on 
merges from glibc.  The tool itself doesn't change much (so if you have an 
EGLIBC-based host distribution, e.g. Debian or Ubuntu, it's quite possible 
the installed host localedef will work for processing locales for the 
target, given an appropriate endianness option).

The present approach of reaching over to use source files not designed for 
use outside the main glibc build is not sustainable.  To keep 
cross-localedef long term as something that can be built separately from 
glibc, someone needs to put in the (probably weeks of) work to separate 
localedef and other host tools from the glibc source tree, into separate 
git repositories on sourceware, so that the standard build is always using 
an installed glibc rather than as part of building glibc.  (Then one could 
consider how much portability to hosts with older glibc - or non-glibc 
hosts - is needed, and maybe use gnulib to provide that portability in the 
separate localedef package.)

The options for endianness and wchar_t alignment are the only parts I 
consider critical to merge to glibc before the separate EGLIBC source tree 
is declared dead.  (I want to deal with some of the other patches in the 
list as well before declaring the separate source tree dead.  But I also 
think we might reasonably set a goal for 2.19, in six months' time, to be 
the last release branch of the separate source tree, with anything 
remaining unmerged by then being discarded in the absence of users caring 
enough about it to merge to glibc.)

> > 13. Installation of *_pic.a and associated .map files for use of
> >      mklibs.  Same question applies as for option groups and
> >      --disable-versioning about whether this is still useful (the
> >      original use case of mklibs having been for boot *floppies*).
> 
> There are still people using this.  But I agree, the behavior is becoming less
> and less important.  It may be that this type of optimization/mapping become
> deprecated in a similar way to the option groups that were discussed
> previously.
> 
> I think the two biggest users are debian (I assume they still use it), and
> OpenEmbedded.  (Where I know there are cases where mklibs doesn't work
> properly.)

Would someone from one or the other of those users like to pick up merging 
this into glibc, then?  (It would be a good idea to complete the copyright 
assignment paperwork first, given that it's quite likely any patch 
submitted needs a substantial rework.)

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches