On Wed, Jan 12 2022, Junio C Hamano wrote: > <rsbecker@xxxxxxxxxxxxx> writes: > >> diff --git a/config.mak.uname b/config.mak.uname >> index a3a779327f..9b3e9bff5f 100644 >> --- a/config.mak.uname >> +++ b/config.mak.uname >> @@ -576,6 +576,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL) >> NO_SETENV = YesPlease >> NO_UNSETENV = YesPlease >> NO_MKDTEMP = YesPlease >> + NO_UNCOMPRESS2 = YesPlease >> # Currently libiconv-1.9.1. >> OLD_ICONV = UnfortunatelyYes >> NO_REGEX = NeedsStartEnd >> >> Could we get that into rc1? > > Sure, with an appliable patch that is properly signed off. > > ----- >8 --------- >8 --------- >8 --------- >8 --------- >8 ----- > Date: Mon, 10 Jan 2022 22:51:39 -0500 > From: "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> > Subject: [PATCH] build: NonStop ships with an older zlib > > Notably, it lacks uncompress2(); use the fallback we ship in our > tree instead. > > not-Signed-off-yet-by: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > config.mak.uname | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/config.mak.uname b/config.mak.uname > index a3a779327f..9b3e9bff5f 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -576,6 +576,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL) > NO_SETENV = YesPlease > NO_UNSETENV = YesPlease > NO_MKDTEMP = YesPlease > + NO_UNCOMPRESS2 = YesPlease > # Currently libiconv-1.9.1. > OLD_ICONV = UnfortunatelyYes > NO_REGEX = NeedsStartEnd I've run into some other cases on testing on platforms hwere the NO_UNCOMPRESS2 is now needed. It's a bit of an annoyance, as git would previously compile cleanly on almost any system with NO_CURL=Y NO_OPENSSL=Y, most of those with a C compiler have a libz, even if it's ancient. As I noted in https://lore.kernel.org/git/87wnn62nhp.fsf@xxxxxxxxxxxxxxxxxxx/ this use of uncompress2() is just saving a few lines of boilerplate instead of using the underlying zlib functions, which every other in-tree user uses. So I think it would be most welcome if someone wanted to work on moving to that API use, and IMO such a change could even happen before the final release. After all we don't use reftable for anything except the tests it runs, so as long as those pass it IMO outweighs the new annyonce in compiling git on those platforms.
