Is there a reason that all of the necessary routines aren't added to the libmpich (and/or libpmpich when weak symbol aliases aren't available)? We have users who do not use the compilation scripts and expect to provide a single include path for compiling and library for linking (which admittedly doesn't work if they need additional system libraries, such as -lpthread, though such users are often used to adding system libraries). And I just had a bunch of tests fail because libmpl wasn't found (a different problem, caused by an inconsistent setting of prefix). Even if the libraries are built using the so-called convenience library model (which we'll probably need to adopt to make use of the other autotools), the libraries can be merged at the end of the build. Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
Hi Bill, I think there are two problems here: 1. How do we merge the libraries at the end of the build? I did look for this sometime back, but didn't find a good way of doing this. If this is possible, then we can merge libmpich.a, libopa.a and libmpl.a into a single library. 2. The number of libraries mpich2 depends on is quite a few (e.g., pthreads, PVFS when ROMIO is configured with PVFS, MX or IB libraries when Nemesis is configured with these networks, coverage flags). So, using a single libmpich.a would be incorrect in these cases anyway, even if we are able to merge libmpich, opa and mpl. If users are trying to use a single library, shouldn't we explain these problems so they can correct their build, instead? -- Pavan On 12/30/2009 11:22 AM, William Gropp wrote:
Is there a reason that all of the necessary routines aren't added to the libmpich (and/or libpmpich when weak symbol aliases aren't available)? We have users who do not use the compilation scripts and expect to provide a single include path for compiling and library for linking (which admittedly doesn't work if they need additional system libraries, such as -lpthread, though such users are often used to adding system libraries). And I just had a bunch of tests fail because libmpl wasn't found (a different problem, caused by an inconsistent setting of prefix). Even if the libraries are built using the so-called convenience library model (which we'll probably need to adopt to make use of the other autotools), the libraries can be merged at the end of the build.
Bill
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
On Wed, Dec 30, 2009 at 12:45:28PM -0600, Pavan Balaji wrote:
Hi Bill,
I think there are two problems here:
1. How do we merge the libraries at the end of the build? I did look for this sometime back, but didn't find a good way of doing this. If this is possible, then we can merge libmpich.a, libopa.a and libmpl.a into a single library.
2. The number of libraries mpich2 depends on is quite a few (e.g., pthreads, PVFS when ROMIO is configured with PVFS, MX or IB libraries when Nemesis is configured with these networks, coverage flags). So, using a single libmpich.a would be incorrect in these cases anyway, even if we are able to merge libmpich, opa and mpl.
Hi Pavan. PVFS MX and IB fall into the same category as pthread: libraries necessary to funciton, but outside of MPICH2. I think it's safe to assume that sites know where their PVFS, MX, or IB libraries are installed and can make things work. One thing we do in PVFS that I like a lot is the "pvfs2-config" utility: % ~/work/soft/pvfs2/bin/pvfs2-config --cflags -I/home/robl/work/soft/pvfs2/include % ~/work/soft/pvfs2/bin/pvfs2-config --libs -L/home/robl/work/soft/pvfs2/lib -lpvfs2 -lcrypto -lssl -lpthread Now I don't have to care that PVFS requires other outside libraries: i just drop a LDFLAGS=$(pvfs2-config --libs) into my build process. In PVFS the internal PVFS libraries like trove and bmi still end up in one libpvfs2.a, so maybe this is not a solution to Bill's query after all.
If users are trying to use a single library, shouldn't we explain these problems so they can correct their build, instead?
-- Pavan
On 12/30/2009 11:22 AM, William Gropp wrote:
Is there a reason that all of the necessary routines aren't added to the libmpich (and/or libpmpich when weak symbol aliases aren't available)? We have users who do not use the compilation scripts and expect to provide a single include path for compiling and library for linking (which admittedly doesn't work if they need additional system libraries, such as -lpthread, though such users are often used to adding system libraries). And I just had a bunch of tests fail because libmpl wasn't found (a different problem, caused by an inconsistent setting of prefix). Even if the libraries are built using the so-called convenience library model (which we'll probably need to adopt to make use of the other autotools), the libraries can be merged at the end of the build.
Bill
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA
On 01/04/2010 08:56 AM, Rob Latham wrote:
One thing we do in PVFS that I like a lot is the "pvfs2-config" utility:
% ~/work/soft/pvfs2/bin/pvfs2-config --cflags -I/home/robl/work/soft/pvfs2/include % ~/work/soft/pvfs2/bin/pvfs2-config --libs -L/home/robl/work/soft/pvfs2/lib -lpvfs2 -lcrypto -lssl -lpthread
Yes, that's correct. In fact, if the user really wants, he/she can do an mpicc -show to see what all libs are required and just use them. But my point here was really that relying on the fact that MPICH2 will use a single library is fundamentally flawed. We should teach users to use the correct approach (either use wrappers or pkg_config or something else), instead of directly trying to link against libmpich.a. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
participants (3)
-
Pavan Balaji -
Rob Latham -
William Gropp