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

Re: [Patches] Differences between glibc and EGLIBC

On 7/8/13 12:23 PM, Joseph S. Myers wrote:
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

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

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

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

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

My desire is that it isn't something that is -built- separately, but is something that can run separately. I.e. you need to build eglibc (cross) and you then get cross-localedef built for the host system.

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

I think that is reasonable.

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

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

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

Patches mailing list