Compile with GCC on BlueGene/Q

LAMMPS LAMMPS Mailing List Mirror
1

Dear users,

i try to compile LAMMPS on BlueGene/Q.

I managed to build it as a static lib with the
mpicxx compiler wrappers successfully.
Also the examples in COUPLE work for me,
when compiling it manually as indicated
in the README.

However, if I try to link the liblammps.a
in another CMakeProject, I fail in the end
with ```undefined references to MPI_Send```
and to some other MPI functions.

If I look into the liblammps.a by the tool
nm, I see exactly those undefined references
marked by a capital U.

I don't see the failure, since I compile
my CMakeProject also with mpicxx wrappers,
and this links fine to MPI in the end.

Do you have any suggestions? I mean
this suggests to me an MPI version
mismatch somehow.

Best,
Stephan

2

If you build LAMMPS as a static lib, then you have to provide
the MPI lib (or any other external iib) explicitly when you
link your final application (your code + LAMMPS + list of external libs).

It sounds like you do that for just LAMMPS (e.g. the couple apps).

If you can’t do it for your code, then it seems like the error is
either in your code (the way you built it), or the MPI lib you
are providing when you link (which would need to be compatible
with the mpi.h file used when you built LAMMPS as a static lib).

Steve

3

Dear Steve,

so you mean I need to make sure, that my final application
uses the exact same MPI version as I use when building LAMMPS.

So, I should figure out, which exact mpi.h is used during building
my custom code, then override the MPI_INC setting in the LAMMPS
Makefile.mpi to be sure, right?

As it seems to me, it is not enough to just specify the
mpicxx wrappers in my case, though it should be sufficient IMHO.

Best,
Stephan

If you build LAMMPS as a static lib, then you have to provide the
MPI lib (or any other external iib) explicitly when you link your
final application (your code + LAMMPS + list of external libs).

It sounds like you do that for just LAMMPS (e.g. the couple apps).

If you can't do it for your code, then it seems like the error is
either in your code (the way you built it), or the MPI lib you are
providing when you link (which would need to be compatible with
the mpi.h file used when you built LAMMPS as a static lib).

Steve

Dear users,

i try to compile LAMMPS on BlueGene/Q.

I managed to build it as a static lib with the mpicxx compiler
wrappers successfully. Also the examples in COUPLE work for me,
when compiling it manually as indicated in the README.

However, if I try to link the liblammps.a in another CMakeProject,
I fail in the end with ```undefined references to MPI_Send``` and
to some other MPI functions.

If I look into the liblammps.a by the tool nm, I see exactly those
undefined references marked by a capital U.

I don't see the failure, since I compile my CMakeProject also with
mpicxx wrappers, and this links fine to MPI in the end.

Do you have any suggestions? I mean this suggests to me an MPI
version mismatch somehow.

Best, Stephan

---------------------------------------------------------------------

- ---------

Monitor Your Dynamic Infrastructure at Any Scale With Datadog!

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Steve,

so you mean I need to make sure, that my final application
uses the exact same MPI version as I use when building LAMMPS.

​*always*. but if you have a mismatch there, you will get a different
linker error than the one you quoted.​

So, I should figure out, which exact mpi.h is used during building
my custom code, then override the MPI_INC setting in the LAMMPS
Makefile.mpi to be sure, right?

​no. using the same mpicxx/mpicc/mpif77 wrapper ​should be sufficient.
playing with MPI_INC should only be needed, if you have a broken MPI
installation.

As it seems to me, it is not enough to just specify the
mpicxx wrappers in my case, though it should be sufficient IMHO.

​i agree, it should be sufficient. i would look more carefully into what
your build system is doing and perhaps try to issue the linker command
manually​. after, all, if you manage to link the couple examples, there
should not be a systematic difference. perhaps, somehow the linker command
is due to some accident not set to mpicxx in your build system.

axel.

5

Dear Axel,

thanks for your keen suggestions!

Apparently, something is kinda screwed when CMAKE links
statically the liblammps.a to our framework (in a certain
stage). I could adjust by your suggestion the linker
command and got it to work somehow for now (still need
to figure out why it now works - in the dynamic case
it already worked, but on big machines static linking is
mandatory for me as it consumes otherwise to much Wall clock).

In addition the mpicxx was pointing to IBM XL compiler
tools, not to the GNU GCC compiler tools, this explains
another linking mismatch I encountered (not shown here)
where IBM XL and GCC MPI where intermingled and thus linking failed.
(This should be a reminder for people using JUQUEEN supercomputer,
that you need to make sure, for instance by ```type -a```, that
you've got the correct executables at hands when compiling/linking).

Best regards,
and again my apologies,

Stephan

Dear Steve,

so you mean I need to make sure, that my final application uses the
exact same MPI version as I use when building LAMMPS.

​*always*. but if you have a mismatch there, you will get a
different linker error than the one you quoted.​

So, I should figure out, which exact mpi.h is used during building
my custom code, then override the MPI_INC setting in the LAMMPS
Makefile.mpi to be sure, right?

​no. using the same mpicxx/mpicc/mpif77 wrapper ​should be
sufficient. playing with MPI_INC should only be needed, if you
have a broken MPI installation.

As it seems to me, it is not enough to just specify the mpicxx
wrappers in my case, though it should be sufficient IMHO.

​i agree, it should be sufficient. i would look more carefully
into what your build system is doing and perhaps try to issue the
linker command manually​. after, all, if you manage to link the
couple examples, there should not be a systematic difference.
perhaps, somehow the linker command is due to some accident not
set to mpicxx in your build system.

axel.

Best, Stephan

If you build LAMMPS as a static lib, then you have to provide
the MPI lib (or any other external iib) explicitly when you
link your final application (your code + LAMMPS + list of
external libs).

It sounds like you do that for just LAMMPS (e.g. the couple
apps).

If you can't do it for your code, then it seems like the
error is either in your code (the way you built it), or the
MPI lib you are providing when you link (which would need to
be compatible with the mpi.h file used when you built LAMMPS
as a static lib).

Steve

Dear users,

i try to compile LAMMPS on BlueGene/Q.

I managed to build it as a static lib with the mpicxx
compiler wrappers successfully. Also the examples in COUPLE
work for me, when compiling it manually as indicated in the
README.

However, if I try to link the liblammps.a in another
CMakeProject, I fail in the end with ```undefined references
to MPI_Send``` and to some other MPI functions.

If I look into the liblammps.a by the tool nm, I see exactly
those undefined references marked by a capital U.

I don't see the failure, since I compile my CMakeProject also
with mpicxx wrappers, and this links fine to MPI in the end.

Do you have any suggestions? I mean this suggests to me an
MPI version mismatch somehow.

Best, Stephan

------------------------------------------------------------------

- ---

- ---------

Monitor Your Dynamic Infrastructure at Any Scale With Datadog!

Get real-time metrics from all of your servers, apps and
tools in one place. SourceForge users - Click here to start
your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140

_______________________________________________ lammps-users

mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/lammps-users

---------------------------------------------------------------------

- ---------