October 2018 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPICH interact with RTDA
by Zhou, Hui 26 Oct '18

26 Oct '18

In fact there is a manual mode in hydra. Try this: mpiexec -n 2 -launcher=manual -host=A,B date It will print out the launch command lines and wait (very patiently). Then if you paste the proxy command line on your local host or any host on your network, it will continue. I guess that is all the pipelines that you can use to create your own wrapper scripts to work for custom environment. — Hui On Oct 26, 2018, at 8:42 AM, Zhou, Hui <zhouh(a)anl.gov<mailto:[email protected]>> wrote: Having a manual mode of launching proxies sounds very interesting. I don’t think currently hydra supports it though. The manually launched proxies need establish communication back to mpiexec.hydra — I suspect the mechanism already exist. I guess the next question is how to reliably detect launch failures other than having mpiexec.hydra hanging forever — maybe that is a valid option. Hui Zhou On Oct 23, 2018, at 11:44 PM, Shuwei Zhao <shuweizhao1991(a)gmail.com<mailto:[email protected]>> wrote: Hi, I'm trying integrate MPICH with network submission tool called RTDA(RunTime Design Automation - www.rtda.com<http://www.rtda.com/>), I use the mpich-3.2.1a but looks like that mpich doesn't detect the resource manager and launcher, mpich cannot distribute jobs as expected. Does mpich support interact with RTDA resource manager and launcher? Since the hydra process manager did tight integration with SGE, LSF, SLURM, PBS, etc. I was thinking for platform it doesn't support - if there is way to submit jobs with loose integration? ( loose integration means that we do the job submission self and run hydra_pmi_proxy on each allocated node manually, instead of mpich finished everything under the hood. ) Thank you very much, Shuwei _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPICH interact with RTDA
by Zhou, Hui 26 Oct '18

26 Oct '18

Having a manual mode of launching proxies sounds very interesting. I don’t think currently hydra supports it though. The manually launched proxies need establish communication back to mpiexec.hydra — I suspect the mechanism already exist. I guess the next question is how to reliably detect launch failures other than having mpiexec.hydra hanging forever — maybe that is a valid option. Hui Zhou On Oct 23, 2018, at 11:44 PM, Shuwei Zhao <shuweizhao1991(a)gmail.com<mailto:[email protected]>> wrote: Hi, I'm trying integrate MPICH with network submission tool called RTDA(RunTime Design Automation - www.rtda.com<http://www.rtda.com/>), I use the mpich-3.2.1a but looks like that mpich doesn't detect the resource manager and launcher, mpich cannot distribute jobs as expected. Does mpich support interact with RTDA resource manager and launcher? Since the hydra process manager did tight integration with SGE, LSF, SLURM, PBS, etc. I was thinking for platform it doesn't support - if there is way to submit jobs with loose integration? ( loose integration means that we do the job submission self and run hydra_pmi_proxy on each allocated node manually, instead of mpich finished everything under the hood. ) Thank you very much, Shuwei _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPICH interact with RTDA
by Zhou, Hui 26 Oct '18

26 Oct '18

Having a manual mode of launching proxies sounds very interesting. I don’t think currently hydra supports it though. The manually launched proxies need establish communication back to mpiexec.hydra — I suspect the mechanism already exist. I guess the next question is how to reliably detect launch failures other than having mpiexec.hydra hanging forever — maybe that is a valid option. Hui Zhou On Oct 23, 2018, at 11:44 PM, Shuwei Zhao <shuweizhao1991(a)gmail.com<mailto:[email protected]>> wrote: Hi, I'm trying integrate MPICH with network submission tool called RTDA(RunTime Design Automation - www.rtda.com<http://www.rtda.com/>), I use the mpich-3.2.1a but looks like that mpich doesn't detect the resource manager and launcher, mpich cannot distribute jobs as expected. Does mpich support interact with RTDA resource manager and launcher? Since the hydra process manager did tight integration with SGE, LSF, SLURM, PBS, etc. I was thinking for platform it doesn't support - if there is way to submit jobs with loose integration? ( loose integration means that we do the job submission self and run hydra_pmi_proxy on each allocated node manually, instead of mpich finished everything under the hood. ) Thank you very much, Shuwei _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Getting an error in MPI_Comm_accept - ideas?
by Alexander Rast 25 Oct '18

25 Oct '18

It has taken a while to condense this down to something small enough because the whole thing is embedded within a large and reasonably complex software infrastructure of which parts were not trivial to strip away. I have tested a few further cases including using an MPI_Improbe/MPI_Imreceive combination in the MPISpinner() without success. The code I am sending reliably crashes on the MPI_Comm_connect at the end, failing within MPI_Comm_accept with an error message essentially similar to the one I have in the previous message. It seems clear the bug is related to some sort of message race, because depending upon the exact sequence (within the actual application we can have numerous possible scenarios before the final ending MPI_Comm_connect), the application may exit cleanly, give an error similar to the above, or give a variety of other, different errors. It's timing/state dependent in some non-obvious way. I'm running MPICH 3.2.1 with, in this case, a fairly standard set of options: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --enable-shared --prefix=/usr --enable-fortran=all --disable-rpath --disable-wrapper-rpath --sysconfdir=/etc/mpich --libdir=/usr/lib/x86_64-linux-gnu --includedir=/usr/include/mpich --docdir=/usr/share/doc/mpich --with-hwloc-prefix=system --enable-checkpointing --with-hydra-ckpointlib=blcr CPPFLAGS= CFLAGS= CXXFLAGS= FFLAGS= FCFLAGS= I also have a version with the performance-monitoring features enabled that I use from time to time, which also displays similar behaviour, although the exact output changes (presumably because differences in the performance-monitoring code change the execution timings or sequence). On Thu, Sep 27, 2018 at 2:39 PM Amer, Abdelhalim <aamer(a)anl.gov> wrote: > Hi, > > Can you pack the smallest test example in a single file so that we > compile and run it? Also please give us more information about the MPICH > version you are using and how it was built (run the `mpichversion` > binary to get this information). It would be better to use the latest > version (3.2.1) before reporting back. All of this is to help us > reproduce your problem or simply solving it by upgrading to a newer > version of MPICH. > > Halim > www.mcs.anl.gov/~aamer > > On 9/21/18 10:39 AM, Alexander Rast wrote: > > All, > > > > I'm running an MPI_Comm_accept in a separate thread whose purpose is to > > allow connections from other (hitherto unknown) MPI universes. A > > well-known issue of such configurations is that MPI_Comm_accept being > > blocking, in order for the application to exit, a connection MUST be > > made even if no actual other universes attempted to connect. In this > > situation (see Gropp, et al. "Using Advanced MPI", section 6.5) it seems > > the 'customary' solution is to have the local universe connect to itself > > and then shut down. > > > > However, I'm getting the following error on exit: > > > > Fatal error in PMPI_Comm_accept: Message truncated, error stack: > > PMPI_Comm_accept(129).............: > > MPI_Comm_accept(port="tag#0$description#aesop.cl.cam.ac.uk > > <http://aesop.cl.cam.ac.uk>$port#43337$ifname#128.232.98.176$", > > MPI_INFO_NULL, root=6, MPI_COMM_WORLD, newcomm=0x1473f24) failed > > MPID_Comm_accept(153).............: > > MPIDI_Comm_accept(1005)...........: > > MPIR_Bcast_intra(1249)............: > > MPIR_SMP_Bcast(1088)..............: > > MPIR_Bcast_binomial(239)..........: > > MPIDI_CH3U_Receive_data_found(131): Message from rank 0 and tag 2 > > truncated; 260 bytes received but buffer size is 12 > > > > You typically get several of these messages, the number seems to vary > > from trial to trial, I'm guessing it comes from different MPI processes > > (although there is no fixed relationship between number of processes > > started and number of error messages) > > > > Does anyone have any suggestions on what types of problems might cause > > this error? (I'm not expecting you to identify and debug the problem > > specifically, unless, perhaps, this error is indicative of some > > particular mistake, just would like any hints on where to look) > > > > If it helps, here are the 3 main relevant functions involved - there is, > > of course, a lot more going on in the application besides these, but the > > error is occurring at shutdown and by this point the rest of the > > application is quiescent. Also note that the Connect routine is NOT > > called at shutdown; it's invoked when a 'real' universe wants to connect. > > > > > //------------------------------------------------------------------------------ > > > > void* CommonBase::Accept(void* par) > > /* Blocking routine to connect to another MPI universe by publishing a > port. > > This operates in a separate thread to avoid blocking the whole > process. > > */ > > { > > CommonBase* parent=static_cast<CommonBase*>(par); > > > > while (parent->AcceptConns.load(std::memory_order_relaxed)) > > { > > // run the blocking accept itself. > > if > > > (MPI_Comm_accept(parent->MPIPort.load(std::memory_order_seq_cst),MPI_INFO_NULL,parent->Lrank.load(std::memory_order_relaxed),MPI_COMM_WORLD,parent->Tcomm.load(std::memory_order_seq_cst))) > > { > > printf("Error: attempt to connect to another MPI universe failed\n"); > > parent->AcceptConns.store(false,std::memory_order_relaxed); > > break; > > } > > // Now trigger the Connect process in the main thread to complete the > setup > > PMsg_p Creq; > > string N(""); // zero-length string indicates a server-side > > connection > > Creq.Put(0,&N); > > Creq.Key(Q::SYST,Q::CONN); > > Creq.Src(0); > > Creq.comm = MPI_COMM_SELF; > > Creq.Send(0); > > while (*(parent->Tcomm.load(std::memory_order_seq_cst)) != > > MPI_COMM_NULL); // block until connect has succeeded > > } > > pthread_exit(par); > > return par; > > } > > > > > //------------------------------------------------------------------------------ > > > > unsigned CommonBase::Connect(string svc) > > // connects this process' MPI universe to a remote universe that has > > published > > // a name to access it by. > > { > > int error = MPI_SUCCESS; > > // a server has its port already so can just open a comm > > if (svc=="") Comms.push_back(*Tcomm.load(std::memory_order_seq_cst)); > > else // clients need to look up the service name > > { > > MPI_Comm newcomm; > > char port[MPI_MAX_PORT_NAME]; > > // Get the published port for the service name asked for. > > // Exit if we don't get a port, probably because the remote universe > > isn't > > // initialised yet (we can always retry). > > if (error = MPI_Lookup_name(svc.c_str(),MPI_INFO_NULL,port)) return > > error; > > // now try to establish the connection itself. Again, we can always > > retry. > > if (error = > > MPI_Comm_connect(port,MPI_INFO_NULL,0,MPI_COMM_WORLD,&newcomm)) return > > error; > > Comms.push_back(newcomm); // as long as we succeeded, add to the list > > of comms > > } > > int rUsize; > > MPI_Comm_remote_size(Comms.back(), &rUsize); > > Usize.push_back(rUsize); // record the size of the remote universe > > FnMapx.push_back(new FnMap_t); // give the new comm some function tables > > to use > > pPmap.push_back(new ProcMap(this)); // and a new processor map for the > > remote group > > PMsg_p prMsg; > > SendPMap(Comms.back(), &prMsg); // Send our process data to the > > remote group > > int fIdx=FnMapx.size()-1; > > // populate the new function table with the global functions > > (*FnMapx[fIdx])[Msg_p::KEY(Q::EXIT )] = > &CommonBase::OnExit; > > (*FnMapx[fIdx])[Msg_p::KEY(Q::PMAP )] = > &CommonBase::OnPmap; > > (*FnMapx[fIdx])[Msg_p::KEY(Q::SYST,Q::PING,Q::ACK )] = > > &CommonBase::OnSystPingAck; > > (*FnMapx[fIdx])[Msg_p::KEY(Q::SYST,Q::PING,Q::REQ )] = > > &CommonBase::OnSystPingReq; > > (*FnMapx[fIdx])[Msg_p::KEY(Q::TEST,Q::FLOO )] = > > &CommonBase::OnTestFloo; > > if (svc=="") *Tcomm.load(std::memory_order_seq_cst) = MPI_COMM_NULL; // > > release any Accept comm. > > return error; > > } > > > > > //------------------------------------------------------------------------------ > > > > unsigned CommonBase::OnExit(PMsg_p * Z,unsigned cIdx) > > // Do not post anything further here - the LogServer may have already > gone > > { > > AcceptConns.store(false,std::memory_order_relaxed); // stop accepting > > connections > > if (acpt_running) > > { > > printf("(%s)::CommonBase::OnExit closing down Accept MPI > > request\n",Sderived.c_str()); > > fflush(stdout); > > // have to close the Accept thread via a matching MPI_Comm_connect > > // because the MPI interface has made no provision for a nonblocking > > accept, thus > > // otherwise the Accept thread will block forever waiting for a > > message that will > > // never come because we are shutting down. See Gropp, et al. "Using > > Advanced MPI" > > MPI_Comm dcomm; > > > > > MPI_Comm_connect(MPIPort.load(std::memory_order_seq_cst),MPI_INFO_NULL,Lrank.load(std::memory_order_relaxed),MPI_COMM_WORLD,&dcomm); > > pthread_join(MPI_accept,NULL); > > acpt_running = false; > > } > > if (Urank == Lrank.load(std::memory_order_relaxed)) > > { > > > > > MPI_Unpublish_name(MPISvc,MPI_INFO_NULL,MPIPort.load(std::memory_order_seq_cst)); > > MPI_Close_port(MPIPort.load(std::memory_order_seq_cst)); > > } > > return 1; > > } > > > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

MPICH interact with RTDA
by Shuwei Zhao 23 Oct '18

23 Oct '18

Hi, I'm trying integrate MPICH with network submission tool called RTDA(RunTime Design Automation - www.rtda.com) I use the mpich-3.2.1a but looks like that mpich doesn't detect the resource manager and launcher, mpich cannot distribute jobs as expected. Does mpich support interact with RTDA resource manager and launcher? Since the hydra process manager did tight integration with SGE, LSF, SLURM, PBS, etc. I was thinking for platform it doesn't support - if there is way to submit jobs with loose integration? ( loose integration means that we do the job submission self and run hydra_pmi_proxy on each allocated node manually, instead of mpich finished everything under the hood. ) Thank you very much, Shuwei

1 0

Re: [mpich-discuss] mpich install error (libstdc++.so)
by Zhifeng Yang 19 Oct '18

19 Oct '18

Hi Min, Yes, I forgot to make clean. After making clean, now it works fine. Thank you very much for your help. I appreciate it so much. Have a nice day Zhifeng On Thu, Oct 18, 2018 at 2:57 PM Si, Min <msi(a)anl.gov> wrote: > Hi Zhifeng, > > Your config.log looks correct to me. Did you run `make clean` before the > last successful build ? I am guessing whether some files were not > recompiled. > > And you could try to compile a simple program and see if it works. E.g., > `mpicc -o cpi ./examples/cpi.c` > > Min > > On 2018/10/18 12:23, Zhifeng Yang wrote: > > Hi Min, > > Thank you very much for your help. Now I installed MPICH successfully. > > However, when I use it for another weather model. It has the following > error. > > time mpif90 -w -ffree-form -ffree-line-length-none -fconvert=big-endian > -frecord-marker=4 -fopenmp -o test_io_idx test_io_idx.f -L. -lwrfio_int > > real 0m0.234s > user 0m0.076s > sys 0m0.042s > if [ -f ../../frame/pack_utils.o -a -f ../../frame/clog.o ] ; then \ > time mpif90 -w -ffree-form -ffree-line-length-none > -fconvert=big-endian -frecord-marker=4 -fopenmp -I../ioapi_share -o > diffwrf diffwrf.f \ > ../../frame/pack_utils.o > ../../frame/module_internal_header_util.o > ../../frame/module_driver_constants.o ../../frame/module_machine.o > ../../frame/module_wrf_error.o ../../frame/wrf_debug.o libwrfio_int.a ; \ > fi > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `_intel_fast_memset' > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `_intel_fast_memcpy' > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `__intel_sse2_strlen' > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `__intel_sse2_strncmp' > collect2: error: ld returned 1 exit status > 0.03user 0.06system 0:00.31elapsed 31%CPU (0avgtext+0avgdata > 9716maxresident)k > 144inputs+48outputs (0major+10999minor)pagefaults 0swaps > make[3]: [test_io_idx] Error 1 (ignored) > make[3]: Leaving directory > `/umbc/xfs1/zzbatmos/users/vy57456/model/gfortran/wrfchem4_0_c/WRF/external/io_int' > > It seems that I used ifort to compile MPICH. But I used gfortran. Any help? > > Zhifeng > > > On Thu, Oct 18, 2018 at 10:19 AM Si, Min <msi(a)anl.gov> wrote: > >> Hi Zhifeng, >> >> It looks like the Intel c++ compiler icpc is used for linking. Maybe you >> did not specify `CXX=g++` at configure time. >> >> Please try this (make sure all compilers are with the same version) >> ./configure <other config options> CC=gcc CXX=g++ FC=gfortran F77=gfortran >> >> If you still see the installation error, please send us the config.log at >> your build directory together with the error message. >> >> Min >> On 2018/10/18 8:28, Zhifeng Yang wrote: >> >> Hi >> >> I tried to install mpich using gcc. However, while make, I got the >> following error message. >> >> libtool: link: icpc -shared src/binding/cxx/.libs/initcxx.o >> -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/source_code/mpich-3.2.1/lib/.libs >> -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib >> -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/mpich-3.2.1/lib >> -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib lib/.libs/libmpi.so >> -lpthread >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4 >> -L/cm/shared/apps/slurm/14.11.11/lib64/slurm >> -L/cm/shared/apps/slurm/14.11.11/lib64 >> -L/usr/cluster/contrib/hdf5/install-1.8.16/lib >> -L/cm/shared/apps/acml/current/ifort64/lib >> -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64 >> -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64/ >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/ >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64 >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64/ >> -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4/ >> -L/cm/shared/apps/slurm/14.11.11/lib64/slurm/ >> -L/cm/shared/apps/slurm/14.11.11/lib64/ >> -L/usr/cluster/contrib/hdf5/install-1.8.16/lib/ >> -L/cm/shared/apps/acml/current/ifort64/lib/ >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../ >> -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -limf -lirng -lm -lipgo -ldecimal >> -lcilkrts /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so -lintlc -lsvml >> -lgcc -lgcc_s -lirc_s -ldl -lc -O2 -Wl,-soname -Wl,libmpicxx.so.12 -o >> lib/.libs/libmpicxx.so.12.1.1 >> /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so: could not read >> symbols: File in wrong format >> make[2]: *** [lib/libmpicxx.la] Error 1 >> make[2]: Leaving directory >> `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory >> `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' >> make: *** [all] Error 2 >> >> >> Do you have any experience on this error? Thank you >> >> Zhifeng >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] mpich install error (libstdc++.so)
by Si, Min 18 Oct '18

18 Oct '18

Hi Zhifeng, Your config.log looks correct to me. Did you run `make clean` before the last successful build ? I am guessing whether some files were not recompiled. And you could try to compile a simple program and see if it works. E.g., `mpicc -o cpi ./examples/cpi.c` Min On 2018/10/18 12:23, Zhifeng Yang wrote: Hi Min, Thank you very much for your help. Now I installed MPICH successfully. However, when I use it for another weather model. It has the following error. time mpif90 -w -ffree-form -ffree-line-length-none -fconvert=big-endian -frecord-marker=4 -fopenmp -o test_io_idx test_io_idx.f -L. -lwrfio_int real 0m0.234s user 0m0.076s sys 0m0.042s if [ -f ../../frame/pack_utils.o -a -f ../../frame/clog.o ] ; then \ time mpif90 -w -ffree-form -ffree-line-length-none -fconvert=big-endian -frecord-marker=4 -fopenmp -I../ioapi_share -o diffwrf diffwrf.f \ ../../frame/pack_utils.o ../../frame/module_internal_header_util.o ../../frame/module_driver_constants.o ../../frame/module_machine.o ../../frame/module_wrf_error.o ../../frame/wrf_debug.o libwrfio_int.a ; \ fi /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `_intel_fast_memset' /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `_intel_fast_memcpy' /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `__intel_sse2_strlen' /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `__intel_sse2_strncmp' collect2: error: ld returned 1 exit status 0.03user 0.06system 0:00.31elapsed 31%CPU (0avgtext+0avgdata 9716maxresident)k 144inputs+48outputs (0major+10999minor)pagefaults 0swaps make[3]: [test_io_idx] Error 1 (ignored) make[3]: Leaving directory `/umbc/xfs1/zzbatmos/users/vy57456/model/gfortran/wrfchem4_0_c/WRF/external/io_int' It seems that I used ifort to compile MPICH. But I used gfortran. Any help? Zhifeng On Thu, Oct 18, 2018 at 10:19 AM Si, Min <msi(a)anl.gov<mailto:[email protected]>> wrote: Hi Zhifeng, It looks like the Intel c++ compiler icpc is used for linking. Maybe you did not specify `CXX=g++` at configure time. Please try this (make sure all compilers are with the same version) ./configure <other config options> CC=gcc CXX=g++ FC=gfortran F77=gfortran If you still see the installation error, please send us the config.log at your build directory together with the error message. Min On 2018/10/18 8:28, Zhifeng Yang wrote: Hi I tried to install mpich using gcc. However, while make, I got the following error message. libtool: link: icpc -shared src/binding/cxx/.libs/initcxx.o -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/source_code/mpich-3.2.1/lib/.libs -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/mpich-3.2.1/lib -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib lib/.libs/libmpi.so -lpthread -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4 -L/cm/shared/apps/slurm/14.11.11/lib64/slurm -L/cm/shared/apps/slurm/14.11.11/lib64 -L/usr/cluster/contrib/hdf5/install-1.8.16/lib -L/cm/shared/apps/acml/current/ifort64/lib -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64 -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64/ -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/ -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64 -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64/ -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4/ -L/cm/shared/apps/slurm/14.11.11/lib64/slurm/ -L/cm/shared/apps/slurm/14.11.11/lib64/ -L/usr/cluster/contrib/hdf5/install-1.8.16/lib/ -L/cm/shared/apps/acml/current/ifort64/lib/ -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../ -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -limf -lirng -lm -lipgo -ldecimal -lcilkrts /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so -lintlc -lsvml -lgcc -lgcc_s -lirc_s -ldl -lc -O2 -Wl,-soname -Wl,libmpicxx.so.12 -o lib/.libs/libmpicxx.so.12.1.1 /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so: could not read symbols: File in wrong format make[2]: *** [lib/libmpicxx.la<http://libmpicxx.la>] Error 1 make[2]: Leaving directory `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' make: *** [all] Error 2 Do you have any experience on this error? Thank you Zhifeng _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] mpich install error (libstdc++.so)
by Zhifeng Yang 18 Oct '18

18 Oct '18

Hi Min, You may want to see my config.log file while configuring MPICH. Here it is. It seems that there are some intel compiler path. But I am not sure whether they affect my make. Thank you Zhifeng On Thu, Oct 18, 2018 at 1:23 PM Zhifeng Yang <yangzf01(a)gmail.com> wrote: > Hi Min, > > Thank you very much for your help. Now I installed MPICH successfully. > > However, when I use it for another weather model. It has the following > error. > > time mpif90 -w -ffree-form -ffree-line-length-none -fconvert=big-endian > -frecord-marker=4 -fopenmp -o test_io_idx test_io_idx.f -L. -lwrfio_int > > real 0m0.234s > user 0m0.076s > sys 0m0.042s > if [ -f ../../frame/pack_utils.o -a -f ../../frame/clog.o ] ; then \ > time mpif90 -w -ffree-form -ffree-line-length-none > -fconvert=big-endian -frecord-marker=4 -fopenmp -I../ioapi_share -o > diffwrf diffwrf.f \ > ../../frame/pack_utils.o > ../../frame/module_internal_header_util.o > ../../frame/module_driver_constants.o ../../frame/module_machine.o > ../../frame/module_wrf_error.o ../../frame/wrf_debug.o libwrfio_int.a ; \ > fi > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `_intel_fast_memset' > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `_intel_fast_memcpy' > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `__intel_sse2_strlen' > /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: > undefined reference to `__intel_sse2_strncmp' > collect2: error: ld returned 1 exit status > 0.03user 0.06system 0:00.31elapsed 31%CPU (0avgtext+0avgdata > 9716maxresident)k > 144inputs+48outputs (0major+10999minor)pagefaults 0swaps > make[3]: [test_io_idx] Error 1 (ignored) > make[3]: Leaving directory > `/umbc/xfs1/zzbatmos/users/vy57456/model/gfortran/wrfchem4_0_c/WRF/external/io_int' > > It seems that I used ifort to compile MPICH. But I used gfortran. Any help? > > Zhifeng > > > On Thu, Oct 18, 2018 at 10:19 AM Si, Min <msi(a)anl.gov> wrote: > >> Hi Zhifeng, >> >> It looks like the Intel c++ compiler icpc is used for linking. Maybe you >> did not specify `CXX=g++` at configure time. >> >> Please try this (make sure all compilers are with the same version) >> ./configure <other config options> CC=gcc CXX=g++ FC=gfortran F77=gfortran >> >> If you still see the installation error, please send us the config.log at >> your build directory together with the error message. >> >> Min >> On 2018/10/18 8:28, Zhifeng Yang wrote: >> >> Hi >> >> I tried to install mpich using gcc. However, while make, I got the >> following error message. >> >> libtool: link: icpc -shared src/binding/cxx/.libs/initcxx.o >> -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/source_code/mpich-3.2.1/lib/.libs >> -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib >> -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/mpich-3.2.1/lib >> -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib lib/.libs/libmpi.so >> -lpthread >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64 >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4 >> -L/cm/shared/apps/slurm/14.11.11/lib64/slurm >> -L/cm/shared/apps/slurm/14.11.11/lib64 >> -L/usr/cluster/contrib/hdf5/install-1.8.16/lib >> -L/cm/shared/apps/acml/current/ifort64/lib >> -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64 >> -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64/ >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/ >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64 >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64/ >> -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64/ >> -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4/ >> -L/cm/shared/apps/slurm/14.11.11/lib64/slurm/ >> -L/cm/shared/apps/slurm/14.11.11/lib64/ >> -L/usr/cluster/contrib/hdf5/install-1.8.16/lib/ >> -L/cm/shared/apps/acml/current/ifort64/lib/ >> -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../ >> -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -limf -lirng -lm -lipgo -ldecimal >> -lcilkrts /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so -lintlc -lsvml >> -lgcc -lgcc_s -lirc_s -ldl -lc -O2 -Wl,-soname -Wl,libmpicxx.so.12 -o >> lib/.libs/libmpicxx.so.12.1.1 >> /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so: could not read >> symbols: File in wrong format >> make[2]: *** [lib/libmpicxx.la] Error 1 >> make[2]: Leaving directory >> `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory >> `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' >> make: *** [all] Error 2 >> >> >> Do you have any experience on this error? Thank you >> >> Zhifeng >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] mpich install error (libstdc++.so)
by Zhifeng Yang 18 Oct '18

18 Oct '18

Hi Min, Thank you very much for your help. Now I installed MPICH successfully. However, when I use it for another weather model. It has the following error. time mpif90 -w -ffree-form -ffree-line-length-none -fconvert=big-endian -frecord-marker=4 -fopenmp -o test_io_idx test_io_idx.f -L. -lwrfio_int real 0m0.234s user 0m0.076s sys 0m0.042s if [ -f ../../frame/pack_utils.o -a -f ../../frame/clog.o ] ; then \ time mpif90 -w -ffree-form -ffree-line-length-none -fconvert=big-endian -frecord-marker=4 -fopenmp -I../ioapi_share -o diffwrf diffwrf.f \ ../../frame/pack_utils.o ../../frame/module_internal_header_util.o ../../frame/module_driver_constants.o ../../frame/module_machine.o ../../frame/module_wrf_error.o ../../frame/wrf_debug.o libwrfio_int.a ; \ fi /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `_intel_fast_memset' /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `_intel_fast_memcpy' /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `__intel_sse2_strlen' /umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/mpich-3.2.1/lib/libmpi.so: undefined reference to `__intel_sse2_strncmp' collect2: error: ld returned 1 exit status 0.03user 0.06system 0:00.31elapsed 31%CPU (0avgtext+0avgdata 9716maxresident)k 144inputs+48outputs (0major+10999minor)pagefaults 0swaps make[3]: [test_io_idx] Error 1 (ignored) make[3]: Leaving directory `/umbc/xfs1/zzbatmos/users/vy57456/model/gfortran/wrfchem4_0_c/WRF/external/io_int' It seems that I used ifort to compile MPICH. But I used gfortran. Any help? Zhifeng On Thu, Oct 18, 2018 at 10:19 AM Si, Min <msi(a)anl.gov> wrote: > Hi Zhifeng, > > It looks like the Intel c++ compiler icpc is used for linking. Maybe you > did not specify `CXX=g++` at configure time. > > Please try this (make sure all compilers are with the same version) > ./configure <other config options> CC=gcc CXX=g++ FC=gfortran F77=gfortran > > If you still see the installation error, please send us the config.log at > your build directory together with the error message. > > Min > On 2018/10/18 8:28, Zhifeng Yang wrote: > > Hi > > I tried to install mpich using gcc. However, while make, I got the > following error message. > > libtool: link: icpc -shared src/binding/cxx/.libs/initcxx.o > -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/source_code/mpich-3.2.1/lib/.libs > -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib > -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/mpich-3.2.1/lib > -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib lib/.libs/libmpi.so > -lpthread > -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64 > -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64 > -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64 > -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64 > -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4 > -L/cm/shared/apps/slurm/14.11.11/lib64/slurm > -L/cm/shared/apps/slurm/14.11.11/lib64 > -L/usr/cluster/contrib/hdf5/install-1.8.16/lib > -L/cm/shared/apps/acml/current/ifort64/lib > -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64 > -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64/ > -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/ > -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64 > -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64/ > -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ > -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64/ > -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64/ > -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64/ > -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64/ > -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4/ > -L/cm/shared/apps/slurm/14.11.11/lib64/slurm/ > -L/cm/shared/apps/slurm/14.11.11/lib64/ > -L/usr/cluster/contrib/hdf5/install-1.8.16/lib/ > -L/cm/shared/apps/acml/current/ifort64/lib/ > -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../ > -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -limf -lirng -lm -lipgo -ldecimal > -lcilkrts /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so -lintlc -lsvml > -lgcc -lgcc_s -lirc_s -ldl -lc -O2 -Wl,-soname -Wl,libmpicxx.so.12 -o > lib/.libs/libmpicxx.so.12.1.1 > /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so: could not read symbols: > File in wrong format > make[2]: *** [lib/libmpicxx.la] Error 1 > make[2]: Leaving directory > `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' > make: *** [all] Error 2 > > > Do you have any experience on this error? Thank you > > Zhifeng > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] mpich install error (libstdc++.so)
by Si, Min 18 Oct '18

18 Oct '18

Hi Zhifeng, It looks like the Intel c++ compiler icpc is used for linking. Maybe you did not specify `CXX=g++` at configure time. Please try this (make sure all compilers are with the same version) ./configure <other config options> CC=gcc CXX=g++ FC=gfortran F77=gfortran If you still see the installation error, please send us the config.log at your build directory together with the error message. Min On 2018/10/18 8:28, Zhifeng Yang wrote: Hi I tried to install mpich using gcc. However, while make, I got the following error message. libtool: link: icpc -shared src/binding/cxx/.libs/initcxx.o -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/source_code/mpich-3.2.1/lib/.libs -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib -Wl,-rpath,/home/vy57456/zzbatmos_user/application/gfortran/mpich-3.2.1/lib -Wl,-rpath,/cm/shared/apps/gcc/4.8.4/lib/../lib lib/.libs/libmpi.so -lpthread -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64 -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4 -L/cm/shared/apps/slurm/14.11.11/lib64/slurm -L/cm/shared/apps/slurm/14.11.11/lib64 -L/usr/cluster/contrib/hdf5/install-1.8.16/lib -L/cm/shared/apps/acml/current/ifort64/lib -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64 -L/cm/shared/apps/slurm/14.11.11/lib64/../lib64/ -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/ -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64 -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../lib64/ -L/lib/../lib64 -L/lib/../lib64/ -L/usr/lib/../lib64 -L/usr/lib/../lib64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/../compiler/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/ipp/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/compiler/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/mkl/lib/intel64/ -L/cm/shared/apps/intel/composer_xe/2015.5.223/tbb/lib/intel64/gcc4.4/ -L/cm/shared/apps/slurm/14.11.11/lib64/slurm/ -L/cm/shared/apps/slurm/14.11.11/lib64/ -L/usr/cluster/contrib/hdf5/install-1.8.16/lib/ -L/cm/shared/apps/acml/current/ifort64/lib/ -L/cm/shared/apps/gcc/4.8.4/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../ -L/lib64 -L/lib/ -L/usr/lib64 -L/usr/lib -limf -lirng -lm -lipgo -ldecimal -lcilkrts /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so -lintlc -lsvml -lgcc -lgcc_s -lirc_s -ldl -lc -O2 -Wl,-soname -Wl,libmpicxx.so.12 -o lib/.libs/libmpicxx.so.12.1.1 /cm/shared/apps/gcc/4.8.4/lib/../lib/libstdc++.so: could not read symbols: File in wrong format make[2]: *** [lib/libmpicxx.la<http://libmpicxx.la>] Error 1 make[2]: Leaving directory `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/umbc/xfs1/zzbatmos/users/vy57456/application/gfortran/source_code/mpich-3.2.1' make: *** [all] Error 2 Do you have any experience on this error? Thank you Zhifeng _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0