Re-compiling chapel-1.33.0

Users
1

Hello,

Yesterday I upgraded my development machine and now I'm getting this error:

mason build
Skipping registry update since no dependency found in manifest file.
ld-elf.so.1: /usr/local/llvm15/lib/libLLVM-15.so: Unsupported relocation type 1044473 in non-PLT relocations

Error while getting Chapel version:
Failed to run 'chpl --version'

I decided to re-build chapel-1.33 from a cleanly unpacked tarball. I run:

source util/setchplenv.bash
export CHPL_COMM=gasnet
gmake

and get

Making the compiler...
cd llvm && gmake unset
Error: Please set the environment variable CHPL_LLVM to a supported value.
Supported values are:
  1) 'none' to build with minimal LLVM support
  2) 'bundled' to build with the LLVM packaged in the third-party directory
  3) 'system' to use a pre-installed system-wide LLVM
     Currently supported LLVM versions are: 15, 14, 13, 12, 11, 16
See: https://chapel-lang.org/docs/latest/usingchapel/chplenv.html#chpl-llvm

I set CHPL_LLVM:

export CHPL_LLVM=system

Now gmake fails like this:

Making the compiler...

Error: Could not find clang with the same version as CHPL_LLVM_CONFIG=llvm-config15. Please try setting CHPL_TARGET_CC.
/usr/home/rmason/Software/Chapel/chapel-1.33.0/make/Makefile.base:106: *** error running util/printchplenv -- please see error above.  Stop.

I do export CHPL_TARGET_CC=/usr/local/bin/clang15
and theng make fails again

Making the compiler...

Error: Could not find clang++ with the same version as CHPL_LLVM_CONFIG=llvm-config15. Please try setting CHPL_TARGET_CXX.

After doing export CHPL_TARGET_CXX=/usr/local/bin/clang++15 gmake still fails:

Making the compiler...

Error: Missing or wrong version for clang at /usr/local/bin/clang15
/usr/home/rmason/Software/Chapel/chapel-1.33.0/make/Makefile.base:106: *** error running util/printchplenv -- please see error above.  Stop.

What is the magic incantation to get chapel to build again?

Thanks for your help.
Roger

2

Hi Roger —

I'm looking for someone to help with this. In the meantime, what does /usr/local/bin/clang15 --version give you?

Thanks,
-Brad

3

Roger —

Oh, and the version reported by llvm-config15 --version would be useful as well.

-Brad

4

Hi Roger,

Can you also run the following and post the output, without explicitly setting CHPL_TARGET_CXX or CHPL_TARGET_CC?

source util/setchplenv.bash
export CHPL_COMM=gasnet
$CHPL_HOME/util/printchplenv --anonymize --all --internal
export CHPL_LLVM=system
$CHPL_HOME/util/printchplenv --anonymize --all --internal

Thanks,
-Jade

5

Hello Brad, Jade,

A reboot seems to have fixed the problem. I'm surprised because the OS update I performed should not have touched compilers etc. There is one remaining problem:

Building Mason...
error: The runtime has not been built for this configuration. Run $CHPL_HOME/util/chplenv/printchplbuilds.py for information on available runtimes.

The output of the indicated Python script is:

                       <Current>              0                 
     CHPL_TARGET_PLATFORM: freebsd              freebsd             
     CHPL_TARGET_COMPILER: llvm                 llvm                
         CHPL_TARGET_ARCH: amd64                amd64               
          CHPL_TARGET_CPU: unknown              unknown             
        CHPL_LOCALE_MODEL: flat                 flat                
                CHPL_COMM: gasnet               gasnet              
          CHPL_COMM_DEBUG: -                    -                   
      CHPL_COMM_SUBSTRATE: udp                  udp                 
      CHPL_GASNET_SEGMENT: everything           everything          
      CHPL_GASNET_VERSION: 1                    NA*                 
               CHPL_TASKS: fifo                 NA*                 
         CHPL_TASKS_DEBUG: -                    NA*                 
              CHPL_TIMERS: generic              generic             
              CHPL_UNWIND: none                 none                
                 CHPL_MEM: jemalloc             jemalloc            
             CHPL_ATOMICS: cstdlib              cstdlib             
               CHPL_HWLOC: none                 none                
                 CHPL_RE2: bundled              bundled             
         CHPL_AUX_FILESYS: none                 none                
             CHPL_LIB_PIC: none                 none                
        CHPL_SANITIZE_EXE: none                 none                
                    MTIME: NA                   Feb 17 07:48

Does this mean I must rebuild Chapel to build Mason? If so, is there a recommended way to switch between multiple runtimes?

Thank you,
Roger

1 Like
6

Hi Roger —

Glad you were able to get past those mysterious errors, though now you're going to just encourage us to start giving the typical IT support answer: "Did you turn it off and turn it back on again?" :slight_smile:

Thanks for providing the output of that script. As you can see, most rows match, though the "NA*" entries in the second column are unfamiliar to me; and the one in the CHPL_TASKS row is particularly surprising to me since that setting is typically important and applicable. I'm not expert enough in that script to know how to interpret that offhand, and am hoping someone else on the team can help out with that after the holiday weekend (we have Monday off).

Do you have any CHPL_* environment variables set other than CHPL_HOME?

Typically, when this error occurs, it can be resolved by just doing cd $CHPL_HOME && make runtime to rebuild the runtime with your current settings. However, given that it sounds as though you had just done a build from scratch, I'm not confident that it will help... Still, it's worth a try. Given my concerns about CHPL_TASKS, I also wonder whether setting that explicitly to fifo and rebuilding would help?

I'll note that if you're not actively using mason, not being able to build it is probably not the end of the world. That is, lack of mason won't prevent other Chapel features from working. I'm going to see if I can find someone familiar with the mason build to take a look here, though.

It is possible to maintain multiple distinct runtimes at once, as the lib directory structure where the binaries are stored are made unique by things like CHPL_COMM, CHPL_MEM, CHPL_TASKS and such settings that make each instance different (this is why I'm not clear on why CHPL_TASKS would be saying NA).

The ways I use to switch between them are simply to set the CHPL_ variables the way I want them, typically by creating little bash scripts that I can source to get my favorite configurations.

Now that you've asked, I'm remembering that the printchplbuilds.py script supports --bash and --csh options that take a configuration number (the '0' in the second column of your table) and give you the commands for the respective shell to set up that configuration. I'm not familiar enough with this feature to know how that interacts with the NA entries, however. @jhh67 is probably the expert here

Have a good weekend,
-Brad

7

I think the problem with the mason build is that since mason is meant to run on the same system as the compiler (vs on a compute node e.g.) it always builds with CHPL_COMM=none. I would expect that doing CHPL_COMM=none make would resolve your issue, but if not, you could make sure that the default configuration with CHPL_COMM=none is built:

# in a separate terminal window
# first, unset any CHPL_ variables you have set
unset CHPL_COMM
# build local version in default configuration
source util/setchplenv.bash
make # or, make -j20 etc if you like

Note that mason needs CHPL_RE2=bundled, so it won't build in the quickstart configuration.

8

It appears the printchplbuild.py script has a bug, the “NA*” for CHPL_TASKS is incorrect. I will look into it. The Chapel build system can support multiple runtimes, which is what this script is trying to show. You build different runtimes by setting the various CHP_ variables appropriately, then you can switch between runtimes when compiling Chapel programs by re-setting those variables. So, for example, I can build one runtime with CHPL_COMM=none and another with CHPL_COMM=gasnet, then when I compile a Chapel program it will use the appropriate runtime based on the value of that variable.

John

9

Hello Brad,

Bradcray via Chapel Programming Language notifications@chapel.discoursemail.com writes:

Glad you were able to get past those mysterious errors, though now
you're going to just encourage us to start giving the typical IT
support answer: "Did you turn it off and turn it back on again?"
:slight_smile:

:slight_smile:

It is possible to maintain multiple distinct runtimes at once, as the
lib directory structure where the binaries are stored are made unique
by things like CHPL_COMM, CHPL_MEM, CHPL_TASKS and such settings that
make each instance different (this is why I'm not clear on why
CHPL_TASKS would be saying NA).

The ways I use to switch between them are simply to set the CHPL_ variables the way I want them, typically by
creating little bash scripts that I can source to get my favorite configurations.

Now that you've asked, I'm remembering that the printchplbuilds.py
script supports --bash and --csh options that take a configuration
number (the '0' in the second column of your table) and give you the
commands for the respective shell to set up that configuration. I'm
not familiar enough with this feature to know how that interacts with
the NA entries, however. @jhh67 is probably the expert here

Thanks very much for this info. I have now set up my shell to detect
NIC functionalty and set serial /vs/ parallel chapel accordingly.

Best wishes,
Roger

1 Like
10

Hello Michael,

Michael Ferguson via Chapel Programming Language notifications@chapel.discoursemail.com writes:

I think the problem with the mason build is that since mason is meant
to run on the same system as the compiler (vs on a compute node e.g.)
it always builds with CHPL_COMM=none. I would expect that doing
CHPL_COMM=none make would resolve your issue, but if not, you could
make sure that the default configuration with CHPL_COMM=none is built:

in a separate terminal window

first, unset any CHPL_ variables you have set

unset CHPL_COMM

build local version in default configuration

source util/setchplenv.bash
make # or, make -j20 etc if you like

Note that mason needs CHPL_RE2=bundled, so it won't build in the quickstart configuration.

Thank you for your help. I think I have now set up my development
machine to handle different configs. Unfortunately -j20 is just a
dream.

Best wishes,
Roger

1 Like
11

Hell John,

John Hartman via Chapel Programming Language notifications@chapel.discoursemail.com writes:

It appears the printchplbuild.py script has a bug, the “NA*” for
CHPL_TASKS is incorrect. I will look into it. The Chapel build system
can support multiple runtimes, which is what this script is trying to
show. You build different runtimes by setting the various CHP_
variables appropriately, then you can switch between runtimes when
compiling Chapel programs by re-setting those variables. So, for
example, I can build one runtime with CHPL_COMM=none and another with
CHPL_COMM=gasnet, then when I compile a Chapel program it will use the
appropriate runtime based on the value of that variable.

Thank you. I think I understand better now. I have set up a couple of
scripts on my development machine to handle this.

Best wishes,
Roger

12

Hi Roger —

Glad to hear that you've had some improvements here. Please let us know if there are any other outstanding issues or surprises.

For what it's worth, I find even -j4 or -j8 to be a nice boost over a vanilla make for me.

-Brad