search

charmplusplus / charm

The Charm++ parallel programming system. Visit https://charmplusplus.org/ for more information.
Apache License 2.0
199 stars 50 forks source link

can't build charm4py build with clang #3809

Open ritvikrao opened 2 months ago

ritvikrao commented 2 months ago

When attempting to build the charm4py version of charm++ using the clang compiler, I get an error because one of the clang commands uses a flag that is gcc-specific.

I tried this build using Frontier.

Build command: ./build charm4py mpi-linux-x86_64 --with-production -j8

Error:

clang-15: error: unknown argument: '-fno-lifetime-dse'
Fatal Error by charmc in directory /ccs/home/rrao/charm4py/charm_src/charm/mpi-linux-x86_64
   Command mpicxx -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -I/ccs/home/rrao/charm4py/charm_src/charm/mpi-linux-x86_64/include -D__CHARMC__=1 -DAMPI_ERRHANDLER_RETURN=0 -DNDEBUG -O2 -U_FORTIFY_SOURCE -fno-stack-protector -fno-lifetime-dse -ftls-model=initial-exec -std=gnu++11 -fpic -O3 -std=gnu++11 -MD -MT CMakeFiles/ldb-rand.dir/src/conv-ldb/cldb.rand.C.o -MF CMakeFiles/ldb-rand.dir/src/conv-ldb/cldb.rand.C.o.d -c /ccs/home/rrao/charm4py/charm_src/charm/src/conv-ldb/cldb.rand.C -o CMakeFiles/ldb-rand.dir/src/conv-ldb/cldb.rand.C.o returned error code 1
charmc exiting...

Modules:

Currently Loaded Modules:
  1) craype-x86-trento        5) xpmem/2.6.2-2.5_2.22__gd067c3f.shasta   9) cray-dsmml/0.2.2       13) darshan-runtime/3.4.0  17) cray-mrnet/5.0.4
  2) libfabric/1.15.2.0       6) cray-pmi/6.1.8                         10) cray-mpich/8.1.23      14) hsi/default            18) valgrind4hpc/2.12.10
  3) craype-network-ofi       7) cce/15.0.0                             11) cray-libsci/22.12.1.1  15) lfs-wrapper/0.0.1      19) cray-python/3.11.5
  4) perftools-base/22.12.0   8) craype/2.7.19                          12) PrgEnv-cray/8.3.3      16) DefApps/default

The current workaround is to switch to the gcc compiler with:

module swap PrgEnv-cray PrgEnv-gnu

but this error may show up on other platforms when using clang. I think the build process needs to be changed to use the appropriate flag based on the compiler.

ericjbohm commented 1 month ago

This represents a slight misunderstanding of the build system, but also an interesting dilemma that could be handled better. The default compiler for our build system is gnu. The recommended approach for using something other than gnu is to pass that compiler name as parameter to the build system.

Cray/HPE programming environments further complicate this matter by allowing you to change the default compiler in your environment. But not all deployments make the same choices (NCSA Delta is notably different and I've heard El Capitan is different in other ways). We could try to autodetect which compiler is actually in use and make choices accordingly, but that is an inherently fragile approach that we cannot future proof.

Have you tried building explicitly with clang as a parameter?