Charm++ parallel programming system

[Rob Van der Wijngaart <robv AT nvidia.com>]

Thanks, Jozsef. Yes, I did explicitly specify gcc. It turns out that this did 
not cause the problem. Some of our systems use modules, and at some point I 
started to include the intel compiler (v18.0) in my suite of modules, while I 
still specified gcc for the Charm++ build. When I started to see problems 
today, I switched to icc, and eventually dropped down to 17.0 and 16.0, all 
to no avail. But when I removed all intel modules and switched back to gcc, 
all problems went away, and I could build Charm++/NAMD properly. I guess the 
Intel module created trouble with include paths.

Rob

-----Original Message-----
From: Jozsef Bakosi 
<jbakosi AT lanl.gov>
 
Sent: Wednesday, July 25, 2018 4:30 PM
To: Rob Van der Wijngaart 
<robv AT nvidia.com>
Cc: 
charm AT cs.illinois.edu
Subject: Re: [charm] Charm++ build trouble

Also, what is your Charm++ build command? gcc is the default on linux so you 
should not have to explicitly specify it (which if you do, might mean 
trouble).

I.e., instead of

     > ./build charm++ multicore-linux-x86_64 gcc

do 

     > ./build charm++ multicore-linux-x86_64

J

On 07.25.2018 23:23, Rob Van der Wijngaart wrote:
> Hi Jozsef,
> 
> 
> 
> Thanks for the quick reply! I looked inside tmp/config.log, and it shows 
> exactly the same error:
> 
> configure:2133: checking machine name
> 
> configure:2142: result: multicore-linux64-gcc
> 
> configure:2352: checking "cp command as"
> 
> configure:2361: result: cp -p
> 
> configure:2387: checking "C++ compiler as"
> 
> configure:2389: result: "g++  -D_REENTRANT      "
> 
> configure:2207: checking "whether C++ compiler works"
> 
> configure:2155: result: "ok"
> 
> configure:2407: checking "C++ linker as"
> 
> configure:2409: result: "g++  -D_REENTRANT      "
> 
> configure:2232: checking "whether linker works"
> 
> configure:2155: result: "ok"
> 
> configure:2419: checking "Native C++ compiler as"
> 
> configure:2421: result: "g++  -D_REENTRANT  "
> 
> configure:2423: checking "Sequential C++ compiler as"
> 
> configure:2425: result: "g++  -D_REENTRANT  "
> 
> configure:2232: checking "whether compiler accept -fno-stack-protector"
> 
> configure:2155: result: "ok"
> 
> configure:2207: checking "whether C++ compiler supports C++11 without flags"
> 
> configure:2160: result: "no"
> 
> configure:2207: checking "whether C++ compiler supports C++11 with 
> '-std=c++0x'"
> 
> configure:2160: result: "no"
> 
> configure:2207: checking "whether C++ compiler supports C++11 with 
> '-qlanglvl=extended0x'"
> 
> configure:2160: result: "no"
> 
> configure:2207: checking "whether C++ compiler supports C++11 with 
> '--c++11'"
> 
> configure:2160: result: "no"
> 
> configure:2207: checking "whether C++ compiler supports C++11 with '-h 
> std=c++11'"
> 
> configure:2160: result: "no"
> 
> 
> 
> However, charmconfig.out is more informative, see below. It looks like the 
> build uses the path to the include files for the Intel compiler, even 
> though I specified gcc for the build process. I should be able to figure 
> out now how to make sure that include path is not used. Thanks for the 
> pointer!
> 
> 
> 
> Rob
> 
> 
> g++ -D_REENTRANT -I../include -I. -c test.cpp -o test.o -std=c++0x
> In file included from /usr/include/c++/4.8.2/cstdint:41:0,
>                  from /usr/include/c++/4.8.2/bits/char_traits.h:376,
>                  from /usr/include/c++/4.8.2/string:40,
>                  from /usr/include/c++/4.8.2/stdexcept:39,
>                  from /usr/include/c++/4.8.2/array:38,
>                  from /usr/include/c++/4.8.2/tuple:39,
>                  from /usr/include/c++/4.8.2/bits/stl_map.h:63,
>                  from /usr/include/c++/4.8.2/map:61,
>                  from test.cpp:3:
> /cm/shared/apps/intel/compilers_and_libraries_2018.1.163/linux/compiler/include/stdint.h:43:54:
>  error: missing binary operator before token "("
>      defined(__has_include_next) && __has_include_next(<stdint.h>)
>                                                       ^
> /cm/shared/apps/intel/compilers_and_libraries_2018.1.163/linux/compile
> r/include/stdint.h:285:10: error: 'int__INTPTR_WIDTH___t' does not name a 
> type typedef  __intn_t(__INTPTR_WIDTH__)  intptr_t;
>           ^
> /cm/shared/apps/intel/compilers_and_libraries_2018.1.163/linux/compile
> r/include/stdint.h:292:9: error: 'uint__INTPTR_WIDTH___t' does not name a 
> type typedef __uintn_t(__INTPTR_WIDTH__) uintptr_t;
>          ^
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Jozsef Bakosi 
> <jbakosi AT lanl.gov>
> Sent: Wednesday, July 25, 2018 3:30 PM
> To: Rob Van der Wijngaart 
> <robv AT nvidia.com>
> Cc: 
> charm AT cs.illinois.edu
> Subject: Re: [charm] Charm++ build trouble
> 
> 
> 
> Hi Rob,
> 
> 
> 
> Sometimes I find that error message misleading. Take a look at 
> tmp/charmconfig.out and config.log, those might give you a better clue on 
> what's going wrong.
> 
> 
> 
> Jozsef
> 
> 
> 
> On 07.25.2018 22:18, Rob Van der Wijngaart wrote:
> 
> > Hello all,
> 
> >
> 
> > I am running into some trouble building Charm++. I've built it on my 
> > system before as part of my NAMD build, and am not sure if anything has 
> > changed, but now the Charm++ build breaks. The error is highlighted in 
> > the snippet from the output of the build process below. Apparently, the 
> > error checking believes that the C++ compiler does not support the flag 
> > -std=c++0x. However, when I use it on the command line, everything is 
> > hunky dory. Do you have any suggestions for how to troubleshoot/fix the 
> > problem? Thanks.
> 
> >
> 
> > Rob
> 
> >
> 
> > [robv@psgcluster build_temp]$ cat temp.c #include <stdio.h> int
> 
> > main(int argc, char **argv) {
> 
> >   printf("Hello\n");
> 
> > }
> 
> > [robv@psgcluster build_temp]$ g++ -std=c++0x temp.c [robv@psgcluster
> 
> > build_temp]$ ./a.out Hello
> 
> >
> 
> >
> 
> > Selected Compiler: gcc
> 
> > Selected Options:
> 
> > Copying src/scripts/Makefile to multicore-linux64-gcc/tmp 
> > Soft-linking
> 
> > over bin Soft-linking over lib Soft-linking over lib_so Soft-linking
> 
> > over include Soft-linking over tmp Generating
> 
> > multicore-linux64-gcc/tmp/conv-mach-pre.sh
> 
> > Performing '/usr/bin/gmake -j 40 basics OPTS=-optimize -production
> 
> > QUIET= CONFIG_OPTS=--disable-controlpoint --disable-tracing
> 
> > --disable-tracing-commthread --dis\ able-charmdebug --disable-replay
> 
> > --disable-error-checking --disable-stats --enable-tracing' in
> 
> > multicore-linux64-gcc/tmp /usr/bin/gmake -C topomanager -f
> 
> > Makefile_charm headers
> 
> > gmake[1]: Entering directory 
> > `/home/robv/apps/build_temp/charm-v6.8.2/multicore-linux64-gcc/tmp/topomanager'
> 
> > gmake[1]: Nothing to be done for `headers'.
> 
> > gmake[1]: Leaving directory 
> > `/home/robv/apps/build_temp/charm-v6.8.2/multicore-linux64-gcc/tmp/topomanager'
> 
> > /usr/bin/gmake charmxi
> 
> > gmake[1]: Entering directory 
> > `/home/robv/apps/build_temp/charm-v6.8.2/multicore-linux64-gcc/tmp'
> 
> > ./configure --disable-controlpoint --disable-tracing
> 
> > --disable-tracing-commthread --disable-charmdebug --disable-replay
> 
> > --disable-error-checking --disable-stats \ --enable-tracing Error
> 
> > checking is disabled AMPI error checking is enabled Statistics
> 
> > collection is disabled Charm tracing is enabled Charm tracing
> 
> > communication thread is disabled CharmDebug is disabled Charm
> 
> > record/replay is disabled CCS is enabled Charm control point is
> 
> > disabled Charm LB user data is disabled Charm shrink expand is
> 
> > disabled Setting load balancing timer type as 'double'
> 
> > checking machine name... multicore-linux64-gcc checking "cp command
> 
> > as"... cp -p
> 
> > checking "C++ compiler as"... "g++  -D_REENTRANT      "
> 
> > checking "whether C++ compiler works"... "ok"
> 
> > checking "C++ linker as"... "g++  -D_REENTRANT      "
> 
> > checking "whether linker works"... "ok"
> 
> > checking "Native C++ compiler as"... "g++  -D_REENTRANT  "
> 
> > checking "Sequential C++ compiler as"... "g++  -D_REENTRANT  "
> 
> > checking "whether compiler accept -fno-stack-protector"... "ok"
> 
> > checking "whether C++ compiler supports C++11 without flags"... "no"
> 
> > checking "whether C++ compiler supports C++11 with '-std=c++0x'"... "no"
> 
> > checking "whether C++ compiler supports C++11 with 
> > '-qlanglvl=extended0x'"... "no"
> 
> > checking "whether C++ compiler supports C++11 with '--c++11'"... "no"
> 
> > checking "whether C++ compiler supports C++11 with '-h std=c++11'"... "no"
> 
> > Charm++ requires some C++11 support, but doesn't know the flag to
> 
> > Charm++ enable it
> 
> ----------------------------------------------------------------------
> ------------- This email message is for the sole use of the intended 
> recipient(s) and may contain confidential information.  Any 
> unauthorized review, use, disclosure or distribution is prohibited.  
> If you are not the intended recipient, please contact the sender by 
> reply email and destroy all copies of the original message.
> ----------------------------------------------------------------------
> -------------