> On Apr 2, 2018, at 2:00 PM, devel-requ...@lists.open-mpi.org wrote:
>
> From: Gilles Gouaillardet <gilles.gouaillar...@gmail.com
> <mailto:gilles.gouaillar...@gmail.com>>
> 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 <devel@lists.open-mpi.org
> <mailto:devel@lists.open-mpi.org>>
>
> 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
randomdsde...@gmail.com_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel
