This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH v2 10/12] soft-fp: Add the lack of implementation for 128 bit


Joseph Myers <joseph@codesourcery.com> 於 2018年7月19日 週四 上午4:40寫道:
>
> On Wed, 18 Jul 2018, Zong Li wrote:
>
> > > I think consideration of (a revised version of) this patch is most
> > > appropriately deferred until 2.29 (and probably likewise the new port
> > > itself, given the associated risks and the lack of posting before the
> > > freeze - posting before the freeze being particularly important for any
> > > architecture-independent changes involved in a new port).
> >
> > I know this concern and mechanism in glibc. Is there a chance to
> > include this modification at this moment? Because this new port
> > is the only one port to use it.
>
> Well, being in the freeze you could test the patch much more extensively
> than would normally be expected for such a patch to justify it as not
> affecting existing configurations.

Thanks, I am going to do my best to fix up this port problem before
release date.

> I'm thinking of a before-and-after
> comparison of installed stripped shared libraries built with
> build-many-glibcs.py - build unmodified glibc for all configurations
> build-many-glibcs.py supports, using the --strip option, save the install
> directories, rebuild for all configurations with the patch applied (and no
> other changes), compare the <configuration>/lib* directories with the
> saved copies from the previous build to make sure that none of the
> installed stripped shared libraries have changed at all (and also make
> sure that the test results are identical for the two builds).
>
> That would be overkill for this patch normally - but late in the freeze as
> we are, we need to be much, much more careful about not breaking other
> configurations, and so much more thorough testing is appropriate (and of
> course the patch submission message then needs to describe that testing).
>

This idea is awesome. That is helpful for port developer no matter for new port
or old port, thanks for your effort.

> --
> Joseph S. Myers
> joseph@codesourcery.com


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