mpich2-1.1.1rc1 tarball sanity checking
I've created an mpich2-1.1.1rc1 tarball and placed it in the web space. I haven't linked to it yet from the website or announced it on any of the lists. I've personally sanity checked it on my Mac, but we could probably use a quick look-over from others before officially releasing it. Also, I'll coordinate with Jayesh about windows binaries. You can get the RC from here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.1.1rc1/... -Dave
The build worked with gcc on vanquish. But when I tried with the CUDA compiler nvcc on bb36, it failed at the following location. 1.1 builds with nvcc. Rajeev make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util/thread' make[3]: Entering directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util/dbg' CC dbg_printf.c dbg_printf.c:56:1: warning: "va_copy" redefined In file included from ../../include/mpiimpl.h:48, from dbg_printf.c:16: /usr/lib/gcc/x86_64-linux-gnu/4.2.4/include/stdarg.h:54:1: warning: this is the location of the previous definition dbg_printf.c: In function ‘MPIU_dbglog_vprintf’: dbg_printf.c:240: error: incompatible types in assignment dbg_printf.c:270: error: incompatible types in assignment dbg_printf.c:277: error: incompatible types in assignment make[3]: *** [dbg_printf.o] Error 255 make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util/dbg' make[2]: *** [all-redirect] Error 2 make[2]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util' make[1]: *** [all-redirect] Error 2 make[1]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src' make: *** [all-redirect] Error 2 bb36:/sandbox/thakur/mpich2-1.1.1rc1%
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Goodell Sent: Friday, July 17, 2009 3:42 PM To: [email protected] Subject: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
I've created an mpich2-1.1.1rc1 tarball and placed it in the web space. I haven't linked to it yet from the website or announced it on any of the lists. I've personally sanity checked it on my Mac, but we could probably use a quick look-over from others before officially releasing it. Also, I'll coordinate with Jayesh about windows binaries.
You can get the RC from here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarb alls/1.1.1rc1/mpich2-1.1.1rc1.tar.gz
-Dave
This was caused by r4845. The nvcc compiler doesn't like multiple -Ox parameters, even if they specify the same optimization level. Pavan made the change but it looks like he has headed home for the evening. I'll take a look and see how we can avoid the duplicate flags. We'll hold off on the rc until Monday, I don't think that there's any way we can get this fixed and re-packaged by any reasonable hour tonight. -Dave On Jul 17, 2009, at 4:20 PM, Rajeev Thakur wrote:
The build worked with gcc on vanquish. But when I tried with the CUDA compiler nvcc on bb36, it failed at the following location. 1.1 builds with nvcc.
Rajeev
make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util/ thread' make[3]: Entering directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/dbg' CC dbg_printf.c dbg_printf.c:56:1: warning: "va_copy" redefined In file included from ../../include/mpiimpl.h:48, from dbg_printf.c:16: /usr/lib/gcc/x86_64-linux-gnu/4.2.4/include/stdarg.h:54:1: warning: this is the location of the previous definition dbg_printf.c: In function ‘MPIU_dbglog_vprintf’: dbg_printf.c:240: error: incompatible types in assignment dbg_printf.c:270: error: incompatible types in assignment dbg_printf.c:277: error: incompatible types in assignment make[3]: *** [dbg_printf.o] Error 255 make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util/ dbg' make[2]: *** [all-redirect] Error 2 make[2]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util' make[1]: *** [all-redirect] Error 2 make[1]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src' make: *** [all-redirect] Error 2 bb36:/sandbox/thakur/mpich2-1.1.1rc1%
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Goodell Sent: Friday, July 17, 2009 3:42 PM To: [email protected] Subject: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
I've created an mpich2-1.1.1rc1 tarball and placed it in the web space. I haven't linked to it yet from the website or announced it on any of the lists. I've personally sanity checked it on my Mac, but we could probably use a quick look-over from others before officially releasing it. Also, I'll coordinate with Jayesh about windows binaries.
You can get the RC from here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarb alls/1.1.1rc1/mpich2-1.1.1rc1.tar.gz
-Dave
I'm hiding and working on my paper. I'll try to fix it over the weekend. On Jul 17, 2009, at 4:46 PM, Dave Goodell <[email protected]> wrote:
This was caused by r4845. The nvcc compiler doesn't like multiple - Ox parameters, even if they specify the same optimization level. Pavan made the change but it looks like he has headed home for the evening. I'll take a look and see how we can avoid the duplicate flags.
We'll hold off on the rc until Monday, I don't think that there's any way we can get this fixed and re-packaged by any reasonable hour tonight.
-Dave
On Jul 17, 2009, at 4:20 PM, Rajeev Thakur wrote:
The build worked with gcc on vanquish. But when I tried with the CUDA compiler nvcc on bb36, it failed at the following location. 1.1 builds with nvcc.
Rajeev
make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/thread' make[3]: Entering directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/dbg' CC dbg_printf.c dbg_printf.c:56:1: warning: "va_copy" redefined In file included from ../../include/mpiimpl.h:48, from dbg_printf.c:16: /usr/lib/gcc/x86_64-linux-gnu/4.2.4/include/stdarg.h:54:1: warning: this is the location of the previous definition dbg_printf.c: In function ‘MPIU_dbglog_vprintf’: dbg_printf.c:240: error: incompatible types in assignment dbg_printf.c:270: error: incompatible types in assignment dbg_printf.c:277: error: incompatible types in assignment make[3]: *** [dbg_printf.o] Error 255 make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/dbg' make[2]: *** [all-redirect] Error 2 make[2]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/util' make[1]: *** [all-redirect] Error 2 make[1]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src' make: *** [all-redirect] Error 2 bb36:/sandbox/thakur/mpich2-1.1.1rc1%
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Goodell Sent: Friday, July 17, 2009 3:42 PM To: [email protected] Subject: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
I've created an mpich2-1.1.1rc1 tarball and placed it in the web space. I haven't linked to it yet from the website or announced it on any of the lists. I've personally sanity checked it on my Mac, but we could probably use a quick look-over from others before officially releasing it. Also, I'll coordinate with Jayesh about windows binaries.
You can get the RC from here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarb alls/1.1.1rc1/mpich2-1.1.1rc1.tar.gz
-Dave
It looks like it's caused because we add MPI_DEFAULT_COPTS (which contains "-O2") to both MPICH2_EXTRA_CFLAGS and CFLAGS on lines 1649-1654 and then we later temporarily add MPICH2_EXTRA_CFLAGS to CFLAGS for several tests. The right fix is probably to not add MPICH2_DEFAULT_COPTS (and friends) to CFLAGS. However, IIRC this is the mechanism that puts -O2 into the mpicc scripts, so we might have to add another variable to accomplish that still. -Dave On Jul 17, 2009, at 4:55 PM, Pavan Balaji wrote:
I'm hiding and working on my paper. I'll try to fix it over the weekend.
On Jul 17, 2009, at 4:46 PM, Dave Goodell <[email protected]> wrote:
This was caused by r4845. The nvcc compiler doesn't like multiple - Ox parameters, even if they specify the same optimization level. Pavan made the change but it looks like he has headed home for the evening. I'll take a look and see how we can avoid the duplicate flags.
We'll hold off on the rc until Monday, I don't think that there's any way we can get this fixed and re-packaged by any reasonable hour tonight.
-Dave
On Jul 17, 2009, at 4:20 PM, Rajeev Thakur wrote:
The build worked with gcc on vanquish. But when I tried with the CUDA compiler nvcc on bb36, it failed at the following location. 1.1 builds with nvcc.
Rajeev
make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/thread' make[3]: Entering directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/dbg' CC dbg_printf.c dbg_printf.c:56:1: warning: "va_copy" redefined In file included from ../../include/mpiimpl.h:48, from dbg_printf.c:16: /usr/lib/gcc/x86_64-linux-gnu/4.2.4/include/stdarg.h:54:1: warning: this is the location of the previous definition dbg_printf.c: In function ‘MPIU_dbglog_vprintf’: dbg_printf.c:240: error: incompatible types in assignment dbg_printf.c:270: error: incompatible types in assignment dbg_printf.c:277: error: incompatible types in assignment make[3]: *** [dbg_printf.o] Error 255 make[3]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util/dbg' make[2]: *** [all-redirect] Error 2 make[2]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src/ util' make[1]: *** [all-redirect] Error 2 make[1]: Leaving directory `/sandbox/thakur/mpich2-1.1.1rc1/src' make: *** [all-redirect] Error 2 bb36:/sandbox/thakur/mpich2-1.1.1rc1%
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Goodell Sent: Friday, July 17, 2009 3:42 PM To: [email protected] Subject: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
I've created an mpich2-1.1.1rc1 tarball and placed it in the web space. I haven't linked to it yet from the website or announced it on any of the lists. I've personally sanity checked it on my Mac, but we could probably use a quick look-over from others before officially releasing it. Also, I'll coordinate with Jayesh about windows binaries.
You can get the RC from here: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarb alls/1.1.1rc1/mpich2-1.1.1rc1.tar.gz
-Dave
It looks like it's caused because we add MPI_DEFAULT_COPTS (which contains "-O2") to both MPICH2_EXTRA_CFLAGS and CFLAGS on lines 1649-1654 and then we later temporarily add MPICH2_EXTRA_CFLAGS to CFLAGS for several tests. The right fix is probably to not add MPICH2_DEFAULT_COPTS (and friends) to CFLAGS. However, IIRC this is the mechanism that puts -O2 into the mpicc scripts, so we might have to add another variable to accomplish that still.
We don't add -O2 to mpicc and friends. The optimization flags are only for compiling MPICH2. I'll check what's going on. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
Can someone review the attached patch? I don't see a reason to maintain MPICH2_EXTRA_CFLAGS separately. A lot of autoconf and confdb macros anyway rely on having the flags set in CFLAGS. So, instead of adding these flags to MPICH2_EXTRA_CFLAGS and then adding them to CFLAGS every time we do a configure test, we should just add them to CFLAGS. I know that Anthony did this to avoid corrupting the precious variables, but autoconf/confdb seem to expect all the flags in CFLAGS and friends anyway. So, we ended up adding hacks to append these to CFLAGS each time. FWIW, all other projects seem to be adding stuff in CFLAGS as well. Also note that we do store the user-specified CFLAGS in WRAPPER_CFLAGS, so those are not lost either. The attached patch gets rid of MPICH2_EXTRA_CFLAGS and friends; if someone sees a problem with this, please let me know. Rajeev: can you see if this patch solves your problem? -- Pavan On 07/17/2009 09:58 PM, Pavan Balaji wrote:
It looks like it's caused because we add MPI_DEFAULT_COPTS (which contains "-O2") to both MPICH2_EXTRA_CFLAGS and CFLAGS on lines 1649-1654 and then we later temporarily add MPICH2_EXTRA_CFLAGS to CFLAGS for several tests. The right fix is probably to not add MPICH2_DEFAULT_COPTS (and friends) to CFLAGS. However, IIRC this is the mechanism that puts -O2 into the mpicc scripts, so we might have to add another variable to accomplish that still.
We don't add -O2 to mpicc and friends. The optimization flags are only for compiling MPICH2. I'll check what's going on.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
Yes, it works with this patch. A problem unrelated to the patch is that if I build with nvcc and g77, all Fortran tests in test/mpi/f77 fail to compile with the errors attached. If I use gcc, however, it works. This problem may have existed even earlier with 1.1; I didn't try to build the Fortran tests before. It may be something weird going on with nvcc. We can probably ignore it for now. Rajeev On Fri, 17 Jul 2009, Pavan Balaji wrote:
Can someone review the attached patch? I don't see a reason to maintain MPICH2_EXTRA_CFLAGS separately. A lot of autoconf and confdb macros anyway rely on having the flags set in CFLAGS. So, instead of adding these flags to MPICH2_EXTRA_CFLAGS and then adding them to CFLAGS every time we do a configure test, we should just add them to CFLAGS. I know that Anthony did this to avoid corrupting the precious variables, but autoconf/confdb seem to expect all the flags in CFLAGS and friends anyway. So, we ended up adding hacks to append these to CFLAGS each time.
FWIW, all other projects seem to be adding stuff in CFLAGS as well. Also note that we do store the user-specified CFLAGS in WRAPPER_CFLAGS, so those are not lost either. The attached patch gets rid of MPICH2_EXTRA_CFLAGS and friends; if someone sees a problem with this, please let me know.
Rajeev: can you see if this patch solves your problem?
-- Pavan
On 07/17/2009 09:58 PM, Pavan Balaji wrote:
It looks like it's caused because we add MPI_DEFAULT_COPTS (which contains "-O2") to both MPICH2_EXTRA_CFLAGS and CFLAGS on lines 1649-1654 and then we later temporarily add MPICH2_EXTRA_CFLAGS to CFLAGS for several tests. The right fix is probably to not add MPICH2_DEFAULT_COPTS (and friends) to CFLAGS. However, IIRC this is the mechanism that puts -O2 into the mpicc scripts, so we might have to add another variable to accomplish that still.
We don't add -O2 to mpicc and friends. The optimization flags are only for compiling MPICH2. I'll check what's going on.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
A problem unrelated to the patch is that if I build with nvcc and g77, all Fortran tests in test/mpi/f77 fail to compile with the errors attached. If I use gcc, however, it works. This problem may have existed even earlier with 1.1; I didn't try to build the Fortran tests before. It may be something weird going on with nvcc. We can probably ignore it for now.
Yup, this seems to have been broken in 1.1 itself. I'll take a look at it, though we shouldn't hold up 1.1.1 for it. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
It looks like this bug has been in MPICH2 forever. The configure checks if the C compiler requires to be linked with pthreads to compile thread programs and if it does, we add -lpthread to LDFLAGS. GCC requires it, but nvcc doesn't. But LDFLAGS are used by all compilers (CC, CXX, F77, F90). So, when the C compiler doesn't require this library but the other compilers do, things break. Rajeev: can you try the attached patch? -- Pavan On 07/19/2009 11:50 AM, Pavan Balaji wrote:
A problem unrelated to the patch is that if I build with nvcc and g77, all Fortran tests in test/mpi/f77 fail to compile with the errors attached. If I use gcc, however, it works. This problem may have existed even earlier with 1.1; I didn't try to build the Fortran tests before. It may be something weird going on with nvcc. We can probably ignore it for now.
Yup, this seems to have been broken in 1.1 itself. I'll take a look at it, though we shouldn't hold up 1.1.1 for it.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls. Rajeev FC /home/thakur/cvs/mpich2/test/mpi/f77/spawn/connaccf.f /home/thakur/mpich2-install/bin/mpif77 -lpthread -lpthread ../util/mtestf.o -o connaccf connaccf.o make[1]: Leaving directory `/sandbox/test/mpi/f77/spawn' make[1]: Entering directory `/sandbox/test/mpi/f77/io' ../../maint/testmerge -defn=/home/thakur/cvs/mpich2/test/mpi/maint/common.defn \ /home/thakur/cvs/mpich2/test/mpi/f77/io/ioharness.defn /home/thakur/cvs/mpich2/test/mpi/f77/io/ioharness.tlt Opening /home/thakur/cvs/mpich2/test/mpi/maint/common.defn.. FC iwriteatf.f /home/thakur/mpich2-install/bin/mpif77 -lpthread -lpthread -o iwriteatf iwriteatf.o \ ../util/mtestf.o /home/thakur/mpich2-install/lib/libmpich.a(mpidtime.o): In function `MPID_Wtick': mpidtime.c:(.text+0x19a): undefined reference to `clock_getres' /home/thakur/mpich2-install/lib/libmpich.a(mpidtime.o): In function `MPID_Wtime': mpidtime.c:(.text+0x96): undefined reference to `clock_gettime' /home/thakur/mpich2-install/lib/libmpich.a(ad_iwrite.o): In function `ADIOI_GEN_aio_wait_fn': ad_iwrite.c:(.text+0x154): undefined reference to `aio_suspend64' ad_iwrite.c:(.text+0x1f7): undefined reference to `aio_error64' ad_iwrite.c:(.text+0x20b): undefined reference to `aio_return64' /home/thakur/mpich2-install/lib/libmpich.a(ad_iwrite.o): In function `ADIOI_GEN_aio_poll_fn': ad_iwrite.c:(.text+0x2c6): undefined reference to `aio_error64' ad_iwrite.c:(.text+0x2ea): undefined reference to `aio_return64' /home/thakur/mpich2-install/lib/libmpich.a(ad_iwrite.o): In function `ADIOI_GEN_aio': ad_iwrite.c:(.text+0x47e): undefined reference to `aio_write64' ad_iwrite.c:(.text+0x4d7): undefined reference to `aio_read64' collect2: ld returned 1 exit status make[1]: *** [iwriteatf] Error 1 make[1]: Leaving directory `/sandbox/test/mpi/f77/io' make: *** [all-redirect] Error 2 bb36:/sandbox/test/mpi/f77%
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 2:23 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
It looks like this bug has been in MPICH2 forever. The configure checks if the C compiler requires to be linked with pthreads to compile thread programs and if it does, we add -lpthread to LDFLAGS. GCC requires it, but nvcc doesn't. But LDFLAGS are used by all compilers (CC, CXX, F77, F90). So, when the C compiler doesn't require this library but the other compilers do, things break.
Rajeev: can you try the attached patch?
-- Pavan
On 07/19/2009 11:50 AM, Pavan Balaji wrote:
A problem unrelated to the patch is that if I build with nvcc and g77, all Fortran tests in test/mpi/f77 fail to compile with the errors attached. If I use gcc, however, it works. This problem may have existed even earlier with 1.1; I didn't try to build
the Fortran
tests before. It may be something weird going on with nvcc. We can probably ignore it for now.
Yup, this seems to have been broken in 1.1 itself. I'll take a look at it, though we shouldn't hold up 1.1.1 for it.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls.
The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority. With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
Async I/O needs -lrt. If I manually add -lrt it works. Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 7:30 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls.
The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority.
With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
Ok, this is getting messier as we go. I've attached yet another patch, but this will now duplicate -lrt as well. The problem is that the entire build system is a big mess with a ton of hacks. And until we clean it up, these things will be hard to fix correctly. If it is OK with everyone, we can use this hack fix for the time being. But we *really* need to clean up the build system soon (I wish we could find some intern to do this for us). -- Pavan On 07/19/2009 07:56 PM, Rajeev Thakur wrote:
Async I/O needs -lrt. If I manually add -lrt it works.
Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 7:30 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls. The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority.
With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
Yes it works now. Do we feel comfortable enough with it to include it in 1.1.1? Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 9:45 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
Ok, this is getting messier as we go. I've attached yet another patch, but this will now duplicate -lrt as well.
The problem is that the entire build system is a big mess with a ton of hacks. And until we clean it up, these things will be hard to fix correctly. If it is OK with everyone, we can use this hack fix for the time being. But we *really* need to clean up the build system soon (I wish we could find some intern to do this for us).
-- Pavan
On 07/19/2009 07:56 PM, Rajeev Thakur wrote:
Async I/O needs -lrt. If I manually add -lrt it works.
Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 7:30 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls. The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority.
With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
We need this for MPICH2 to work with CUDA, which I think is a good thing to have. Even if we don't add this in 1.1.1rc1, it'll be good if we can get it into the final 1.1.1 release. It'll be great if someone can review the patch that I sent out. -- Pavan On 07/19/2009 10:56 PM, Rajeev Thakur wrote:
Yes it works now. Do we feel comfortable enough with it to include it in 1.1.1?
Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 9:45 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
Ok, this is getting messier as we go. I've attached yet another patch, but this will now duplicate -lrt as well.
The problem is that the entire build system is a big mess with a ton of hacks. And until we clean it up, these things will be hard to fix correctly. If it is OK with everyone, we can use this hack fix for the time being. But we *really* need to clean up the build system soon (I wish we could find some intern to do this for us).
-- Pavan
On 07/19/2009 07:56 PM, Rajeev Thakur wrote:
Async I/O needs -lrt. If I manually add -lrt it works.
Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 7:30 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls. The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority.
With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
This looks OK to me, although I'm not sure I see how -lrt will get duplicated. Could you add a comment explaining this shortcoming so it's easier to work on later once we've forgotten all of this discussion? -Dave On Jul 19, 2009, at 9:44 PM, Pavan Balaji wrote:
Ok, this is getting messier as we go. I've attached yet another patch, but this will now duplicate -lrt as well.
The problem is that the entire build system is a big mess with a ton of hacks. And until we clean it up, these things will be hard to fix correctly. If it is OK with everyone, we can use this hack fix for the time being. But we *really* need to clean up the build system soon (I wish we could find some intern to do this for us).
-- Pavan
On 07/19/2009 07:56 PM, Rajeev Thakur wrote:
Async I/O needs -lrt. If I manually add -lrt it works. Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected] ] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 7:30 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls. The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority.
With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji <config3.patch>
Thanks. Removed the extra comment (as per your previous email), added a note about -lrt (and -lpthread) and committed. Nothing pending from my side for the release. -- Pavan On 07/20/2009 09:34 AM, Dave Goodell wrote:
This looks OK to me, although I'm not sure I see how -lrt will get duplicated. Could you add a comment explaining this shortcoming so it's easier to work on later once we've forgotten all of this discussion?
-Dave
On Jul 19, 2009, at 9:44 PM, Pavan Balaji wrote:
Ok, this is getting messier as we go. I've attached yet another patch, but this will now duplicate -lrt as well.
The problem is that the entire build system is a big mess with a ton of hacks. And until we clean it up, these things will be hard to fix correctly. If it is OK with everyone, we can use this hack fix for the time being. But we *really* need to clean up the build system soon (I wish we could find some intern to do this for us).
-- Pavan
On 07/19/2009 07:56 PM, Rajeev Thakur wrote:
Async I/O needs -lrt. If I manually add -lrt it works. Rajeev
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pavan Balaji Sent: Sunday, July 19, 2009 7:30 PM To: [email protected] Subject: Re: [mpich2-core] mpich2-1.1.1rc1 tarball sanity checking
That set of compiles passes (although -lpthread now appears twice in the command line), but it fails further below in the f77/io tests with missing aio calls. The duplicate -lpthread problem has been there even before this patch (you should be able to see it with trunk too). While we need to fix it, it's not really a high priority.
With respect to the clock_getres errors, they belong to the -lrt library. It's quite likely that that is facing the same error as pthreads as well (though I'm surprised it didn't show up in my testing; I didn't try the I/O tests). I don't know about the AIO stuff, but it's possible some library is missing for that too.
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji <config3.patch>
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
This one also looks good (just looking at the delta between your last patch and this one). -Dave On Jul 19, 2009, at 2:23 PM, Pavan Balaji wrote:
It looks like this bug has been in MPICH2 forever. The configure checks if the C compiler requires to be linked with pthreads to compile thread programs and if it does, we add -lpthread to LDFLAGS. GCC requires it, but nvcc doesn't. But LDFLAGS are used by all compilers (CC, CXX, F77, F90). So, when the C compiler doesn't require this library but the other compilers do, things break.
Rajeev: can you try the attached patch?
-- Pavan
On 07/19/2009 11:50 AM, Pavan Balaji wrote:
A problem unrelated to the patch is that if I build with nvcc and g77, all Fortran tests in test/mpi/f77 fail to compile with the errors attached. If I use gcc, however, it works. This problem may have existed even earlier with 1.1; I didn't try to build the Fortran tests before. It may be something weird going on with nvcc. We can probably ignore it for now. Yup, this seems to have been broken in 1.1 itself. I'll take a look at it, though we shouldn't hold up 1.1.1 for it. -- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji <config2.patch>
This one looks good, although you should probably kill the comment starting on line 338 of your patch (line 8 of aclocal_subcfg.m4). -Dave On Jul 17, 2009, at 11:55 PM, Pavan Balaji wrote:
Can someone review the attached patch? I don't see a reason to maintain MPICH2_EXTRA_CFLAGS separately. A lot of autoconf and confdb macros anyway rely on having the flags set in CFLAGS. So, instead of adding these flags to MPICH2_EXTRA_CFLAGS and then adding them to CFLAGS every time we do a configure test, we should just add them to CFLAGS. I know that Anthony did this to avoid corrupting the precious variables, but autoconf/confdb seem to expect all the flags in CFLAGS and friends anyway. So, we ended up adding hacks to append these to CFLAGS each time.
FWIW, all other projects seem to be adding stuff in CFLAGS as well. Also note that we do store the user-specified CFLAGS in WRAPPER_CFLAGS, so those are not lost either. The attached patch gets rid of MPICH2_EXTRA_CFLAGS and friends; if someone sees a problem with this, please let me know.
Rajeev: can you see if this patch solves your problem?
-- Pavan
On 07/17/2009 09:58 PM, Pavan Balaji wrote:
It looks like it's caused because we add MPI_DEFAULT_COPTS (which contains "-O2") to both MPICH2_EXTRA_CFLAGS and CFLAGS on lines 1649-1654 and then we later temporarily add MPICH2_EXTRA_CFLAGS to CFLAGS for several tests. The right fix is probably to not add MPICH2_DEFAULT_COPTS (and friends) to CFLAGS. However, IIRC this is the mechanism that puts -O2 into the mpicc scripts, so we might have to add another variable to accomplish that still. We don't add -O2 to mpicc and friends. The optimization flags are only for compiling MPICH2. I'll check what's going on. -- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji <config.patch>
participants (3)
-
Dave Goodell -
Pavan Balaji -
Rajeev Thakur