> On Apr 2, 2018, at 2:00 PM, [email protected] wrote:
>
> From: Gilles Gouaillardet <[email protected]
> <mailto:[email protected]>>
> Subject: Re: [OMPI devel] Guidance on How to Submit PRs to Fix GitHub Issue
> #5000?
> Date: April 1, 2018 at 8:49:32 PM EDT
> To: Open MPI Developers <[email protected]
> <mailto:[email protected]>>
>
> Bryce,
>
> The current status on OS X is half baked, the /usr/bin/javah symlink is still
> there, but it points to nothing, and a direct consequence is that
> AC_PATH_PROG detects /usr/bin/javah, when I hope it does not.
>
> ⋮
I touch on that later on in my original issue’s discussion thread and in
the one I opened downstream in Homebrew, yes. I believe, however, that, if you
haven’t noticed it already, the situation is like this:
`AC_PATH_PROG()` finds `/usr/bin/javah` in your system’s `$PATH`.
`/usr/bin/javah` is a symbolic link to
`/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah`.
When Open mPI’s build process invokes
`/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah`
through `/usr/bin/javah`, the former then serves as a run-time shim that looks
for
`/Library/Java/JavaVirtualMachines/jdk-$JDK_VERSION.jdk/Contents/Home/bin/javah`.
When
`/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah`
can’t forward its own invocation along to
`/Library/Java/JavaVirtualMachines/jdk-$JDK_VERSION.jdk/Contents/Home/bin/javah`
when `$JDK_VERSION=10` because the latter tool does not exist in that case,
the former then prints a message to standard error and then exits with error
code 2.
> ⋮
>
> Since javac -h is already working in Java 8, I guess we do not care of older
> java versions.
>
> I am currently testing a PR that simply replace java with javac -h
>
> ⋮
Cool, then I’ll rebase my stab at the work that remains on top of yours
after in lands in-tree.
> ⋮
>
> Regarding the PR, you are obviously free to issue one. That being said, it
> should only be vs the master branch. Once it is merged, other PRs can be
> issued vs the release branches by cherry-picking (and back porting if needed)
> the commit in the master branch. This is how we work at Open MPI (e.g. no, we
> do not gitflow).
>
> Cheers,
>
> Gilles
I was already working against `master`, but thanks for letting me know.
Regards,
Bryce Glover
[email protected]_______________________________________________
devel mailing list
[email protected]
https://lists.open-mpi.org/mailman/listinfo/devel
