Chapel: Importing Chapel python module on Cray-CS gives undefined symbol error

[ben-albrecht]

Summary of Problem

Importing a Chapel-built python module on a Cray-CS with CHPL_REGEXP=re2 can result in an error upon importing:

/lus/snx11049/balbrecht/crayai/lib/a.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE

Steps to Reproduce

Source Code:

I have only been able to reproduce this error when the code involves a formatted print (makes sense, as it's related to CHPL_REGEXP):

export proc f() {
  var err = "ImportError: /lus/snx11049/balbrecht/crayai/lib/a.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE";
  writeln("Formatted IO causes this error:\n%s".format(err));
}

Compile command:

chpl foo.chpl --library-python

Execution command:

cd libfoo/
python
> import foo
/lus/snx11049/balbrecht/crayai/lib/a.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE

Configuration Information

• Output of chpl --version: chpl version 1.20.1 (ce2f672)
• Output of $CHPL_HOME/util/printchplenv --anonymize:

CHPL_TARGET_PLATFORM: linux64
CHPL_TARGET_COMPILER: gnu
CHPL_TARGET_ARCH: x86_64
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: intrinsics
CHPL_GMP: none
CHPL_HWLOC: hwloc
CHPL_REGEXP: re2
CHPL_LLVM: none
CHPL_AUX_FILESYS: none

• Back-end compiler and version, e.g. gcc --version or clang --version:

gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

• (For Cray systems only) Output of module list:

Currently Loaded Modulefiles:
  1) craype-network-infiniband   2) craype-ivybridge            3) slurm/default

[ben-albrecht]

We encountered this issue on Crays in the past, and it was addressed specifically for XCs in https://github.com/chapel-lang/chapel/pull/11719. However, still have the issue on Cray-CS machines.

One work-around is to set CHPL_REGEXP=none.

Alternatively, @ronawho suggested using the gcc module (module load gcc) and adding the following temporary work-around, which links stdc++ explicitly:

diff --git a/runtime/etc/Makefile.include b/runtime/etc/Makefile.include
index 2207118..3caed2f 100644
--- a/runtime/etc/Makefile.include
+++ b/runtime/etc/Makefile.include
@@ -124,7 +124,7 @@ printlinkershared:

 printlibraries:
        @echo $(GEN_LFLAGS) $(COMP_GEN_LFLAGS) -L$(CHPL_RT_LIB_DIR) \
-             -lchpl $(LIBS) -lm $(CHPL_MAKE_THIRD_PARTY_LINK_ARGS) $(CHPL_MAKE_BASE_LFLAGS)
+             -lchpl -lstdc++ $(LIBS) -lm $(CHPL_MAKE_THIRD_PARTY_LINK_ARGS) $(CHPL_MAKE_BASE_LFLAGS)

 printlinker:
        @echo $(LD)

I have confirmed that this works. This is probably a good starting point for whoever develops a more principled solution,

[lydia-duncan]

I believe we already do that for multilocale interoperability, but @dlongnecke-cray should correct me if I'm wrong

[ben-albrecht]

@lydia-duncan - If that's the case, are you suggesting we just need to port that change to the CHPL_COMM=none case as well?

[lydia-duncan]

The reason we added it for multilocale interop was due to requirements for other parts of the implementation, but the change is simple enough that I suppose you could phrase it that way

[ben-albrecht]

I'll note that this issue has raised in our priorities recently, since the newly added weighted HPO metrics feature depends on CHPL_REGEXP=re2.