I've just realized that both you and the similar report you linked to were using CMake 2.8.3. If you don't succeed could you try another CMake version? -- Szilárd
On Mon, Oct 24, 2011 at 11:14 PM, Szilárd Páll <szilard.p...@cbr.su.se> wrote: > Please keep all discussions on the mailing list! Also, I'm also CC-ing > to the gmx-devel list, maybe somebody over there has an better what > causes your CMake issue. > >>>> //Flags used by the compiler during all build types >>>> CMAKE_C_FLAGS:STRING=' -msse2 -ip -funroll-all-loops -std=gnu99 ' >>>> >>>> //Flags used by the compiler during release builds. >>>> CMAKE_C_FLAGS_RELEASE:STRING=-mtune=itanium2 -mtune=core2 -O3 -DNDEBUG >>>> ... >>>> These are obviously the wrong flags for the detected architecture, >>>> sse2 is no longer available and so are the the mtune architectures. >>> >>> Indeed, some of those flags are wrong (CXX -std=gnu99), others simply >>> outdated (-mtune=itanium2). There are plans to correct these issues >>> for 4.6, but let's agree on the fact that they are not show-stoppers >>> (FYI you won't get more than a few percent speedup with the right >>> compiler options, the most I've seen is ~5%.) >> >> OK, I was under the impression it would be simple to correct that - >> independend of gains if any. > > Theoretically it is, but in practice not so much. Keeping up with the > ever changing compiler options - especially the architecture-related > optimization flags - is not a fun job. We'll try to improve these > aspects of the CMkake build system the next release. > >>> If you want to get rid of them, the solution is pretty simple: just >>> remove the offending options and pick new ones if you think they work >>> better for you. >> >> That involves hand-editing the CMakeCache which may be no less >> bothersome than enduring the warnings ;-) > > You can use ccmake (or cmake-gui), they will make your life easier. > Otherwise, editing the cache is nowhere near as difficult as it > sounds. ;) > >>> However, I'm not sure what do you mean by "sse2 is no longer >>> available"? Of course it is, both the Intel Compiler and the majority >>> of current processors support it. Also, -mtune=core2 is perfectly >>> valid as is -msse2. >> >> I checked that with the documentation on the Intel site and >> the code generation options written out by the compiler (as >> help info). On the Intel site, -msse2 and -mtune=core2 are >> still listed as valid, whereas they aren't mentioned in the >> help provided by the compiler I installed. Maybe they are >> redundant with the Intel64-compiler and set by default >> (not entirely sure). Bottom line: you are right here, I >> missed some information. > > i) Indded the "-msse2" is redundant. From the icc man page: > > "On Linux systems, if neither -x nor -m is specified, the default is > -msse2." > > ii) Nope, the default as usually is -mtune=generic on "IA-32" and > "Intel 64" - as Intel likes to call them. > > Btw, core2 is essentially equivalent with -xSSSE3. Depending on the > processors you intend to run on you can try -xSSE4.1 or -xSSE4.2, but > I doubt you'll see a noticeable difference. > >>>> CMAKE_CXX_FLAGS:STRING=' -msse3 -ip -funroll-all-loops -std=gnu99 ' >>> >>> As Mark said, SSE3 won't help you in any noticeable way. >> >> The only 'help' I envisioned here was to avoid screen cluttering >> by loads of warnings. mMy suggested 'fixes' weren't really fixes, >> as I can see now. In my own development work, I can't stand >> pages of recurring warning messages ;-) So I probably >> overreacted here ... > > Sure, warnings are not nice and we dislike them as well. That's why > these issues will be corrected in the future. > >>>> But the install is broken. On `make install-mdrun`, the scripts would >>>> remove any library from "src/gmxlib/CMakeFiles/CMakeRelink.dir" >>>> and bail out with the error below. Even if you copy the libraries >>>> by hand to CMakeRelink.dir/, the'll get removed by make install-mdrun >>>> before trying to link with them. >>> >>> Now that is a bug. I'd appreciate if you could enter it in >>> redmine.gromacs.org withe all details on how to reproduce it! >> >> I didn't do that until now but examined this further. There is already >> an identical error posted by some other researcher (as you know): >> http://www.mail-archive.com/gmx-users@gromacs.org/msg39228.html >> >> I was able to replicate the error somehow on a different machine without >> any intel compiler around (when building with -DGMX_MPI=ON and cmake). >> >> Gromacs 4.5.5: autoconf/configure on SuSE 11.4/x64 on i7 >> ---------------------------------------------------------------- >> icc/64-12.1.0 gcc/x64/4.5.1 >> intThread OK OK >> MPI(1.3.2) OK OK >> >> >> Gromacs 4.5.5: cmake 2.8.3 on SuSE 11.4/x64 on i7 >> ---------------------------------------------------------------- >> icc/64-12.1.0 gcc/x64/4.5.1 >> intThread error OK >> MPI(1.3.2) error error >> >> >> Gromacs 4.5.5: autoconf/configure on SuSE 11.4/x64 on Phenom/X4 >> ---------------------------------------------------------------- >> gcc/x64/4.5.1 gcc/x64/4.6.1 >> intThread OK OK >> MPI(1.3.2) OK OK >> >> >> Gromacs 4.5.5: cmake 2.8.3 on SuSE 11.4/x64 on Phenom/X4 >> ---------------------------------------------------------------- >> gcc/x64/4.5.1 gcc/x64/4.6.1 >> intThread OK OK >> MPI(1.3.2) error error >> >> >> Gromacs/git (2011-10-18): cmake 2.8.3 on SuSE 11.4/x64 on Phenom/X4 >> ------------------------------------------------------------------- >> gcc/x64/4.5.1 gcc/x64/4.6.1 >> intThread error error >> MPI(1.3.2) error error >> >> >> Notes: - the MPI is openmpi out-out-the-box w/SuSE 11.4 >> - Gromacs/git - w/autoconf was not tested >> - Intel-Compiler on AMD Phenom N/A >> - Gromacs/git failed w/compile error >> on Boost(?) -> src/gromacs/analysisdata/modules/plot.cpp:60 >> boost::mpl::aux::template_arity<mpl_::na>::value’ is not a >> valid template argument for type ‘int’ because it is a >> non-constant expression (many following) >> - Boost version is 1.4.6 (actual version) >> >> Resumé: >> - autoconf succeeds in almost all cases with any compiler >> - cmake fails in almost all cases except the simplest ones (cmake >> ../gromacs-src) >> >> I really don't know what to make out of this. > > Me neither, but let's try to figure it out. > > First of all, your OpenMPI is quite outdated; as the > build-generation-time message warns OpenMPI <v1.4.1 has known issues. > > However, I've just tried gcc 4.6.0 + OpenMPI 1.3 with cmake 2.6.4 as > well as 2.8.2 and in both cases my installation went just fine. > Although I didn't remember seeing you full command line call to CMake, > I tried to replicate a quite common scenario: build & install full > Gromacs with MPI off and "threads" on, then build & install mdrun with > MPI. Here are my command lines: > > CMAKE_PREFIX_PATH=/my/path/to/fftw3 cmake ../ -DGMX_MPI=OFF > -DCMAKE_INSTALL_PREFIX=/tmp/gromacs-4.5 && make -j6 && make install > > CMAKE_PREFIX_PATH=/my/path/to/fftw3 cmake ../ -DGMX_MPI=ON > -DCMAKE_INSTALL_PREFIX=/tmp/gromacs-4.5 && make mdrun -j6 && make > install-mdrun > > Could you please run the above commands and see what you get. If make > install-mdrun still fails, please attach your CMakeCache.txt so we can > take a look at it. > > Cheers, > -- > Szilárd > -- gmx-users mailing list gmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
