[Bug]: Runtime Install Directory Not Created On Linux aarch64

[insertinterestingnamehere]

There are some missing install directories when building and installing on a Linux aarch64 system (RHEL8). This results in the "The runtime has not been built for this configuration." error showing up when trying to call the chapel compiler. I looked into the error a bit and it's trying to find an install directory that's supposed to be there.

Here's the relevant bit of the build script I'm using:

export CHPL_LLVM=system
export CC=clang
export CXX=clang++
export CFLAGS="-g $CFLAGS"
export CXXFLAGS="-g $CXXFLAGS"
cd chapel
git clean -fdx
git clean -fdX
./autoconf
./configure --prefix="$PREFIX"
make -j12
make install

When I run this on a similarly configured x86_64 machine the directory $PREFIX/lib/chapel/2.2/runtime/lib/linux64 gets created whereas on an aarch64 it does not. Only $PREFIX/lib/chapel/2.2/runtime/lib/compiler is created in that case. The "The runtime has not been built for this configuration." error shows up because the compiler tries to find a lengthy subdirectory of this that doesn't actually exist.

[bradcray]

@insertinterestingnamehere : Can you supply the output of util/printchplenv --all --anonymize after you've made your export settings (and/or after you've done all of the above… it shouldn't matter). I'd also be curious for the output from util/chplenv/printchplbuilds.py.

[jabraham17]

In addition to the printchplenv output in the build directory, can you also supply the printchplenv ouput from the install directory?

$PREFIX/share/chapel/2.2/util/chplenv/printchplenv.py
CHPL_HOME=$PREFIX/share/chapel/2.2 $PREFIX/share/chapel/2.2/util/chplenv/printchplbuilds.py

[insertinterestingnamehere]

Here's the result of using the one in the source tree, generic-izing my home directory out:

CHPL_HOME: ~/chapel
script location: ~/chapel/util/chplenv
CHPL_TARGET_PLATFORM: linux64
CHPL_TARGET_COMPILER: llvm
CHPL_TARGET_ARCH: aarch64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_GMP: bundled
CHPL_HWLOC: bundled
CHPL_RE2: bundled
CHPL_LLVM: system +
CHPL_AUX_FILESYS: none

Here's the result of using the installed one with the prefix marked.

CHPL_HOME: $PREFIX/share/chapel/2.2
script location: $PREFIX/share/chapel/2.2/util/chplenv
CHPL_TARGET_PLATFORM: linux64
CHPL_TARGET_COMPILER: llvm
CHPL_TARGET_ARCH: aarch64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_GMP: none
CHPL_HWLOC: bundled
CHPL_RE2: none
CHPL_LLVM: system +
CHPL_AUX_FILESYS: none

So the results are slightly different. GMP and RE2 aren't bundled in the installed version and CHPL home is based on the install directory.

[jabraham17]

GMP and RE2 aren't bundled in the installed version

Yeah, I realized this was a bug after I mentioned running those scripts. See #25874. That should not affect the lib directory being missing though. If you run chpl --print-chpl-settings you should see GMP and RE2 match.

CHPL home is based on the install directory

Thats expected, CHPL_HOME in the installed version should be PREFIX/share/chapel/2.2

[jabraham17]

I have been so far unable to reproduce this using rockylinux 8 (the closest to RHEL8 I can get easily) on aarch64.

I did this inside a docker container

FROM rockylinux/rockylinux:8

RUN dnf upgrade -y && dnf install -y --allowerasing sudo vim which
RUN dnf upgrade -y && \
    dnf install -y --allowerasing \
      gcc gcc-c++ m4 perl python3 python3-devel bash make gawk git cmake \
      which diffutils wget vim sudo \
      llvm-devel clang clang-devel

RUN git clone https://github.com/chapel-lang/chapel.git --depth 1 --branch main

I then ran the commands from the OP and had no issues.

Can you check the whole build log and make sure there are no build errors during make, causing make install to not have a full chapel build to install.

[insertinterestingnamehere]

Thanks for checking! I did check the build log and didn't see anything that looked at all like an error. I'll try debugging this some more locally and see if I can get more info on what's going on.

[jabraham17]

Hi @insertinterestingnamehere, per offline conversations I think you have uncovered the root problem of this to be due to a make vs gmake version inconsistency, which I have captured in #25891. I think that means this particular issue is resolved?

[insertinterestingnamehere]

Yep, that issue is an excellent summary. Thank you!