On Fri, Jan 11, 2019 at 10:03:01AM -0800, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:
>
> > On Thu, Jan 10, 2019 at 01:22:00PM -0800, Junio C Hamano wrote:
> >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> >> ...
> >> > I.e. is this another case where we're blindly fixing bugs but should
> >> > just re-import upstream's code instead?
> >>
> >> Good point. I am inclined to queue the remainder of the series
> >> without this one for now.
> >
> > Note that without this first patch the linux-gcc build job will fail
> > with the above compiler error, and that's the only build job that runs
> > the test suite with all the misc test knobs (split-index,
> > commit-graph, etc.) enabled.
>
> I know.
>
> The point is to give more incentive to try what was suggested
> earlier by Ævar (in short, "try to do the right thing, before
> hacking around locally in this project" ;-)
Well, first I'm not sure what changes Ævar meant to be backported.
Back then I briefly glanced at glibc's gitweb [1], but didn't see
anything remotely relevant to these compiler errors.
As to re-importing obstack.{c,h} from upstream, we've made some
portability fixes to these files, and neither of the commit messages
of those fixes mention that they are backports from upstream. OTOH,
one of those commits mentions platforms like
"i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1, SunOS 5.10", which makes
me suspect that the re-import will be susceptible to those portability
issues again. Therefore, I think re-importing these files from
upstream is beyond the scope of this patch series (and might not be
the right thing at all).
[1] https://sourceware.org/git/?p=glibc.git;a=history;f=malloc/obstack.c;h=1669641983512d64f66c1ad659562f77ef48adfd;hb=refs/heads/master
