Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetch-jdk doesn't store the arch in the directory name, so different architectures get confused #257

Open
chrisseaton opened this issue Mar 21, 2022 · 5 comments

Comments

@chrisseaton
Copy link
Contributor

For example /Users/chrisseaton/.mx/jdks/labsjdk-ce-11-jvmci-22.1-b03/ is that AMD64 or AArch64?

@dougxc
Copy link
Member

dougxc commented Mar 22, 2022

How is this resolved for JDKs installed under /Library/Java/JavaVirtualMachines? It would be best to adopt an existing solution to this problem.

@chrisseaton
Copy link
Contributor Author

How is this resolved for JDKs installed under /Library/Java/JavaVirtualMachines?

I think they assume you use a JDK for your native architecture, so no solution.

But I can't use a JDK for my native architecture until Sulong catches up. Just a temporary solution needed.

@dougxc
Copy link
Member

dougxc commented Mar 22, 2022

Given that fetch-jdk will use the native platform in deciding which binary to download, this is more than just about disambiguating on the installation directory name.
That is, I don't think fetch-jdk can support this use case without non-trivial changes. Since we're only talking about a temporary situation, I hope doing the download manually is ok.

@chrisseaton
Copy link
Contributor Author

On macOS the native platform can be either AArch64 or AMD64, on the same machine at the same time. The correct binary is downloaded in both cases. It just goes into the same place.

@lewurm
Copy link
Member

lewurm commented May 12, 2022

I worked around it by just not using mx fetch-jdk. The situation is kind of temporary, and I don't think this will be a problem in 1-2 years from now.

My helper (note that it also sets MX_PYTHON accordingly):

# % cat =enter_gvm
#!/bin/bash

set -x
set -e

TAG="jvmci-22.1-b03"
JDK_ROOT=$HOME/jdks

# $1 requested arch
# $2 ce/ee
# $3 11/17

case $1 in
    aarch64|arm64)
        ARCH=aarch64
        ;;
    intel|x86|amd64|x86_64)
        ARCH=amd64
        ;;
    *)
        echo "Specify either aarch64 or amd64, not \"$1\""
        exit 1
        ;;
esac

case $2 in
    ce|ee)
        EDITION=$2
        ;;
    *)
        echo "Specify either ce or ee, not \"$2\""
        exit 2
        ;;
esac

case $3 in
    11|17)
        VERSION=$3
        ;;
    *)
        echo "Specify either 11 or 17, not \"$3\""
        exit 3
        ;;
esac


export JAVA_HOME=$(echo $JDK_ROOT/$ARCH/labsjdk-$EDITION-$VERSION.*-$TAG)/Contents/Home
if [ $ARCH = "amd64" ]; then
    export LLVM_JAVA_HOME=$(echo $JDK_ROOT/$ARCH/labsjdk-$EDITION-$VERSION.*-$TAG-sulong)/Contents/Home
    export MX_PYTHON=/usr/local/homebrew/bin/python3
else
    export MX_PYTHON=/opt/homebrew/bin/python3
fi
export GRAALVM_PROFILE="@$EDITION-$VERSION-$ARCH"
zsh

Where $HOME/jdks looks like this:

% tree $HOME/jdks -L 2
/Users/lewurm/jdks
├── aarch64
│   ├── labsjdk-ce-11.0.15-jvmci-22.1-b03
│   ├── labsjdk-ce-17.0.3-jvmci-22.1-b03
│   ├── labsjdk-ee-11.0.15-jvmci-22.1-b03
│   └── labsjdk-ee-17.0.3-jvmci-22.1-b03
├── amd64
│   ├── labsjdk-ce-17.0.3-jvmci-22.1-b03
│   ├── labsjdk-ee-11.0.15-jvmci-22.1-b03
│   ├── labsjdk-ee-11.0.15-jvmci-22.1-b03-sulong
│   ├── labsjdk-ee-17.0.3-jvmci-22.1-b03
│   └── labsjdk-ee-17.0.3-jvmci-22.1-b03-sulong
└── manual
    └── jdk-11.0.15.jdk

13 directories, 0 files

Usage:

schiggy ~
% enter_gvm aarch64 ce 17
schiggy@ce-17-aarch64 ~
% mx build
[...]

Note how the prompt of my shell picks up $GRAALVM_PROFILE accordingly. I hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants