Closed RandomDSdevel closed 6 years ago
I see open-mli
in the last two commands; I'm guessing that's a typo and it should be open-mpi
?
@scpeters: Oof, should have looked for more of those; I saw one, but didn't catch the ones you saw before submitting this issue. I'm fixing them now…grumbles something incoherent about either auto-correct, having intermittent butterfingers, or both.)
@scpeters: Reported upstream as open-mpi/ompi#5000.
You know, I'm surprised Open MPI's configure.ac
script didn't detect this and bail because of it…
Looking through my logs, it appears said script fell back to using some programs it found in /ur/bin
, which…doesn't make sense, as the JDK installs into /Library/Java/JavaVirtualMachines
, and I don't think I'd have detritus from any of the old Apple-vended Java installations left lying around (as far as I can remember, this OS X installation hails from after Apple handed releasing Java for Macs back over to Oracle.) I wonder where those executables came from…?
Never mind; I don't see any old Apple Java run-time libraries left over on my machine in /System/Library/Java
(there's no JavaVirtualMachines
folder in there.) What I'm dealing with here must therefore all be from within /System/Library/Frameworks/JavaVM.framework
, which is apparently some infrastructure that's still needed even with the Oracle JREs and JDKs. (Per an old message which I found on one of the OpenJDK mailing lists via this Ask Different answer when I was looking around to see what information I could jump off from to troubleshoot and make sure I was as free of old Apple Java installations as I thought I was:
⋮
Do NOT remove any content in the JavaVM.framework. Those items are required by Java 7, 8, 9+ as well as Java SE 6. No modern version of OS X has a Java JDK inside there anyway.
⋮
So, in any case, I'm not crazy and did end up cleaning up after any old Apple Java VMs I might ever have had, if any.)
Anyway, if I poke at /usr/bin/javah
(or /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah
, the former's symbolic-linking target which behaves identically) — say, by invoking it with its --version
or --help
flag —, then here's what I get back:
Unable to locate an executable at "/Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/bin/javah" (-1)
If I ask my shell what $?
is after that, then it prints '2
,' an error code. This, of course, is all to be expected, given the circumstances.
@scpeters:
It's getting a bit late, so I'll probably sign off for the night soon, but I may have some idea of what would need to be patched upstream to get this to work, so I'll hack around on that tomorrow. (Or we could just make sure that Apple's shims don't come first in users' paths ourselves down here in Homebrew, but that feels like a hack, as it would make more sense for upstream to know not to look in /usr/bin
for JDK executables on OS X/macOS in the first place…)
I've now brought this issue's upstream counterpart to the attention of the Open MPI developers' mailing list here and have already received a response to the thread that my former message started there. This reply was to the effect that one of Open MPI's developers felt this issue to be important enough to submit at least a partial fix for it himself. I'll still be working on finishing things up, though (OS X/macOS JDK tool path handling still needs correcting,) so that's till coming.
This issue will be addressed upstream once open-mpi/ompi#5001 and open-mpi/ompi#5015 get merged. I'll submit a formula patch to pull them in once they are (I doubt those two changes alone would be enough for upstream to tag a new release…)
#5001 has now been merged upstream to master
as commit 5e12e0f
and is currently in the process of being backported to Open MPI v3.0.x in open-mpi/ompi#5029 pending upstream CI network hiccups. open-mpi/ompi#5015 should follow shortly.
Thanks @RandomDSdevel for chasing the bug and reporting it. Given that it affects a non-default option, I think we'll wait for the fix in the next version.
@fxcoudert:
I was going to submit the relevant patch in-formula to fix this once said commit landed upstream since I'm the one who's working on that anyway, but OK.
Not that this is nearly as relevant before since @fxcoudert has indicated that Homebrew Core is just going to wait for the Open MPI v3.0.2 to get this fix and the previous one relevant here and has not indicated interest in reopening this issue for me to submit a formula patch to incorporate both of them, but open-mpi/ompi#5015 has now been merged to master
upstream.
I'm going to go ahead and follow up on this issue by submitting a PR to fix it even though it was never reopened for this to happen.
Please note we will close your issue without comment if you delete, do not read, or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.
Please always confirm that you:
brew install
ing (orupgrade
ing orreinstall
ing) a single, official formula (not a cask?) If it's a generalbrew
problem, please file this issue at Homebrew/brew: https://github.com/Homebrew/brew/issues/new. If it's abrew cask
problem please file this issue at https://github.com/caskroom/homebrew-cask/issues/new. If it's a tap — e.g. Homebrew/homebrew-php — problem, please file this issue at the tap.brew update
and can still reproduce the problem? (Caveat: I suspended runningbrew update
s while producing debugging logs for this issue to ensure that Homebrew Core would stay on the same revision between both log-collection runs I made, so me checking this box only applies with respect to the status of my system prior to my preparing to submit this issue. This should not, however, prove to be any sort of problem, as no commits to Homebrew Core since I started going down this rabbit hole appear to have touched any files that would be relevant here.)brew doctor
, fixed all issues and can still reproduce the problem?ran(N/A; see the next bullet point.)brew gist-logs <formula>
(where<formula>
is the name of the formula that failed) and included the output link?brew gist-logs
didn't work (or, in this case, was not preferred:) ranbrew config
andbrew doctor
and included their output with your issue?To help us debug your issue please explain:
What you were trying to do (and why:)
Upgrade my local, built-from-source copy of Open MPI from v3.0.0, Homebrew formula
revision 2
, to v3.0.1 in the course of going through my normal routine of keeping all of my software tools up to date.What happened (include command output:)
Homebrew failed to successfully build Open MPI from v3.0.0, Homebrew formula
revision 2
, to v3.0.1. My logs are:HOMEBREW_BUILD_FROM_SOURCE=1
.)In both cases, the exact point of failure manifested itself as follows:
The issue I describe in this report is thus due to Homebrew's
open-mpi
formula's--with-java
option and the fact thatjavah
was deprecated in Java 9.x and removed in Java 10.What you expected to happen:
For Homebrew to successfully build the new version of Open MPI from source and install it in the old version's place.
Step-by-step reproduction instructions (by running
brew
commands:)With
HOMEBREW_BUILD_FROM_SOURCE=1
(not supported with issue resolution:)Note that setting that environment variable as shown above probably doesn't make any difference in this case, as upgrading Open MPI doesn't depend on upgrading any of its dependencies given the states my Homebrew installation and the packages it manages are currently in, but I usually set it any time I run
brew upgrade
, just to be consistent.Without
HOMEBREW_BUILD_FROM_SOURCE=1
(given to show that this issue also occurs under a supported configuration:)