-lifcore not found

LAMMPS LAMMPS Mailing List Mirror
1

Dear All,

I have compiled lammps in a linux cluster by using the guidance of user manual, but only one error is showing -

"…/usr/bin/ld: cannot find -lifcore
collect2: ld returned 1 exit status
make[1]: *** […/lmp_linux] Error 1
make[1]: Leaving directory `/export/rahul/lammps/lammps-26May13/src/Obj_linux’
make: *** [linux] Error 2
"

can you make suggestion for this, I have tried a lot in mail list but not found. Please help.

ADD info:

mY MAKE FILE IS HERE:

linux = RedHat Linux box, mpicc, FFTW

SHELL = /bin/sh

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

compiler/linker settings

specify flags and libraries needed for your compiler

CC = /opt/LinuxSoftwares/openmpi-1.6.4/prefix/bin/mpicc
CCFLAGS = -g -O -I/opt/LinuxSoftwares/fftw-2.1.5/prefix/include -DFFT_FFTW -DOMPI_IGNORE_CXX_SEEK -DOMPI_SKIP_MPICXX
SHFLAGS = -fPIC
DEPFLAGS = -M

LINK = /opt/LinuxSoftwares/openmpi-1.6.4/prefix/bin/mpicc
LINKFLAGS = -O -L/opt/LinnuxSoftwares/openmpi-1.6.4/prefix/lib -L/opt/LinuxSoftwares/fftw-2.1.5/prefix/lib
LIB = -lpthread -lstdc++
SIZE = size

ARCHIVE = ar
ARFLAGS = -rc
SHLIBFLAGS = -shared

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

LAMMPS-specific settings

specify settings for LAMMPS features you will use

if you change any -D setting, do full re-compile after “make clean”

LAMMPS ifdef settings, OPTIONAL

see possible settings in doc/Section_start.html#2_2 (step 4)

LMP_INC =

MPI library, REQUIRED

see discussion in doc/Section_start.html#2_2 (step 5)

can point to dummy MPI library in src/STUBS as in Makefile.serial

INC = path for mpi.h, MPI compiler settings

PATH = path for MPI library

LIB = name of MPI library

MPI_INC =
MPI_PATH =
MPI_LIB =

FFT library, OPTIONAL

see discussion in doc/Section_start.html#2_2 (step 6)

can be left blank to use provided KISS FFT library

INC = -DFFT setting, e.g. -DFFT_FFTW, FFT compiler settings

PATH = path for FFT library

LIB = name of FFT library

FFT_INC = -DFFT_FFTW
FFT_PATH =
FFT_LIB = -lfftw

JPEG library, OPTIONAL

see discussion in doc/Section_start.html#2_2 (step 7)

only needed if -DLAMMPS_JPEG listed with LMP_INC

INC = path for jpeglib.h

PATH = path for JPEG library

LIB = name of JPEG library

JPG_INC =
JPG_PATH =
JPG_LIB =

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

build rules and dependencies

no need to edit this section

2

Dear All,

I have compiled lammps in a linux cluster by using the guidance of user
manual, but only one error is showing -

"......../usr/bin/ld: cannot find -lifcore
collect2: ld returned 1 exit status
make[1]: *** [../lmp_linux] Error 1
make[1]: Leaving directory
`/export/rahul/lammps/lammps-26May13/src/Obj_linux'
make: *** [linux] Error 2
"

can you make suggestion for this, I have tried a lot in mail list but not
found. Please help.

try this: http://lmgtfy.com/?q=lammps+ifcore+not+found

3

In newer versions of lammps there the two lines included right after the section of the makefile you show:

include Makefile.package.settings
include Makefile.package

The Makefile.package.settings links to files named Makefile.lammps inside the /lib dir. The one inside /lib/reax for example calls the lifcore library. Perhaps that is the source of your problem or something along these lines.

Carlos

4

Yes, that (improper inclusion of ifcore) is the problem.

It's really imprudent to hard code compiler- and/or machine-specific
settings into a generic Makefile.lammps that is automatically included
when these user packages are installed. Why I agree that the problem
is readily solved with Google, it would nice if the LAMMPS svn repo
were to reflect the universal case of NULL for user-*_SYS* and let
people deal with the dependencies in MAKE/Makefile.\(MYPLATFORM\) or (EXTENSION)/Makefile.lammps.$(MYPLATFORM) rather than having them
hunt down the offending options with grep.

While the README suggests that some effort should be required, it's
much more straightforward to debug the NULL case than the "Why is
LAMMPS looking for the Intel Fortran libraries on Blue Gene/Q when I
have not referenced this anywhere in Makefile.bgq?", for example,
since that violates the principle of least surprise in my opinion.

The following patch fixes the problem by requiring the user to add the
appropriate options if and only if they are necessary, rather than
forcing all users using a non-GCC compiler (in one cases) or non-Intel
compiler (in another case) or using BLAS/LAPACK that isn't Netlib
installed in a default path. I didn't deal with the CUDA-related
stuff because I don't care about GPU users.

Best,

Jeff

[[email protected]... lib]$ svn diff */Makefile.lammps
Index: atc/Makefile.lammps

5

Thanks for the feedback. I agree the error messages can be non-intuitive.
Maybe setting the defaults to nothing (no settings) would
be better. But that is certain to generate an error
every time. Currently, the various Makefile.lammps
files in the distro have settings somewhat likely to work, like -lblas or -lgfortran,
at least on Linux boxes.

I have viewed the task of insuring lib/foo/Makefile.lammps
is correct, as part of the build process for the auxiliary lib.
The manual section in 2.3 on "Packages that require extra libraries"

is quite clear on this. I suppose few users read it.

Note that if the user fixes the error for
one platform (by creating/copying a valid lib/foo/Makefile.lammps),
and then moves source files to another platform or cross-compiles
for that platform, the same obscure error will appear. I don’t know a way
to get around the fact that Makefile.lammps is a required
box-dependent file when you install a package with an auxiliary
lib. A file the user has to pay attention to (if he installs the package).
And that the file has to have that specific name.

let
people deal with the dependencies in MAKE/Makefile.(MYPLATFORM) or (EXTENSION)/Makefile.lammps.$(MYPLATFORM)

I don’t know what this means. It sounds like the user editing his MAKE/Makefile.foo
each time certain packages are install/uninstalled. How could we provide a generic
MAKE/Makefile.linux in that scenario? Or worse, when we add a new
package with an auxiliary lib, we’d need to change the format of all the
MAKE/Makefile.foo files to include options for new dependencies
the auxliliary lib has? That’s what the separate lib/foo/Makefile.lammps files
are attempting to isolate and avoid.

Steve

6

Hi Steve,

Sorry for the delay.

I have viewed the task of insuring lib/foo/Makefile.lammps
is correct, as part of the build process for the auxiliary lib.
The manual section in 2.3 on "Packages that require extra libraries"
is quite clear on this. I suppose few users read it.

I haven't read a software manual for open-source code in at least 5
years. I find that manuals are often dated and/or erroneous, while
source never lies. Of course, this method is probably not going to
work for most users.

Note that if the user fixes the error for
one platform (by creating/copying a valid lib/foo/Makefile.lammps),
and then moves source files to another platform or cross-compiles
for that platform, the same obscure error will appear. I don't know a way
to get around the fact that Makefile.lammps is a required
box-dependent file when you install a package with an auxiliary
lib. A file the user has to pay attention to (if he installs the package).
And that the file has to have that specific name.

A box-dependent file is always going to be required to get Fortran to
link unless one is in the unique trivial case of GCC+Netlib on a Linux
box with no nontrivial modifications.

let people deal with the dependencies in MAKE/Makefile.\(MYPLATFORM\) or (EXTENSION)/Makefile.lammps.$(MYPLATFORM)

I don't know what this means. It sounds like the user editing his MAKE/Makefile.foo
each time certain packages are install/uninstalled. How could we provide a generic
MAKE/Makefile.linux in that scenario? Or worse, when we add a new
package with an auxiliary lib, we'd need to change the format of all the
MAKE/Makefile.foo files to include options for new dependencies
the auxliliary lib has? That's what the separate lib/foo/Makefile.lammps
files are attempting to isolate and avoid.

Here is how I solved the problem on BGQ...

1) Split Makefile.bgq into Makefile.bgq and Makefile.bgq.details. The
latter contains all the actual platform-specific bits. The former is
just a generic wrapper at this point and I preserve it only to
localize the changes (i.e. so I can still build with "make bgq" and
not have to refactor the entire build system).

The reason I have to split the files is that I am going to include
Makefile.bgq.details in the lib/\(PACKAGE\)/Makefile\.lib \(which is completely generic and only exists for localization purposes\) but I cannot include the original Makefile\.bgq because it does things relative to src/MAKE that bork the build in lib/(PACKAGE).

2) Add Fortran and BLAS/LAPACK stuff into MAKE/Makefile.bgq.details.
The attachment only deals with Fortran because I only need to build
REAX and MEAM for one of our users, but the extension to ESSL or
equivalent is trivial, obviously.

3) Include Makefile.bgq.details in lib/$(PACKAGE)/Makefile.bgq.
Building with "make -f Makefile.lib" is invariant to my use of XL, GCC
or LLVM (LLVM doesn't have a Fortran front-end so I would be mixing
Clang and gfortran in this case). If I refactored
src/MAKE/Makefile.$machine such that there was a MAKE/Makefile.generic
that included src/MAKE/Makefile.$machine.details, then I would use
"make -f Makefile.lib $machine" so lib/$PACKAGE/Makefile.lib would
include src/MAKE/Makefile.$machine.details instead.

I've attached my files for reference (Makefile.lib is renamed to
Makefile.lib.stupid-gmail because GMail refuses to accept that a plain
text file with 644 permissions is not an executable). I really only
care about my Mac laptop and Blue Gene/Q, but if people are serious
about refactoring the build system along the lines of what I describe
here, I can certainly help out w.r.t. other supercomputers, e.g. Cray.

Best,

Jeff

Makefile.bgq.details (3.28 KB)

Makefile.bgq (1.15 KB)

Makefile.lib.stupid-gmail (1.43 KB)

7

Interesting idea - thanks for the details. I’m not
convinced it’s a better solution though.
Maybe Axel will comment.

To me, it makes all src/MAKE/Makefile.foo files
become essentially identical. And pushes the
machine-specific info that was in Makefile.foo
into Makefile.foo.details. With the addition of
all the lib-specific details needed for that machine.
So it would be harder for us to distribute
Makefile.foo.details files. And I imagine many
variants of Makefile.foo.details depending on
what packages people install.

The way it is now, the machine-specific lib info is isolated to
lib/package/Makefile.foo (and Makefile.lammps) files. Since the user
has to build the lib, that seems to me like a more
natural place to have the info.

I think I will take your advice to have the
lib/package/Makefile.lammps files in the distro
be empty. And have files like lib/meam/Makefile.gfortran
also create the appropriate Makefile.lammps. Thus
if the user does

cd lib/meam; make -f Makefile.foo

he is done, so long as he insures Makefile.foo is
correct for his box.

Steve

8

As far as I can tell, Fortran and BLAS/LAPACK are the important
additions required for packages, so those can be captured in the main
part of the buildsystem without much effort. Users are presumably
capable of figuring out that options for FFT, JPC, etc. need to be set
by hand, so adding one for BLAS/LAPACK seems like it won't be an
issue. In cases where the C++ compiler won't compile Fortran
automatically*, I think users should be able to define FC and FFLAGS
in the main Makefile.$machine without any effort.

* This is a reference to GCC's amusing (amazing?) ability to compile
Fortran with the C compiler due to syntax auto-detection.

As for Makefile.*.details, that is only an artifact of my
localization. If I were to instead refactor such that Makefile.bgq
did not include anything that prevents it from being included by
lib/*/Makefile, then no additional files would be required.

If I get some free time, I'll refactor the whole build system per the
structure I described and you guys can decide if it's worthwhile. If
this happens, I'll add support for a few additional platforms to
sweeten the deal.

Best,

Jeff

9

Interesting idea - thanks for the details. I'm not
convinced it's a better solution though.
Maybe Axel will comment.

i've been thinking about streamlining the configure/make procedure
from a different perspective.
i frequently need to compile multiple incompatible versions from the
same pile of sources.

i think to have a global configuration/architecture "repository" is
something that can be useful.
we'll have to essentially cover two kinds of uses:
- specialty hardware (like BG or Cray), which will need manual tweaks
by the local staff that don't know the application well and don't want
to search through 20 files for making the right changes. for those
this kind of centralized approach would be very helpful
- small-ish "local" cluster machines where people without lots of
experience in compiling and compilers are trying to compile LAMMPS.
for them, we would primarily need a facility that gathers the
necessary information (or falls back on bundled defaults, like BLAS or
FFT) and does consistency checks.

i think it should be possible to combine those two by having a script
(a la autoconf) that will generate the necessary central config file.
this is a bit nasty due to having to compile/link fortran and c++, but
it should be possible. a step that would make this safer is that there
are per-config object directories in the lib/*/ directories, so that
there are no unexpected incompatibilities (e.g. lib/gpu needs to be
compiled with the same MPI library as the main code, and that can
easily go wrong)

another step would be to spend some time on setting up automated build
systems using virtual machines and then export them through a repo.
somebody did this already for ubuntu and with all the build and
portability improvements over the last years it'll get easier all the
time.

i am trying out some improvements in LAMMPS-ICMS currently, but they
are not yet in good enough a shape to get through the Steve-QC-filter.

axel.

10

Interesting idea - thanks for the details. I'm not
convinced it's a better solution though.
Maybe Axel will comment.

i've been thinking about streamlining the configure/make procedure
from a different perspective.
i frequently need to compile multiple incompatible versions from the
same pile of sources.

i think to have a global configuration/architecture "repository" is
something that can be useful.
we'll have to essentially cover two kinds of uses:
- specialty hardware (like BG or Cray), which will need manual tweaks
by the local staff that don't know the application well and don't want
to search through 20 files for making the right changes. for those
this kind of centralized approach would be very helpful

I can write a very simple script to autodetect special machines. Cray
and Blue Gene machines have identical system directory hierarchies
that can be used to detect which architecture is used. The one
challenge is that Cray's cc wrapper can be any one of 3-5 different
backends so getting the right flags requires parsing the result of
"module list" or "cc -V", the latter of which sends one down the road
to autotools.

If one can assume that the configure script is a compiled C program,
then http://sourceforge.net/p/predef/wiki/Home/ has sufficient info to
detect essentially all platform-specific weirdness (true hackers will
find this page to be amazingly useful).

- small-ish "local" cluster machines where people without lots of
experience in compiling and compilers are trying to compile LAMMPS.
for them, we would primarily need a facility that gathers the
necessary information (or falls back on bundled defaults, like BLAS or
FFT) and does consistency checks.

If the user is sensible enough to source the Intel env var scripts,
then detecting their compilers and libraries is easy. This eliminates
the need to have any version-specific linker paths. I don't use PGI
or other commercial compilers often enough to know about how to
generically autodetect them.

I suspect that one can write a script to apt-get, etc. or
wget+configure+make+make_install FFT, MPI and other external deps and
then build LAMMPS against these. That's probably better than trying
to statically instantiate more than one Linux makefile. Either a user
is smart enough to make the changes on their own or they need an Easy
button.

i think it should be possible to combine those two by having a script
(a la autoconf) that will generate the necessary central config file.
this is a bit nasty due to having to compile/link fortran and c++, but
it should be possible. a step that would make this safer is that there
are per-config object directories in the lib/*/ directories, so that
there are no unexpected incompatibilities (e.g. lib/gpu needs to be
compiled with the same MPI library as the main code, and that can
easily go wrong)

You mean mpi.h has to be the same, right? The library isn't touched
except during linking. Of course, it is essential to not mix mpi.h
from OpenMPI and MPICH since that will lead to epic foobarring.

another step would be to spend some time on setting up automated build
systems using virtual machines and then export them through a repo.
somebody did this already for ubuntu and with all the build and
portability improvements over the last years it'll get easier all the
time.

I'm already doing the ALCF site install of LAMMPS and would be happy
to take responsibility for providing a BGQ binary of LAMMPS to the
community (BG binaries are static by default/design so packaging is
trivial). However, most people will be happy building from source
using the directions on
https://wiki.alcf.anl.gov/parts/index.php/Mira_LAMMPS_Documentation.

I'll talk to my friends at Cray to see if they have any interest in
providing LAMMPS as a module.

Best,

Jeff

11

Just released a patch that cleans up the build process a bit.

Axel - there is now a default src/Install.sh that works for
all packages w/out dependencies or libs. The others
have their own simpler Install.sh script using the
function we talked about. I didn’t touch USER-OPENMP/Install.sh,
so you can combine it with the function version as you see fit.

Jeff - I took your advice and whacked the lib/foo/Makefile.lammps
files from the distro. All the lib/foo/Makefile.machine files
now create Makefile.lammps by coping from a specific Makefile.lammps.blah.
The lib/foo/READMEs and doc pages explain that the user
needs to check this before “making” the lib.

So there are now 3 cases:

a) build LAMMPS with packages that don’t use auxiliary libs

works as before, all machine settings are in src/MAKE/Makefile.foo

b) build with a package with a lib where LAMMPS provides the code in lib/foo

do a single step: cd lib/foo; make -f Makefile.blah
which creates the lib file and lib/foo/Makefile.lammps
it’s up to the user to make sure that step is correct for his box

c) build with a package with a lib LAMMPS does not provide

uses src/package/Makefile.lammps, which the user has
to insure has proper settings for his box, e.g. src/VORONOI/Makefile.lammps

Re: Axel and Jeff’s suggestoins for additional build wizardry,
I don’t mind providing additional options (e.g. pre-built binaries, fancier
additional scripts),
but I don’t think I want to alter the basic build system.

I think it is
fine when building with a auxiliary lib for the first time,
to force (or allow) the user to tweak some settings, like
what Fortran compiler to use and what Fortran libs to
link against. And having those settings where the lib
is, makes more sense to me, than putting them in some
big machine file separate from the lib. That leads to many
versions of one machine file and confusion for the average user
about which settings they need to worry about. And it means
we have to add settings and options to all the machine files (as does a user
who maintains their own) every time
we add a new auxiliary lib with new dependencies. The way
it is now is more incremental and the user can just ignore
all of it if he doesn’t use the package.

Steve