Re: [OMPI devel] VampirTrace and MPI_Init_thread()
On Saturday 14 August 2010 00:10:49 Lisandro Dalcin wrote: > On 13 August 2010 05:22, Matthias Jurenz wrote: > > On Wednesday 11 August 2010 23:16:50 Lisandro Dalcin wrote: > >> On 11 August 2010 03:12, Matthias Jurenz > > > > wrote: > >> > Hello Lisandro, > >> > > >> > this problem will be fixed in the next Open MPI release. There was an > >> > obsolete preprocessor condition around the MPI_Init_thread wrapper, so > >> > the source code could never be compiled :-( > >> > > >> > Thanks for the hint. > >> > > >> > Matthias > >> > >> OK. Many thanks for you clarification. > >> > >> BTW, I have and additional issue. I'm trying to build as shared > >> library from libvt*.a using by passing -whole-archive to the linker. > >> The idea behind this is to use that library with LD_PRELOAD to get MPI > >> tracing of a binary compiled with plain mpicc (i.e, not mpicc-vt). For > >> example, I managed to get this trick working with MPE. Moreover, I can > >> enable MPI profiling at runtime in a Python script using mpi4pt by > >> dlopen'ing the shared lib with profiling symbols before loading the > >> mpi4py.MPI Python extension module. Being able to profile without a > >> recompile is nice ;-) > >> > >> However, see this: > >> > >> $ pwd > >> /usr/local/openmpi/1.4.2/lib > >> > >> $ ll libvt* > >> -rw-r--r--. 1 root root 410784 2010-05-05 20:40 libvt.a > >> -rw-r--r--. 1 root root 197618 2010-05-05 20:40 libvt.fmpi.a > >> -rw-r--r--. 1 root root 569128 2010-05-05 20:40 libvt.mpi.a > >> -rw-r--r--. 1 root root 503514 2010-05-05 20:40 libvt.omp.a > >> -rw-r--r--. 1 root root 661466 2010-05-05 20:40 libvt.ompi.a > >> > >> $ nm libvt* | grep pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> U pomp_rd_table > >> > >> That symbol (and possibly others) are undefined and I cannot found > >> them elsewhere. Is there any easy way to build a shared lib with the > >> MPI_xxx symbols? > > > > Actually, the symbols above will be defined at compile/link time of the > > application by the OpenMP instrumentor "OPARI". > > However, while your application doesn't use OpenMP it should work to > > define the missing symbols in a separate source file (see attachment) > > when building the shared library: > > > > gcc -fPIC -I/vampirtrace -shared missing_syms.c -o > > libvt.mpi.so -Wl,--whole-archive /libvt.mpi.a > libdir>/libotf.a -Wl,--no-whole-archive -ldl -lz -L -lmpi > > OK. Many thanks for the hint. > > I was able to build a shared lib, dlopen() it at runtime and get MPI > traces from Python scripts without need of recompiles with mpicc-vt. > Sweet! > > > FYI, the next Open MPI 1.5 will come with a newer VampirTrace which > > provides shared libraries by default. > > Nice! ... Perhaps Open MPI mpiexec's could gain a -vt flag to enable > traces at runtime (should be easy to implement with LD_PRELOAD, > right?)... We plan to provide the script "vtpreload.sh" in future releases of VampirTrace which can be prepended to the application executable, like: mpirun -np 2 vtpreload.sh In addition to preloading the VT library to get the MPI functions, the script will be capable to instrument almost each other function by using binary instrumentation. Furthermore, it will do some nm/ldd magic to determine the suitable VT library to preload. An additional '-vt' flag for mpirun sounds good. This flags could also receive some options for the vtpreload script. > > BTW, I understand Open MPI 1.5 VT will have the MPI_Init_thread() > issue fixed. Any chance for v1.4 series? > Yes, it will be fixed in Open MPI 1.4.3, too. Matthias smime.p7s Description: S/MIME cryptographic signature
[OMPI devel] autogen.sh improvements
I just wanted to give the community a heads up that Ralph, Brian, and I are revamping autogen in a Mercurial branch. I don't know the exact timeline to completion, but it won't be *too* far in the future. We made some core changes, and then made some other changes that necessitated minor edits to many component Makefile.am's and configure.m4's. So the overall commit will look *much* bigger than it really is. But it's all good stuff. :-) Here's a list of the intended high-level changes: Improvements: - 1. "autogen.sh" is now "autogen.pl" (i.e., autogen is now in perl, not Bourne) --> We can put a sym link in SVN so that the old name still works, if it's important to people 2. the project/framework/component discovery is quite a bit faster 3. the perl code is a LOT easier to maintain (and add features to) 4. autogen.pl defaults to --no-ompi if ompi/ is not present (which is good for OPAL+ORTE tarballs) 5. ompi_mca.m4 has been cleaned up a bit, allowing autogen.pl to be a little dumber than autogen.sh 6. vprotocol components now live in ompi/mca/vprotocol (instead of ompi/mca/pml/v/mca/vprotocol) 7. a few more "OMPI" name cleanups (e.g., s/ompi/mca/gi and s/ompi/opal/gi where relevant) New features: - 1. configure.params won't be necessary for components that have no configure.m4 and only have a single Makefile.am 2. configure.params won't be necessary for components that call AC_CONFIG_FILES themselves in their configure.m4 file 3. added --enable-mca-only-build= option (opposite of --enable-mca-no-build) 4. autogen.pl accepts --platform= argument, just like configure Dropped features: - 1. component configure.stub files are no longer supported 2. component compile-time priorities are no longer supported (or necessary) 3. SVK is no longer supported 4. it is not possible to run autogen.pl from a component directory -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] autogen.sh improvements
> 5. ompi_mca.m4 has been cleaned up a bit, allowing autogen.pl to be a > little dumber than autogen.sh So you are dumbing down in search of improvements ?
Re: [OMPI devel] autogen.sh improvements
> > 5. ompi_mca.m4 has been cleaned up a bit, allowing autogen.pl to be a > > little dumber than autogen.sh > > So you are dumbing down in search of improvements ? > Apologies. That was only meant to go to Jeff Squyres. Kevin
Re: [OMPI devel] autogen.sh improvements
Yes - autogen dumbs down by spreading the "smarts" across other parts of the build system, and removing complexity that we no longer use or need On Aug 16, 2010, at 5:23 PM, kevin.buck...@ecs.vuw.ac.nz wrote: >> 5. ompi_mca.m4 has been cleaned up a bit, allowing autogen.pl to be a >> little dumber than autogen.sh > > So you are dumbing down in search of improvements ? > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] autogen.sh improvements
'zactly what Ralph said. The m4 parts got a little smarter (because they really should have been smarter to begin with). As a result, autogen could get a little stupider. :-) On Aug 16, 2010, at 4:43 PM, Ralph Castain wrote: > Yes - autogen dumbs down by spreading the "smarts" across other parts of the > build system, and removing complexity that we no longer use or need > > > On Aug 16, 2010, at 5:23 PM, kevin.buck...@ecs.vuw.ac.nz wrote: > >>> 5. ompi_mca.m4 has been cleaned up a bit, allowing autogen.pl to be a >>> little dumber than autogen.sh >> >> So you are dumbing down in search of improvements ? >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
