From: Axel Kohlmeyer (akohlmey_at_cmm.chem.upenn.edu)
Date: Mon Jun 01 2009 - 21:58:49 CDT
On Mon, 2009-06-01 at 22:27 -0400, Guanglei Cui wrote:
> Dear Axel,
> I didn't keep the make log, but I plan to try it again some time this
> week. Should I use mpiCC in Linux-x86_64-icc.arch, instead of
> icc/icpc? One reason to build static binaries (as static as possible)
yes. using mpiCC will make linking much easier.
> is to use the binary on other computers. The precompiled NAMD (UDP)
> binary only depends on libdl, libm, libstdc++, libc, ld-linux-x86-64,
> and libgcc_s. One should be able to build an MPI binary with similar
nope. MPI binaries are highly dependent on the locally available
transport layers and the corresponding libraries. with a static
link this will create problems. This is why OpenMPI is so convenient,
because it selects transport layers at runtime through shared libraries.
however, the executables depend only on the OpenMPI libraries, the
corresponding shared objects are opened by the OpenMPI libraries.
with a fully static link this all breaks down (for the most part).
the only part where you should make your binaries more portable
are avoiding dependencies to the intel compiler runtime, but if
you compiled your OpenMPI with icc, then the shared modules depend
on that compiler's runtime, too. so basically, you are more-or-less
stuck with a fully dynamic installation.
to have the intel libs linked statically, you'll need to first compile
OpenMPI with gcc/g++ and then fiddle with the configuration files for
mpicc/mpiCC to have them use icc/icpc/ifort instead of gcc/g++/gfortran
and also change a few linker flags to have them find the right locations
for the runtime libraries and -i-static/-static-libcxa to have the
intel runtime linked in statically on the final executable.
> dependency, I suppose. Would you please elaborate why a static binary
> may fail? What is ABI? Thanks.
ABI is the "Application Binary Interface", which is different from
the API "Application Programming Interface". In c/c++ source code
the standards (ANSI-C/C++, POSIX, BSD, SVIX, XOPEN, ...) define what
names and arguments library functions should have. however, how the
individual libraries interface this to the operating system and the
kernel can change. so you can have applications compiled from the
same sources, but they don't run on different machines. for example
if you compile a binary on, say, red hat EL 4, it will not run on
red hat EL 5, unless you install all the compatible libraries.
including the ones for the gcc-3.x g++ compiler (libstdc++.so.5).
this holds for example for some of the NAMD 2.6 binaries. this is
a quite obvious difference and a bit confusing and annoying
(you have to install multiple libraries and know about it to
be compatible).
with the c library this is more complicated. rather than requiring
a new library version when some changes are made, each library
function call is silently translated to one with a version number
embedded (e.g. @@GLIBC_2.0, @@GLIBC_2.1.1, @@GLIBC_2.3.4 and so on)
whenever there are incompatible changes in the binary interface.
this way you can have multiple binary variants of the same function
in a library and your old executable picks the one that is compatible
with the ABI it was compiled for, but a newly compiled executable
uses the newer ABI. this works nice and smooth if you obey two rules.
1) never try to run an executable that was compiled on a newer
ABI on an installation with an older ABI
2) don't create fully static binaries, always link libc dynamically.
as it is, even fully static binaries will load some shared objects
(for reasons that are debatable and would go to far into detail)
and now you have to have the exactly matching files around, or else
your executable most likely crash (or worse) because it assumes
a different binary interface, which only the shared library can
provide.
if you need further details, search a bit on the web and look for
explanations and also the compiler and glib docs have some explanation.
cheers,
axel.
>
> Regards,
> Guanglei
>
> >
> > can't say without actually seeing which symbols are not found.
> >
> > you cannot link a fully static executable, if you have configured
> > openmpi to use dynamic loading. you should never need to provide
> > any of the linker flags that you quote but rather you mpiCC.
> >
> > with intel compilers, all you want is to link the intel libraries
> > statically, i.e. use -i-static -static-libcxa.
> >
> > why do you want to link statically in the first place. with recent
> > glibc versions, this is a very bad idea, as it would make your
> > binaries fail in uncontrolled ways whenever an update would change
> > the lowlevel ABI.
> >
> > cheers,
> > axel.
> >
> >>
> >> Regards,
> >> Guanglei
> >>
> >> >
> >
> > --
> > =======================================================================
> > Axel Kohlmeyer akohlmey_at_cmm.chem.upenn.edu http://www.cmm.upenn.edu
> > Center for Molecular Modeling -- University of Pennsylvania
> > Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
> > tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
> > =======================================================================
> > If you make something idiot-proof, the universe creates a better idiot.
> >
> >
-- ======================================================================= Axel Kohlmeyer akohlmey_at_cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot.
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:52:53 CST