[Wien] compiler pathscale
Brian R Smith
brian at cypher.acomp.usf.edu
Tue Aug 2 17:03:08 CEST 2005
> 1) siteconfig works fine. It sets up everything in various Makefiles
> using substitutions. OK, it's not as sophisticated as an
> autoconf/automake script but since the only real things needed are the
> lapack/blas libraries it does not need to be.
Right, siteconfig does work (though I think it could be a little more
intuitive). I was thinking about repackaging wien2k in
autoconf/automake format and was wondering if this would be of any
interest to anyone or if it is even allowed by the license?
I am planning on doing this for a number of other scientific
applications because quite honestly, I find some of the build processes
rather disturbing. As well, with autoconf, I can put together RPMs
using specfiles which will greatly simplify my own administration
duties.
-Brian Smith
On Tue, 2005-08-02 at 09:52 -0500, L. D. Marks wrote:
> I think I should correct a couple of things:
>
> 1) siteconfig works fine. It sets up everything in various Makefiles using
> substitutions. OK, it's not as sophisticated as an autoconf/automake
> script but since the only real things needed are the lapack/blas libraries it does
> not need to be.
>
> 2) You can't do things like set a distribution location (e.g.
> autoconf/$(prefix)); Wien has a lot of csh scripts which expect certain
> locations for things.
>
> 3) LD_LIBRARY_PATH is NOT relevant at compile time, it matters at run
> time. You have to set this correctly -- please see numerous comments in
> the mail archives.
>
> N.B., I did not write any of the shell scripts, so I don't have a vested
> interest in them.
>
> On Tue, 2 Aug 2005, Brian R Smith wrote:
>
> > Robert,
> >
> > > Or, should it use -lmkl_lapack32 ?
> >
> > I haven't built with Intel on the EM64T chips, so I don't know if the
> > compiler defaults to 64bit or if you have to specify it explicitly. I
> > would do a 'file' on one of the .o object files generated during the
> > install. It will tell you if it's 32bit or 64bit. Actually, I don't
> > ever recall actually having to use -lmkl_lapack* after passing -lmkl to
> > the linker. On 32bit systems with 7.x series MKL, -lmkl_lapack is
> > included implicitly with -lmkl.
> >
> > > Is there an option for siteconfig that sets up a separate target
> > > directory, it seems like it , but it always sets the target to the
> > > current directory where siteconfig resides, and then searches for the
> > > source in that directory, as far as I can tell
> >
> > siteconfig appears fairly "static" and probably will not work as
> > expected if used outside the intended bounds of the wien2k default build
> > structure. I've never seen any options to specify target paths, though
> > I could be mistaken.
> >
> > > 1. It seems that during the build process, the environment variable
> > > LD_LIBRARY_PATH is not used as I expect, ...
> >
> > Yes, I would not count on this to work. I would pass absolute paths to
> > the linker with -L<path> rather than rely on LD_LIBRARY_PATH (ESP. with
> > 3rd Party Compilers like Intel). An additional benefit of passing
> > absolute paths to the linker is that once those paths are in your
> > siteconfig (and thus your makefiles), rebuilding wien2k at any time will
> > be more trivial (e.g. you wont have to remember to set LD_LIBRARY_PATH
> > or what it needed to be set to).
> >
> >
> > -Brian Smith
> >
> > On Tue, 2005-08-02 at 15:26 +0100, Atwood, Robert C wrote:
> > > OK, I think it has compiled now, using the following:
> > >
> > > Current settings:
> > > O Compiler options: -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> > > L Linker Flags: -pthread
> > > P Preprocessor flags '-DParallel'
> > > R R_LIB (LAPACK+BLAS): -L/usr/local/Cluster-Apps/intel/mkl/7.21.003/lib/em64t -lmkl -lmkl_lapack64 -lvml -v
> > >
> > > Or, should it use -lmkl_lapack32 ?
> > >
> > > Is there an option for siteconfig that sets up a separate target directory, it seems like it , but it always sets the target to the current directory where siteconfig resides, and then searches for the source in that directory, as far as I can tell.
> > >
> > > I have altered expand_lapw to unpack into a specified target, thus separating the archive files from the source code, also it directly unpacks. It works with GNU tar , but some tar programs don't have the -z flag, but GNU tar is available for lots of platforms ..
> > >
> > >
> > >
> > >
> > >
> > >
> > > there are a few points I did not understand ...
> > >
> > >
> > > 1. It seems that during the build process, the environment variable LD_LIBRARY_PATH is not used as I expect, so the settings of the SUSE "environment modules" do not have the expected effect. Despite installing an 'environment module' including the path to the mkl libraries, the build process did not locate them. I was confused by the fact that the build process DID find the other Intel fortran libraries, which are also only referenced by an 'environment module' that sets the appropriate environment variables. I'm not sure this is an issue for anyone who does nto have a vendor-installed SUSE installation with several pre-configured 'environment modules'
> > >
> > > 2. The sysconfig searches the /opt/intel/... for the mkl but this vendor (ClusterVision) installs in a different place. I am sure there reason for this is to clarify which things they installed from things instaled as part of the SUSE installation. Perhaps they should not do this ... but, searching in PATH or LD_LIBRARY_PATH might also find the target libraries.
> > >
> > > 3. When selecting to recompile a single program, the new settings of R_LIB are not propagated to all the subdirectories and error messages from the old settings are repeated. I found this also to be confusing when trying some combinations of flags to see which woudl work , without wanting to recompile the whole package each time.
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: wien-bounces at zeus.theochem.tuwien.ac.at on behalf of Brian R Smith
> > > Sent: Mon 01/08/2005 23:59
> > > To: A Mailing list for WIEN2k users
> > > Subject: RE: [Wien] compiler pathscale
> > >
> > >
> > >
> > > Robert,
> > >
> > > These compile options worked for me with Intel Compilers v8
> > >
> > > SHELL = /bin/sh
> > > FC = ifort
> > > MPF = mpif90
> > > CC = mpicc
> > > FOPT = -O3 -tpp7
> > > FPOPT = -mp -w
> > > DParallel = '-DParallel'
> > > FGEN = $(PARALLEL)
> > > LDFLAGS = -L/usr/local/intel/mkl/mkl72/lib/32 -Vaxlib -L../SRC_lib
> > > R_LIBS = -L/usr/local/intel/mkl/mkl72/lib/32 -lmkl
> > > C_LIBS = $(R_LIBS)
> > > RP_LIBS = $(R_LIBS) -L/usr/local/intel/mkl/mkl72cluster/lib/32/ -lmkl
> > > CP_LIBS = $(RP_LIBS)
> > > DESTDIR = .
> > >
> > >
> > > -Brian
> > >
> > > On Mon, 2005-08-01 at 23:54 +0100, Atwood, Robert C wrote:
> > > > I have a problem compiling for Intel x86_64-suse-linux-gnu; (suse 9.1 with updates from yast) cluster configured by ClusterVision I cannot get the loader to find the correct combination of Intel libraries, in some SRC directories the make system seems to be tryign to mix 64- and 32- bit libraries.
> > > >
> > > > For example, if I try ot make SRC_filtvec, it returns that 'libmkl_lapack' is not found. But the static .a version , at least is in the path referred to in LD_LIBRARY_PATH ? If I move things around or run the link step manually, I can get it to stop complainig about libmkl_lapack but then it starts complaining about -lmkl_ia32
> > > >
> > > > Any ideas from more experience WIEN installers/ cluster sys admins would be appreciated
> > > >
> > > > Robert
> > > >
> > > >
> > > >
> > > >
> > > > ******************** console capture ***********************************
> > > > SUBSHELL> hive2:/sources/local/wien/test/SRC_filtvec # make
> > > > if [ -f .complex ]; then \
> > > > make clean; \
> > > > fi
> > > > touch .real
> > > > cp -p param.inc_r param.inc
> > > > make TYPE='REAL' TYPE_COMMENT='!_REAL' ./filtvec
> > > > make[1]: Entering directory `/hive2tmp/sources/local/wien/test/SRC_filtvec'
> > > > ifort -o ./filtvec filtvec.o main.o info.o -Vaxlib -static-libcxa -pthread -lmkl_lapack -lmkl_ia32 -lguide
> > > > ld: cannot find -lmkl_lapack
> > > > make[1]: *** [filtvec] Error 1
> > > > make[1]: Leaving directory `/hive2tmp/sources/local/wien/test/SRC_filtvec'
> > > > make: *** [real] Error 2
> > > > SUBSHELL> hive2:/sources/local/wien/test/SRC_filtvec # echo $LD_LIBRARY_PATH
> > > > /usr/local/Cluster-Apps/mpi/ge/gcc/64/1.2.6.1/lib/shared:/usr/local/Cluster-Apps/intel/fce/8.1-026//lib:/usr/local/Cluster-Apps/intel/mkl/7.21.003/lib/em64t/
> > > > SUBSHELL> hive2:/sources/local/wien/test/SRC_filtvec # ls /usr/local/Cluster-Apps/intel/mkl/7.21.003/lib/em64t
> > > > . libmkl_def.so libmkl_lapack.a libmkl_vml_def.so
> > > > .. libmkl_em64t.a libmkl_p4n.so libmkl_vml_p4n.so
> > > > libguide.a libmkl_lapack32.so libmkl.so libvml.so
> > > > libguide.so libmkl_lapack64.so libmkl_solver.a
> > > > SUBSHELL> hive2:/sources/local/wien/test/SRC_filtvec #
> > > > ************* end console capture **************************
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: wien-bounces at zeus.theochem.tuwien.ac.at on behalf of stargmoon
> > > > Sent: Mon 01/08/2005 21:09
> > > > To: A Mailing list for WIEN2k users
> > > > Subject: [Wien] compiler pathscale
> > > >
> > > >
> > > >
> > > > Dear WIEN2k community,
> > > >
> > > > I am trying to compile WIEN2k on an AMD processors
> > > > based cluster with compiler pathscale. I am wondering
> > > > if there is someone in the WIEN community who had
> > > > successfully done this before. Which system from the
> > > > WIEN siteconfig list for the system should be
> > > > specified for my system?
> > > >
> > > > My system is: MACHTYPE=x86_64-redhat-linux-gnu.
> > > >
> > > > Looking forward to your reply!
> > > >
> > > > Best,
> > > >
> > > > Stargmoon
> > > >
> > > >
> > > > P.S. I found from the mailist that James once tried to
> > > > do this around this April and posted some questions on
> > > > this mailist. I am wondering if James had successfully
> > > > figured out his problem.
> > > >
> > > >
> > > >
> > > >
> > > > ____________________________________________________
> > > > Start your day with Yahoo! - make it your home page
> > > > http://www.yahoo.com/r/hs
> > > >
> > > > _______________________________________________
> > > > Wien mailing list
> > > > Wien at zeus.theochem.tuwien.ac.at
> > > > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> > > >
> > > >
> > > > _______________________________________________
> > > > Wien mailing list
> > > > Wien at zeus.theochem.tuwien.ac.at
> > > > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> > >
> > > _______________________________________________
> > > Wien mailing list
> > > Wien at zeus.theochem.tuwien.ac.at
> > > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> > >
> > >
> > > _______________________________________________
> > > Wien mailing list
> > > Wien at zeus.theochem.tuwien.ac.at
> > > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> >
> > _______________________________________________
> > Wien mailing list
> > Wien at zeus.theochem.tuwien.ac.at
> > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> >
>
> Note: if you have an old email address for me, please note that "nwu" has
> been changed to "northwestern".
> -----------------------------------------------
> Laurence Marks
> Department of Materials Science and Engineering
> MSE Rm 2036 Cook Hall
> 2220 N Campus Drive
> Northwestern University
> Evanston, IL 60201, USA
> Tel: (847) 491-3996 Fax: (847) 491-7820
> email: L-marks at northwestern dot edu
> http://www.numis.northwestern.edu
> -----------------------------------------------
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
More information about the Wien
mailing list