Re: [Patches] Differences between glibc and EGLIBC

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

On Mon, 8 Jul 2013, Mark Hatle wrote:

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

By all means (complete the copyright assignment and) make the code in 
glibc more portable so that it can be built with host headers (and used 
for make localedata/install-locales) much like the cross-rpcgen, then.  
Right now I'm pretty sure this code (some of which may be shared between 
localedef and libc) has lots of dependence on libc's internal headers, 
without any clean way to use only the internal headers that are relevant 
while using the installed versions of all system headers.

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

I should then suggest that any distributors using EGLIBC should (complete 
the copyright assignment and) work out which of the changes are relevant 
to their distribution (conservatively, anything that could affect their 
builds or the contents of installed headers, binaries, etc.) and join in 
the task of merging those changes to glibc (coordinating through this 
list, especially for the trickier changes), as otherwise you may find in a 
year's time that there is no EGLIBC 2.20 and some change you cared about 
hasn't been merged to glibc for glibc 2.20.

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