Re: [OMPI devel] Annual OMPI membership review: SVN accounts
Please keep all three accounts from Dresden. > Dresden > = > knuepfer: Andreas Knuepfer <andreas.knuep...@tu-dresden.de> **NO COMMITS IN > LAST YEAR** > bwesarg: Bert Wesarg <bert.wes...@tu-dresden.de> **NO COMMITS IN LAST YEAR** > jurenz: Matthias Jurenz <matthias.jur...@tu-dresden.de> > -- Dr. rer. nat. Andreas Knüpfer Senior Scientist Technische Universität Dresden Center for Information Services and HPC (ZIH) Willersbau A114, Zellescher Weg 12, 01062 Dresden Tel. +49 351 463 38323 Fax. +49 351 463 37773 Email: andreas.knuep...@tu-dresden.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [OMPI devel] OpenMPI CUDA 5 readiness?
Hi Dmitry, Rolf, all, sorry for this, the API changes are a constant pain with new CUDA releases. One quick fix is to pass '--disable-cudawrap' to VTs configure. In case CUDA's CUPTI is found, you'll still get the full functionality. But of course we'll adapt to CUDA 5 asap with the help of your patch. Andreas On Sunday, September 02, 2012 20:41:51 Dmitry N. Mikushin wrote: > Dear Rolf, > > FYI, looks like with CUDA 5 preview OpenMPI trunk fails to build due > to the following errors: > > $ svn info > Path: . > URL: http://svn.open-mpi.org/svn/ompi/trunk > Repository Root: http://svn.open-mpi.org/svn/ompi > Repository UUID: 63e3feb5-37d5-0310-a306-e8a459e722fe > Revision: 27216 > Node Kind: directory > Schedule: normal > Last Changed Author: alekseys > Last Changed Rev: 27216 > Last Changed Date: 2012-09-02 15:17:49 +0200 (Sun, 02 Sep 2012) > > $ ../configure --prefix=$RPM_BUILD_ROOT/opt/kernelgen > --disable-mpi-interface-warning --with-cuda=/opt/cuda > --with-cuda-libdir=/usr/lib > > $ make -j8 > ... > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudartwrap.c:145:14: > error: conflicting types for 'cudaGetSymbolAddress' > /usr/local/cuda/include/cuda_runtime_api.h:4261:39: note: previous > declaration of 'cudaGetSymbolAddress' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudartwrap.c:164:14: > error: conflicting types for 'cudaGetSymbolSize' > /usr/local/cuda/include/cuda_runtime_api.h:4283:39: note: previous > declaration of 'cudaGetSymbolSize' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudartwrap.c:392:14: > error: conflicting types for 'cudaGetTextureReference' > /usr/local/cuda/include/cuda_runtime_api.h:5060:39: note: previous > declaration of 'cudaGetTextureReference' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudartwrap.c:501:14: > error: conflicting types for 'cudaFuncGetAttributes' > /usr/local/cuda/include/cuda_runtime_api.h:2242:58: note: previous > declaration of 'cudaFuncGetAttributes' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudartwrap.c:969:14: > error: conflicting types for 'cudaGetSurfaceReference' > /usr/local/cuda/include/cuda_runtime_api.h:5112:39: note: previous > declaration of 'cudaGetSurfaceReference' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudartwrap.c:1565:14: > error: conflicting types for 'cudaFuncSetSharedMemConfig' > /usr/local/cuda/include/cuda_runtime_api.h:2173:39: note: previous > declaration of 'cudaFuncSetSharedMemConfig' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudart.c:2294:14: error: > conflicting types for 'cudaMemcpyToSymbol' > /usr/local/cuda/include/cuda_runtime_api.h:3608:39: note: previous > declaration of 'cudaMemcpyToSymbol' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudart.c:2310:14: error: > conflicting types for 'cudaMemcpyFromSymbol' > /usr/local/cuda/include/cuda_runtime_api.h:3643:39: note: previous > declaration of 'cudaMemcpyFromSymbol' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudart.c:2423:14: error: > conflicting types for 'cudaMemcpyToSymbolAsync' > /usr/local/cuda/include/cuda_runtime_api.h:3990:39: note: previous > declaration of 'cudaMemcpyToSymbolAsync' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudart.c:2439:14: error: > conflicting types for 'cudaMemcpyFromSymbolAsync' > /usr/local/cuda/include/cuda_runtime_api.h:4032:39: note: previous > declaration of 'cudaMemcpyFromSymbolAsync' was here > ../../../../../../ompi/contrib/vt/vt/vtlib/vt_cudart.c:2534:14: error: > conflicting types for 'cudaLaunch' > /usr/local/cuda/include/cuda_runtime_api.h:2209:39: note: previous > declaration of 'cudaLaunch' was here > > Best regards, > - Dima. > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Dr. rer. nat. Andreas Knüpfer Senior Scientist Technische Universität Dresden Center for Information Services and HPC (ZIH) Willersbau A114, Zellescher Weg 12, 01062 Dresden Tel. +49 351 463 38323 Fax. +49 351 463 37773 Email: andreas.knuep...@tu-dresden.de smime.p7s Description: S/MIME cryptographic signature
Re: [OMPI devel] vampirtrace on v1.3 branch
On Tuesday 28 April 2009, Terry Dontje wrote: > Has anyone tested running a simple program compiled with mpicc-vt that > was built on RHEL 5.1 or SLES-10 with gcc under 32 bits? > > I am seeing the following errors when running compiled code: > VampirTrace: BFD: bfd_get_file_flags(): failed > > Note the trunk seems to be working fine and I have other issues with 64 > bit (that I haven't debugged). I see similar errors with Sun Studio. > > --td Hi Terry, this has to do with resolving the symbols in the executable themselves. In order to find the problem, could you please send me the output of 'ldd' with this executable. Do you need a workaround for the problem for now? There is an easy one, but I assume this was only a test, wasn't it? Andreas smime.p7s Description: S/MIME cryptographic signature
Re: [OMPI devel] vt configuration issues
On Thursday 28 February 2008, Jeff Squyres wrote: > I can't remember if I posted about this before or not -- should we > disable trunk/VT building by default while the configuration issues > are being worked out? Which config issues are you refering to? Is it about the 'make distclean' that fails if you explicitly disabled VT before? I see no easy fix for this, because you will get an incomplete set of Makefiles if you ask for an incomplete configure. Yet, by default everything should be fine. Therefore, I'd like to keep it enabled by default ... well, of course I would ;) Are there any other isses open with VT config? Andreas -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773
Re: [OMPI devel] 1.3 Release schedule and contents
The VampirTrace integration is already in the trunk. It should be mentioned as complete somewhere in the misc section. Andreas signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] VT integration: make distclean problem
On Monday 11 February 2008, Josh Hursey wrote: > I've been noticing another problem with the VT integration. If you do > a "./configure --enable-contrib-no-build=vt" a subsequent 'make > distclean' will fail in contrib/vt. The 'make distclean' will succeed > with VT enabled (default). > hm, tricky. I guess it is about the 'make dist' functionality. All others like 'make distclean' etc. are only assisting functionality for 'make dist' after all. And for 'make dist' you need to have everything configured that is going to be part of the distribution. Therefore, VT needs to be part of the tarball, so you can disable it at build time. It would not work the other way around. So in my opinion, the current status is what we want to have. Are there any problems when configuring VT, then building the tarball with VT and disabling it once you build Open MPI from the tarball? Regards, Andreas -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] VT in trunk + how to disable
Hi Josh, hi everybody, we'd like to have VampirTrace enabled by default -- well, of course we do ;) Our main reason is the potential users: As soon as they want to use our tool they want to use it with the same configuration as the default Open MPI installation. Making the administrator re-install it at this point would be most inconvenient. If you're _not_ using our tools, you will _not_ see any difference at all while using the Open MPI installation or running your MPI program. And regarding configuration and compilation of Open MPI itself, we try hard to make everything robust and smooth. As there is no one insisting in disabled by default, we'd like to keep it enabled by default. I hope this is ok with everybody. Best regards, Andreas -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] vt compiler warnings and errors
Hi Everbody, we discussed this issue here a lot. Indeed, we were putting the contents of the VampirTrace tarball to the trunk (via the vendor branch stuff). Then again, this is no virtue by itself, is it? So we agree to removing the configure scripts from the SVN and having it created by the autogen script. This might resolve possible problems because of differing autoconf versions etc. See/hear you at the telco, Andreas On Friday 01 February 2008, Jeff Squyres wrote: > On Feb 1, 2008, at 5:35 AM, Ralf Wildenhues wrote: > > These files do not belong in SVN, they are generated by aclocal: > > ompi/contrib/vt/vt/extlib/otf/aclocal.m4 > > ompi/contrib/vt/vt/aclocal.m4 > > I think both of these have their own configure scripts, meaning that > they were autoconfed/automaked/whatever before they were put into OMPI. > > And in hindsight, this fits in with exactly what our original goal > was: take a VT tarball and dump it into OMPI's SVN. Doh! > > So I think the question still remains: can we hook VT's autoconf (et > al.) requirements into the top-level autogen.sh so that the trunk copy > of vt doesn't have configure/aclocal.m4/etc. and OMPI's top-level > autogen.sh will create them? -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] vt compiler warnings and errors
Hi everybody, now this is an interesting effect. After a fresh checkout all files have the actual time, haven't they? Is the timestamp explicitly saved somewhere? Could it be, that this is newer than Tim's local time yesterday? Maybe the system time is not set to UTC or something like this? If so, then it should be possible to reproduce this today. Could you give it a try, Tim? Another cause could be slight differences in files' times because one is checked out earlier than the other. However, OTF's configure ran before during the first global configure. Therefore, all files' timestamps should be correct after this. So I don't believe in this explanation. What do you think? -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] VT integration
On Friday 21 September 2007, Jeff Squyres wrote: > Per an idea that came up recently, can we make it so that ompi_info > reports the version of VT that is integrated into Open MPI? good idea, we'll pick it up real soon Andreas -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 pgpDaSfrXdqLr.pgp Description: PGP signature
