[v3] build: support z/OS (OS/390).

Commit Message

Haritha D Feb. 25, 2024, 6:10 a.m. UTC

From: Haritha D <[e-mail]>

Since the z/OS linker does not support searching dynamic libraries,
and the current setting of CC_LD_DYNPATH results in a directory
to be supplied to the link step with no option as the suffix,
it causes a linker error because the z/OS LD linker
does not accept directories as input.
Therefore, -L option is added.
Also introduced z/OS (OS/390) as a platform in config.mak.uname

Signed-off-by: Haritha D <[e-mail]>
---
    This PR enables a successful git build on z/OS.
    
    Since the z/OS linker does not support searching dynamic libraries, and
    the current setting of CC_LD_DYNPATH results in a directory to be
    supplied to the link step with no option as the suffix, it causes a
    linker error because the z/OS LD linker does not accept directories as
    input. Therefore, we workaround this by adding the -L option. And,
    Introduced z/OS (OS/390) as a platform in config.mak.uname
    
    Thanks for taking the time to contribute to Git! Please be advised that
    the Git community does not use github.com for their contributions.
    Instead, we use a mailing list ([e-mail]) for code
    submissions, code reviews, and bug reports. Nevertheless, you can use
    GitGitGadget (https://gitgitgadget.github.io/) to conveniently send your
    Pull Requests commits to our mailing list.
    
    Please read the "guidelines for contributing" linked above!

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1663%2FHarithaIBM%2Fzos-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1663/HarithaIBM/zos-v3
Pull-Request: https://github.com/git/git/pull/1663

Range-diff vs v2:

 1:  53e211d7a65 ! 1:  2f1ad41bc14 build: support z/OS (OS/390).
     @@ config.mak.uname: ifeq ($(uname_S),NONSTOP_KERNEL)
      +        NO_MEMMEM = YesPlease
      +        NO_GECOS_IN_PWENT = YesPlease
      +        HAVE_STRINGS_H = YesPlease
     -+        NEEDS_MODE_TRANSLATION = YesPlease
     ++       NEEDS_MODE_TRANSLATION = YesPlease
      +endif
       ifeq ($(uname_S),MINGW)
       	ifeq ($(shell expr "$(uname_R)" : '1\.'),2)
       		$(error "Building with MSys is no longer supported")
     -
     - ## configure.ac ##
     -@@ configure.ac: else
     -             CC_LD_DYNPATH=-Wl,+b,
     -           else
     -              CC_LD_DYNPATH=
     -+	     if test "$(uname -s)" = "OS/390"; then
     -+		     CC_LD_DYNPATH=-L
     -+	     fi
     -              AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
     -           fi
     -       fi
 2:  05df5d7e2d5 < -:  ----------- an improvement: removed configure.ac changes


 config.mak.uname | 12 ++++++++++++
 1 file changed, 12 insertions(+)


base-commit: f41f85c9ec8d4d46de0fd5fded88db94d3ec8c11

Comments

Junio C Hamano Feb. 26, 2024, 5:30 p.m. UTC | #1

"Haritha  via GitGitGadget" <[e-mail]> writes:

> From: Haritha D <[e-mail]>
>
> Since the z/OS linker does not support searching dynamic libraries,
> and the current setting of CC_LD_DYNPATH results in a directory
> to be supplied to the link step with no option as the suffix,
> it causes a linker error because the z/OS LD linker
> does not accept directories as input.
> Therefore, -L option is added.

Shouldn't all of the above removed by now, with 07bbe4ca (Merge
branch 'jc/make-libpath-template', 2024-02-06) that merged the
support for platforms whose linker does not have a way to specify
the path used at runtime to locate dynamic libraries and is already
in the Git 2.44 release?  The autoconf-generated config.mak.autogen
would leave CC_LD_DYNPATH to empty on such a platform, which then
adds only one "-L $where" (instead of the usual "-L $where -R
$where") on the linker command line, making your earlier workaround
to use "-L $where -L $where" unnecessary?

> Also introduced z/OS (OS/390) as a platform in config.mak.uname

"Introduce z/OS ..." (cf. Documentation/SubmittingPatches)

Or perhaps

	Add platform specific settings in config.mak.uname for zOS
	(OS/390).

> diff --git a/config.mak.uname b/config.mak.uname
> index dacc95172dc..03ee2b74525 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -638,6 +638,18 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
>  	SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
>  	SHELL_PATH = /usr/coreutils/bin/bash
>  endif
> +ifeq ($(uname_S),OS/390)
> +        NO_SYS_POLL_H = YesPlease
> +        NO_STRCASESTR = YesPlease
> +        NO_REGEX = YesPlease
> +        NO_MMAP = YesPlease
> +        NO_NSEC = YesPlease
> +        NO_STRLCPY = YesPlease
> +        NO_MEMMEM = YesPlease
> +        NO_GECOS_IN_PWENT = YesPlease
> +        HAVE_STRINGS_H = YesPlease
> +       NEEDS_MODE_TRANSLATION = YesPlease

All of the above should be indented with TAB to imitate the support
for other platforms, I think.

Thanks.

> +endif
>  ifeq ($(uname_S),MINGW)
>  	ifeq ($(shell expr "$(uname_R)" : '1\.'),2)
>  		$(error "Building with MSys is no longer supported")
>
> base-commit: f41f85c9ec8d4d46de0fd5fded88db94d3ec8c11

Haritha D March 1, 2024, 9:09 a.m. UTC | #2

Hi Team,

The win test(7) test case failed stating the reason as "The Operation cancelled". I saw that it failed after 5 hours 59 minutes of running the test cases(build). How do I handle this?

Please suggest.

Best regards
Haritha

On 26/02/24, 11:15 PM, "Junio C Hamano" <[e-mail] <mailto:[e-mail]>> wrote:


"Haritha via GitGitGadget" <[e-mail] <mailto:[e-mail]>> writes:


> From: Haritha D <[e-mail] <mailto:[e-mail]>>
>
> Since the z/OS linker does not support searching dynamic libraries,
> and the current setting of CC_LD_DYNPATH results in a directory
> to be supplied to the link step with no option as the suffix,
> it causes a linker error because the z/OS LD linker
> does not accept directories as input.
> Therefore, -L option is added.


Shouldn't all of the above removed by now, with 07bbe4ca (Merge
branch 'jc/make-libpath-template', 2024-02-06) that merged the
support for platforms whose linker does not have a way to specify
the path used at runtime to locate dynamic libraries and is already
in the Git 2.44 release? The autoconf-generated config.mak.autogen
would leave CC_LD_DYNPATH to empty on such a platform, which then
adds only one "-L $where" (instead of the usual "-L $where -R
$where") on the linker command line, making your earlier workaround
to use "-L $where -L $where" unnecessary?


> Also introduced z/OS (OS/390) as a platform in config.mak.uname


"Introduce z/OS ..." (cf. Documentation/SubmittingPatches)


Or perhaps


Add platform specific settings in config.mak.uname for zOS
(OS/390).


> diff --git a/config.mak.uname b/config.mak.uname
> index dacc95172dc..03ee2b74525 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -638,6 +638,18 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
> SHELL_PATH = /usr/coreutils/bin/bash
> endif
> +ifeq ($(uname_S),OS/390)
> + NO_SYS_POLL_H = YesPlease
> + NO_STRCASESTR = YesPlease
> + NO_REGEX = YesPlease
> + NO_MMAP = YesPlease
> + NO_NSEC = YesPlease
> + NO_STRLCPY = YesPlease
> + NO_MEMMEM = YesPlease
> + NO_GECOS_IN_PWENT = YesPlease
> + HAVE_STRINGS_H = YesPlease
> + NEEDS_MODE_TRANSLATION = YesPlease


All of the above should be indented with TAB to imitate the support
for other platforms, I think.


Thanks.


> +endif
> ifeq ($(uname_S),MINGW)
> ifeq ($(shell expr "$(uname_R)" : '1\.'),2)
> $(error "Building with MSys is no longer supported")
>
> base-commit: f41f85c9ec8d4d46de0fd5fded88db94d3ec8c11

Ghanshyam Thakkar March 1, 2024, 2:39 p.m. UTC | #3

On Fri Mar 1, 2024 at 2:39 PM IST, Haritha D wrote:
> Hi Team,
>
> The win test(7) test case failed stating the reason as "The Operation cancelled". I saw that it failed after 5 hours 59 minutes of running the test cases(build). How do I handle this?
>
> Please suggest.

Hey,

This seems to be a recurring issue, as this happens to me majority
of the time. Seems as though the vm just sits idle after finishing tests
as 360 minutes is the timeout for github acitons.

Usually, rerunning the failed tests from the actions tab works for me.

Thanks.

Junio C Hamano March 1, 2024, 6:15 p.m. UTC | #4

Haritha D <[e-mail]> writes:

> The win test(7) test case failed stating the reason as "The
> Operation cancelled". I saw that it failed after 5 hours 59
> minutes of running the test cases(build). How do I handle this?

Those "win test (n)", at least some of them, seem to have been
somewhat flaky [*1*].  If you are certain you did not break them
with your change, you do not have to fix them yourself.

I am a wrong person to ask how the test failure that may [*2*] block
GGG submission can be circumvented, as I am not involved in that
machinery at all.

Thanks.


[Footnotes]

*1* Also I've seen osx-clang job time-out from time to time, without
    failing any specific test.  Re-running failed jobs from the menu
    often make them pass, which is why I said "somewhat flaky".

*2* I do not even know if GGG refuses to submit a series with a test
    failure, let alone if it allows to override such a safety if
    exists.

Randall S. Becker March 1, 2024, 6:25 p.m. UTC | #5

On Friday, March 1, 2024 1:15 PM, Junio C Hamano wrote:
>Haritha D <[e-mail]> writes:
>
>> The win test(7) test case failed stating the reason as "The Operation
>> cancelled". I saw that it failed after 5 hours 59 minutes of running
>> the test cases(build). How do I handle this?
>
>Those "win test (n)", at least some of them, seem to have been somewhat
flaky [*1*].  If you are certain you did not break them with
>your change, you do not have to fix them yourself.
>
>I am a wrong person to ask how the test failure that may [*2*] block GGG
submission can be circumvented, as I am not involved in that
>machinery at all.
>
>Thanks.
>
>
>[Footnotes]
>
>*1* Also I've seen osx-clang job time-out from time to time, without
>    failing any specific test.  Re-running failed jobs from the menu
>    often make them pass, which is why I said "somewhat flaky".
>
>*2* I do not even know if GGG refuses to submit a series with a test
>    failure, let alone if it allows to override such a safety if
>    exists.

Which tests have been hanging on S390? We have occasional hangs on NonStop
that end up being attributed to our CI build system not supplying pipes
properly to git. It would be interesting if the same tests are having issues
on different platforms.
--Randall

Haritha D March 4, 2024, 4:19 a.m. UTC | #6

Looks like , I do not have sufficient permissions to rerun the tests. How do I proceed?

Please suggest.
 
Thank you
Haritha

On 01/03/24, 11:55 PM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:


On Friday, March 1, 2024 1:15 PM, Junio C Hamano wrote:
>Haritha D <[e-mail] <mailto:[e-mail]>> writes:
>
>> The win test(7) test case failed stating the reason as "The Operation
>> cancelled". I saw that it failed after 5 hours 59 minutes of running
>> the test cases(build). How do I handle this?
>
>Those "win test (n)", at least some of them, seem to have been somewhat
flaky [*1*]. If you are certain you did not break them with
>your change, you do not have to fix them yourself.
>
>I am a wrong person to ask how the test failure that may [*2*] block GGG
submission can be circumvented, as I am not involved in that
>machinery at all.
>
>Thanks.
>
>
>[Footnotes]
>
>*1* Also I've seen osx-clang job time-out from time to time, without
> failing any specific test. Re-running failed jobs from the menu
> often make them pass, which is why I said "somewhat flaky".
>
>*2* I do not even know if GGG refuses to submit a series with a test
> failure, let alone if it allows to override such a safety if
> exists.


Which tests have been hanging on S390? We have occasional hangs on NonStop
that end up being attributed to our CI build system not supplying pipes
properly to git. It would be interesting if the same tests are having issues
on different platforms.
--Randall

Patch

diff --git a/config.mak.uname b/config.mak.uname
index dacc95172dc..03ee2b74525 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -638,6 +638,18 @@  ifeq ($(uname_S),NONSTOP_KERNEL)
 	SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
 	SHELL_PATH = /usr/coreutils/bin/bash
 endif
+ifeq ($(uname_S),OS/390)
+        NO_SYS_POLL_H = YesPlease
+        NO_STRCASESTR = YesPlease
+        NO_REGEX = YesPlease
+        NO_MMAP = YesPlease
+        NO_NSEC = YesPlease
+        NO_STRLCPY = YesPlease
+        NO_MEMMEM = YesPlease
+        NO_GECOS_IN_PWENT = YesPlease
+        HAVE_STRINGS_H = YesPlease
+       NEEDS_MODE_TRANSLATION = YesPlease
+endif
 ifeq ($(uname_S),MINGW)
 	ifeq ($(shell expr "$(uname_R)" : '1\.'),2)
 		$(error "Building with MSys is no longer supported")