Hi Jintack --
I don't do enough Chapel over GASNet over MPI work myself to know
precisely what the problem is (and don't have a build handy that I can
play with to learn more), but here are some notes that will hopefully help
you make progress, and perhaps someone with more experience in this area
can chime in as well.
> ...it looks like we need mpi based on the chapel lanucher setting above?
The first thing I wanted to note is that the use of a Chapel launcher is
completely optional. Launchers are designed to hide things like mpirun,
aprun, srun, qsub, and the like for typical users, but for configurations
that we don't use and test regularly, coverage is spottier than for those
we do (which is to say, the launcher may not work well or exist at all).
Put another way, you should be able to use any of the launchers that
GASNet provides to start a Chapel program, we simply not support a
particular choice (yet), or we may not support it very well.
Since it's a FAQ I'll point out that if you're using a launcher and
compile a program, say with '-o foo', then 'foo' will be the launcher
binary wrapping mpirun, aprun, amudprun, or whatever; and 'foo_real' will
be the binary that implements your Chapel program. If you're not using a
launcher (i.e., CHPL_LAUNCHER is 'none') then 'foo' will simply be the
binary that implements your Chapel program.
You can launch a program manually without using a Chapel-specific launcher
option, and may need to for conduits/configurations we don't have good
coverage for. You can do this either by setting CHPL_LAUNCHER=none and
running the launch command manually yourself on the generated 'foo'
binary, or by compiling with a launcher and launching the 'foo_real'
binary manually.
Most launchers support verbose output which will print what they are doing
under the covers so that you can customize the command yourself. For
example, I'm using the 'amudprun' launcher right now and running with
--verbose, I get a line like this:
chapel/third-party/gasnet/install/darwin-clang-unknown/seg-everything/nodbg/bin/amudprun
-np 2 ./a.out_real -nl 2 --verbose
So I can take that line and replace the 'amudprun' command with some other
launcher if necessary/desired. I can also set CHPL_COMM to none,
recompile my program, and use the line above with the '_real' in it to
launch the resulting binary.
Note that we're always happy to have people contribute improvements to the
existing launcher code back, or to contribute new launcher options. For
reference, this code lives in $CHPL_HOME/runtime/src/launch/
> Paul said it looks like Chapel is not using mpicc as its linker.
As a general tip, you can see the commands Chapel is using to compile and
link the generated code using 'chpl --print-commands ...' when you
compile. And/or, you can use 'chpl --savec <dir name> ...' to save the
compiler-generated C code and Makefile stub and then 'make -f <dir
name>/Makefile' to recompile as necessary.
With respect to the choice of linker, looking at the Makefiles, it appears
that we attempt to set LD to GASNET_LD when we're compiling for GASNet;
but Makefiles are notoriously easy to break / mis-read, so I'd
double-check that I've got that right as follows:
compile with the --savec option as described above
make -f <dir name>/Makefile print-CC print-LD print-GASNET_LD
print-GASNET_INC_MAKEFILE
which should print the values of a bunch of key Makefile variables.
Assuming CC is 'mpicc' as we'd guess, but LD is not, the question would be
whether GASNET_LD set to 'mpicc' and/or is GASNET_INC_MAKEFILE pointing to
the right GASNet Makefile stub and/or is that Makefile stub setting
GASNET_LD properly. Let us know what you find.
Finally, as a complete hack and fallback, the Makefile line that Chapel
uses to link the binary is in runtime/etc/Makefile.exe. Look for the line
starting with $(LD). Rewriting that line would change the link line we
generate. But my preference would be to understand what's going wrong and
fix it in the source base for other users rather than have you hack around
the issue if at all possible.
Hope this is helpful,
-Brad
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
