[Pw_forum] kubuntu+gfortran+configure+make all=no executables

[Axel Kohlmeyer]

On 10/24/07, Paul M. Grant <w2agz at pacbell.net> wrote:

paul,

> Baris, Joerg, Paolo and Axel:  I apologize for the commotion…the entire
> issue was due to a blunder on my part.  I had mistakenly "source-d" instead
> of "export-ed" the path to the QE binaries in .bashrc!  Grrr.  When I tried
> to execute the QE binaries in the bin directory, bash reported it couldn't

no problem.

> find the files.  That's when I saw the executables had the "l" attribute set
> and got thoroughly confused by the nomenclature…which I still don't
> completely understand why the "make" routine does this…the "link" seems
> somewhat "recursive" (incestuous?) in that the executable code is buried in
> what seems to be a "link."  In Windows, a .lnk really does point to a

no. the purpose of a (symbolic) link is to give you access to a file without
having to copy it (and saving disk space in the process). the make program
loops over the subdirectories and compiles the various executables there, but
for convenience, they are then 'collected' in bin through symlinks. for details,
check out, e.g., http://en.wikipedia.org/wiki/Symbolic_Link

the symbolic link in unix is superior to windows in that if you copy it,
you don't copy the link, but the object it points to.

> separate file.  BTW, Axel, if you do a "cp pw.x xpw.x", xpw.x loses the "l"
> attribute and actually does "look and feel like" an executable in ls –l and

yes. that is the expected behavior and you create a real copy, since the
symlink redirects you to the real binary. probably what is most confusing to
you is the fact, that the 'link' part of a symlink has nothing to do with the
linking (or binding) of an executable.

[...]

>
> I did take Axel's advice and ran "file" against both pw.x and xpw.x and got
> the following (respectively):
>
> pw.x:  symbolic link to '../PW/pw.x'  (Weird…my comment…do they really mean
> '..PW/pw.o'?)

no that is correct. the real executable is built in ../PW/pw.x, seen
relative from bin.
so executing ./bin/pw.x actually will execute ./bin/../PW/pw.x
does that make sense to you?

[...]

> OK, now on to agonies with the Intel compiler and (K)Ubuntu 7.10.  Axel,
> please go to the following posting:
> http://ubuntuforums.org/showthread.php?p=3603521.  This is
> exactly the error that occurred with me on attempting an install of
> 10.0.023.  You can see from the responses that apparently someone was able
> with a tour de force effort to hack a fix.  (BTW, the Intel install
> complained as usual it couldn't find g++ and I had to go get the distro for
> that first.).  I then tried backing off to 9.1.045 and got the same error
> message at a different line in ./install.sh.  So Axel, you may be right…the
> problem could be in the new Ubuntu  distro.  Incidentally, the install docs

ha ha. this is funny. i should have run into the same problem when
intalling intel 10 on my (fresh installed) fedora 7.92 laptop, but since
i don't like the the intel installer messing with my installations, and
since i hate having to set environment variables with for LD_LIBRARY_PATH
globally, i always avoided the install.sh script and used rpm directly and
was using my own wrapper in /usr/local/bin, e.g. for ifort

#!/bin/sh
PATH="/opt/intel/fc/10.0.026/bin:${PATH}"
INTEL_LICENSE_FILE=${HOME}/licenses:/opt/intel/licenses
export INTEL_LICENSE_FILE PATH
exec -a "/opt/intel/fc/10.0.026/bin/ifort"
/opt/intel/fc/10.0.026/bin/ifortbin "$@"

this has been working very well for me since intel 8.0.
lesson: sometimes paranoia about automated tools guessing wrong
can help you avoid a lot of trouble. ;-)

> for the Intel Fortran compiler do not mention Ubuntu as a tested
> platform…nor Debian, which is really wild…only Red Hat and SUSE derivatives.
>  Re glibc, I don't really know where it sits in the directory structure
> (this is a issue I've always had with Unix-derived OS's vis-ŕ-vis
> DOS/Windows, and the location seems to change with the distro).  The Ubuntu
> repository doc lists it as 2.6.1-1ubuntu9.  Gcc and g++ seem to be around
> the GNU 4.2 level.

fedora 7.92 has gcc-4.1.2 and glibc 2.7 hmm,....

> I've had success on several of my machines using openSUSE with Intel Fortran
> and the LAPACK/BLAS distributed with QE.  More about that in a separate
> post.

> Given all this new grief with Intel Fortran and Ubuntu (which I will post to
> the respective user groups), I decided to try one of the GNU distributions.
> My understanding is that a "divorce" or "forking" occurred several years ago
> between g95 and gfortran and the latter became the "official" GNU release (I
> have no idea which of the three…ifort, g95 or gfortran…is "best" for QE…can
> someone out there advise?).  Since I was changing compilers, I thought I

i think a lot of people use intel. on many x86 machines it produces the
fastest code, but one has to stay up-to-date with the patches. g95 is
more complete as a fortran95 compiler as gfortran, which still has a few
more quirks, but is continously getting better.

> would also change math libraries (there is a very cryptic remark in the QE
> UG that "…vendor-optimized libraries can be used:  this often yields huge
> gains."  Axel, I think you're the keeper of the libraries…which one(s) give
> the "hugest gains.") .  Because Intel Fortran install bombed, I was leery of

the default fortran implementations of LAPACK and BLAS are usually
the slowest, and those are the ones that most distributions ship. fedora now
offers ATLAS rpms as drop-in. ATLAS is a re-implementation of BLAS and
some parts of LAPACK in a ways that it can automatically adapt to the
cpu/hardware
during compilation. for distributions (or commercial packages) this is
not feasable,
so they ship alternate versions for different hardware combinations or
some generic
optimization. the major jump is from the (cpu cache ignorant) fortran
versions to
the (cpu cache aware) versions (e.g. ATLAS, MKL, ACML, GOTO). the rest
is usually a minor contribution. with MKL it seems to me that recently, intel
is optimizing MKL in a way that it assumes the (2x larger) cache size
of the xeon
versions of processors, which means that desktops don't perform as well as
the corresponding xeon of the same or lower clock (which is usually much more
expensive). there are now also ACML versions that work with intel, and recent
intels (woodcrest, clovertown and co) are much more similar to opterons than
the (netburst) pentium4, so that this is an alternative. in the end, you have to
test on your hardware with several options and pick the one that works best.
i usually go for something convenient (= MKL). i rather spend my time on
thinking about the most efficient strategy of calculations then fighting for
the last half percent of optimal speed. you lose more time in doing useless
calculations. so even if you can do those a little bit faster does not help you
as much as knowing that they are useless _before_ you do them.

> trying Intel MLK.  I did notice the Ubuntu repositories contained a package
> called lapack3 and refblas3, so I downloaded and installed them.  I don't
> think configure found them, though, since a quick scan on config.log only
> picked up the flib .a archives for lapack and blas.

those are probably even slower than the blas/lapack shipped with QE,
since they are likely to be compiled as shared libraries (shared libraries
are up to 10% slower). not worth the effort for the reasons from above.

cheers,
   axel.

> If I can figure out how to point configure to the lapack3 and refblas3 libs,
> I'll test them against my favorite QE benchmark…example07.
>
>
>
> Paul M. Grant, PhD
>
> Principal, W2AGZ Technologies
>
> Visiting Scholar, Applied Physics, Stanford University
>
> EPRI Science Fellow (Retired)
>
> IBM Research Staff Member Emeritus
>
> w2agz at pacbell.net
>
> http://www.w2agz.com
>
>
>
>
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
>


-- 
=======================================================================
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.