Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error
I comfirmed openmpi-1.8.2rc3 with PGI-14.7 worked fine for me except for the openib issue reported by Mike Dubman. Tetsuya Mishima > Sorry, finally got through all this ompi email and see this problem was fixed. > > -Original Message- > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Pritchard Jr., Howard > Sent: Friday, August 01, 2014 8:59 AM > To: Open MPI Developers > Subject: Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error > > Hi Jeff, > > Finally got info yesterday about where the newer PGI compilers are hiding out at LANL. > I'll check this out today. > > Howard > > > -Original Message- > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres (jsquyres) > Sent: Tuesday, July 29, 2014 5:24 PM > To: Open MPI Developers List > Subject: Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error > > Tetsuya -- > > I am unable to test with the PGI compiler -- I don't have a license. I was hoping that LANL would be able to test today, but I don't think they got to it. > > Can you send more details? > > E.g., can you send the all the stuff listed on http://www.open-mpi.org/community/help/ for 1.8 and 1.8.2rc2 for the 14.7 compiler? > > I'm *guessing* that we've done something new in the changes since 1.8 that PGI doesn't support, and we need to disable that something (hopefully while not needing to disable the entire mpi_f08 > bindings...). > > > > On Jul 28, 2014, at 11:43 PM, tmish...@jcity.maeda.co.jp wrote: > > > > > Hi folks, > > > > I tried to build openmpi-1.8.2rc2 with PGI-14.7 and execute a sample > > program. Then, it causes linking error: > > > > [mishima@manage work]$ cat test.f > > program hello_world > > use mpi_f08 > > implicit none > > > > type(MPI_Comm) :: comm > > integer :: myid, npes, ierror > > integer :: name_length > > character(len=MPI_MAX_PROCESSOR_NAME) :: processor_name > > > > call mpi_init(ierror) > > comm = MPI_COMM_WORLD > > call MPI_Comm_rank(comm, myid, ierror) > > call MPI_Comm_size(comm, npes, ierror) > > call MPI_Get_processor_name(processor_name, name_length, ierror) > > write (*,'(A,X,I4,X,A,X,I4,X,A,X,A)') > > +"Process", myid, "of", npes, "is on", trim(processor_name) > > call MPI_Finalize(ierror) > > > > end program hello_world > > > > [mishima@manage work]$ mpif90 test.f -o test.ex > > /tmp/pgfortran65ZcUeoncoqT.o: In function `.C1_283': > > test.f:(.data+0x6c): undefined reference to `mpi_f08_interfaces_callbacks_' > > test.f:(.data+0x74): undefined reference to `mpi_f08_interfaces_' > > test.f:(.data+0x7c): undefined reference to `pmpi_f08_interfaces_' > > test.f:(.data+0x84): undefined reference to `mpi_f08_sizeof_' > > > > So, I did some more tests with previous version of PGI and > > openmpi-1.8. The results are summarized as follows: > > > > PGI13.10 PGI14.7 > > openmpi-1.8 OK OK > > openmpi-1.8.2rc2 configure sets use_f08_mpi:no link error > > > > Regards, > > Tetsuya Mishima > > > > ___ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2014/07/15303.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15335.php > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: http://www.open-mpi.org/community/lists/devel/2014/08/15452.php > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: http://www.open-mpi.org/community/lists/devel/2014/08/15455.php
Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error
Kewl - the openib issue has been fixed in the nightly tarball. I'm waiting for review of a couple of pending CMRs, then we'll release a quick rc4 and move to release the final version On Aug 1, 2014, at 9:55 PM, tmish...@jcity.maeda.co.jp wrote: > > > I comfirmed openmpi-1.8.2rc3 with PGI-14.7 worked fine for me > except for the openib issue reported by Mike Dubman. > > Tetsuya Mishima > >> Sorry, finally got through all this ompi email and see this problem was > fixed. >> >> -Original Message- >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Pritchard > Jr., Howard >> Sent: Friday, August 01, 2014 8:59 AM >> To: Open MPI Developers >> Subject: Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with > PGI-14.7 causes link error >> >> Hi Jeff, >> >> Finally got info yesterday about where the newer PGI compilers are hiding > out at LANL. >> I'll check this out today. >> >> Howard >> >> >> -Original Message- >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres > (jsquyres) >> Sent: Tuesday, July 29, 2014 5:24 PM >> To: Open MPI Developers List >> Subject: Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with > PGI-14.7 causes link error >> >> Tetsuya -- >> >> I am unable to test with the PGI compiler -- I don't have a license. I > was hoping that LANL would be able to test today, but I don't think they > got to it. >> >> Can you send more details? >> >> E.g., can you send the all the stuff listed on > http://www.open-mpi.org/community/help/ for 1.8 and 1.8.2rc2 for the 14.7 > compiler? >> >> I'm *guessing* that we've done something new in the changes since 1.8 > that PGI doesn't support, and we need to disable that something (hopefully > while not needing to disable the entire mpi_f08 >> bindings...). >> >> >> >> On Jul 28, 2014, at 11:43 PM, tmish...@jcity.maeda.co.jp wrote: >> >>> >>> Hi folks, >>> >>> I tried to build openmpi-1.8.2rc2 with PGI-14.7 and execute a sample >>> program. Then, it causes linking error: >>> >>> [mishima@manage work]$ cat test.f >>> program hello_world >>> use mpi_f08 >>> implicit none >>> >>> type(MPI_Comm) :: comm >>> integer :: myid, npes, ierror >>> integer :: name_length >>> character(len=MPI_MAX_PROCESSOR_NAME) :: processor_name >>> >>> call mpi_init(ierror) >>> comm = MPI_COMM_WORLD >>> call MPI_Comm_rank(comm, myid, ierror) >>> call MPI_Comm_size(comm, npes, ierror) >>> call MPI_Get_processor_name(processor_name, name_length, ierror) >>> write (*,'(A,X,I4,X,A,X,I4,X,A,X,A)') >>>+"Process", myid, "of", npes, "is on", trim(processor_name) >>> call MPI_Finalize(ierror) >>> >>> end program hello_world >>> >>> [mishima@manage work]$ mpif90 test.f -o test.ex >>> /tmp/pgfortran65ZcUeoncoqT.o: In function `.C1_283': >>> test.f:(.data+0x6c): undefined reference to > `mpi_f08_interfaces_callbacks_' >>> test.f:(.data+0x74): undefined reference to `mpi_f08_interfaces_' >>> test.f:(.data+0x7c): undefined reference to `pmpi_f08_interfaces_' >>> test.f:(.data+0x84): undefined reference to `mpi_f08_sizeof_' >>> >>> So, I did some more tests with previous version of PGI and >>> openmpi-1.8. The results are summarized as follows: >>> >>> PGI13.10 PGI14.7 >>> openmpi-1.8 OK OK >>> openmpi-1.8.2rc2 configure sets use_f08_mpi:no link error >>> >>> Regards, >>> Tetsuya Mishima >>> >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2014/07/15303.php >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15335.php >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15452.php >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15455.php > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15468.php
Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error
Hi Ralph, I comfirmed that the openib issue was really fixed by r32395 and hope you'll be able to release the final version soon. Tetsuya > Kewl - the openib issue has been fixed in the nightly tarball. I'm waiting for review of a couple of pending CMRs, then we'll release a quick rc4 and move to release the final version > > > On Aug 1, 2014, at 9:55 PM, tmish...@jcity.maeda.co.jp wrote: > > > > > > > I comfirmed openmpi-1.8.2rc3 with PGI-14.7 worked fine for me > > except for the openib issue reported by Mike Dubman. > > > > Tetsuya Mishima > > > >> Sorry, finally got through all this ompi email and see this problem was > > fixed. > >> > >> -Original Message- > >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Pritchard > > Jr., Howard > >> Sent: Friday, August 01, 2014 8:59 AM > >> To: Open MPI Developers > >> Subject: Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with > > PGI-14.7 causes link error > >> > >> Hi Jeff, > >> > >> Finally got info yesterday about where the newer PGI compilers are hiding > > out at LANL. > >> I'll check this out today. > >> > >> Howard > >> > >> > >> -Original Message- > >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres > > (jsquyres) > >> Sent: Tuesday, July 29, 2014 5:24 PM > >> To: Open MPI Developers List > >> Subject: Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with > > PGI-14.7 causes link error > >> > >> Tetsuya -- > >> > >> I am unable to test with the PGI compiler -- I don't have a license. I > > was hoping that LANL would be able to test today, but I don't think they > > got to it. > >> > >> Can you send more details? > >> > >> E.g., can you send the all the stuff listed on > > http://www.open-mpi.org/community/help/ for 1.8 and 1.8.2rc2 for the 14.7 > > compiler? > >> > >> I'm *guessing* that we've done something new in the changes since 1.8 > > that PGI doesn't support, and we need to disable that something (hopefully > > while not needing to disable the entire mpi_f08 > >> bindings...). > >> > >> > >> > >> On Jul 28, 2014, at 11:43 PM, tmish...@jcity.maeda.co.jp wrote: > >> > >>> > >>> Hi folks, > >>> > >>> I tried to build openmpi-1.8.2rc2 with PGI-14.7 and execute a sample > >>> program. Then, it causes linking error: > >>> > >>> [mishima@manage work]$ cat test.f > >>> program hello_world > >>> use mpi_f08 > >>> implicit none > >>> > >>> type(MPI_Comm) :: comm > >>> integer :: myid, npes, ierror > >>> integer :: name_length > >>> character(len=MPI_MAX_PROCESSOR_NAME) :: processor_name > >>> > >>> call mpi_init(ierror) > >>> comm = MPI_COMM_WORLD > >>> call MPI_Comm_rank(comm, myid, ierror) > >>> call MPI_Comm_size(comm, npes, ierror) > >>> call MPI_Get_processor_name(processor_name, name_length, ierror) > >>> write (*,'(A,X,I4,X,A,X,I4,X,A,X,A)') > >>>+"Process", myid, "of", npes, "is on", trim(processor_name) > >>> call MPI_Finalize(ierror) > >>> > >>> end program hello_world > >>> > >>> [mishima@manage work]$ mpif90 test.f -o test.ex > >>> /tmp/pgfortran65ZcUeoncoqT.o: In function `.C1_283': > >>> test.f:(.data+0x6c): undefined reference to > > `mpi_f08_interfaces_callbacks_' > >>> test.f:(.data+0x74): undefined reference to `mpi_f08_interfaces_' > >>> test.f:(.data+0x7c): undefined reference to `pmpi_f08_interfaces_' > >>> test.f:(.data+0x84): undefined reference to `mpi_f08_sizeof_' > >>> > >>> So, I did some more tests with previous version of PGI and > >>> openmpi-1.8. The results are summarized as follows: > >>> > >>> PGI13.10 PGI14.7 > >>> openmpi-1.8 OK OK > >>> openmpi-1.8.2rc2 configure sets use_f08_mpi:no link error > >>> > >>> Regards, > >>> Tetsuya Mishima > >>> > >>> ___ > >>> devel mailing list > >>> de...@open-mpi.org > >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> Link to this post: > >>> http://www.open-mpi.org/community/lists/devel/2014/07/15303.php > >> > >> > >> -- > >> Jeff Squyres > >> jsquy...@cisco.com > >> For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> ___ > >> devel mailing list > >> de...@open-mpi.org > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >> Link to this post: > > http://www.open-mpi.org/community/lists/devel/2014/07/15335.php > >> ___ > >> devel mailing list > >> de...@open-mpi.org > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >> Link to this post: > > http://www.open-mpi.org/community/lists/devel/2014/08/15452.php > >> ___ > >> devel mailing list > >> de...@open-mpi.org > >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > >> Link to this post: > > http://www.open-mpi
Re: [OMPI devel] Trunk broken for PPC64?
Good suggestion, Paul - I have committed it in r32407 and added it to cmr #4826 Thanks! Ralph On Aug 1, 2014, at 1:12 AM, Paul Hargrove wrote: > Gilles, > > At the moment ompi/mca/osc/sm/osc_sm_component.c is using the following: > > #ifdef HAVE_GETPAGESIZE > pagesize = getpagesize(); > #else > pagesize = 4096; > #endif > > While other places in the code use sysconf(), but not always consistently. > > And on some systems _SC_PAGESIZE is spelled as _SC_PAGE_SIZE. > Fortunately configure already checks these variations for you. > > So, I suggest > > #ifdef HAVE_GETPAGESIZE > pagesize = getpagesize(); > #elif defined(_SC_PAGESIZE ) > pagesize = sysconf(_SC_PAGESIZE); > #elif defined(_SC_PAGE_SIZE) > pagesize = sysconf(_SC_PAGE_SIZE); > #else > pagesize = 65536; /* safer to overestimate than under */ > #endif > > > opal_pagesize() anyone? > > -Paul > > On Fri, Aug 1, 2014 at 12:50 AM, Gilles Gouaillardet > wrote: > Paul, > > you are absolutly right ! > > in ompi/mca/coll/ml/coll_ml_lmngr.c at line 53, > cm->lmngr_alignment is hard coded to 4096 > > as a proof of concept, i hard coded it to 65536 and now coll/ml works just > fine > > i will now write a patch that uses sysconf(_SC_PAGESIZE) instead > > Cheers, > > Gilles > > On 2014/08/01 15:56, Paul Hargrove wrote: >> Hmm, maybe this has nothing to do with big-endian. >> Below is a backtrace from ring_c on an IA64 platform (definitely >> little-endian) that looks very similar to me. >> >> It happens that sysconf(_SC_PAGESIZE) returns 64K on both of these systems. >> So, I wonder if that might be related. >> >> -Paul >> >> $ mpirun -mca btl sm,self -np 2 examples/ring_c' >> [altix][[26769,1],0][/eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/openmpi-1.9a1r32386/ompi/mca/coll/ml/coll_ml_lmngr.c:231:mca_coll_ml_lmngr_init] >> COLL-ML [altix:20418] *** Process received signal *** >> [altix:20418] Signal: Segmentation fault (11) >> [altix:20418] Signal code: Invalid permissions (2) >> [altix:20418] Failing at address: 0x16 >> [altix][[26769,1],1][/eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/openmpi-1.9a1r32386/ompi/mca/coll/ml/coll_ml_lmngr.c:231:mca_coll_ml_lmngr_init] >> COLL-ML [altix:20419] *** Process received signal *** >> [altix:20419] Signal: Segmentation fault (11) >> [altix:20419] Signal code: Invalid permissions (2) >> [altix:20419] Failing at address: 0x16 >> [altix:20418] [ 0] [0xa0010800] >> [altix:20418] [ 1] /lib/libc.so.6.1(strlen-0x92e930)[0x2051b2a0] >> [altix:20418] [altix:20419] [ 0] [0xa0010800] >> [altix:20419] [ 1] [ 2] >> /lib/libc.so.6.1(strlen-0x92e930)[0x2051b2a0] >> [altix:20419] [ 2] >> /lib/libc.so.6.1(_IO_vfprintf-0x998610)[0x204b15d0] >> [altix:20419] [ 3] /lib/libc.so.6.1(+0x82860)[0x204b2860] >> [altix:20419] [ 4] >> /lib/libc.so.6.1(_IO_vfprintf-0x99f140)[0x2040] >> [altix:20419] [ 5] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(+0xc5a70)[0x21e55a70] >> [altix:20419] [ 6] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(+0xc84a0)[0x21e584a0] >> [altix:20419] [ 7] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(mca_coll_ml_lmngr_alloc+0x100f520)[0x21e59110] >> [altix:20419] [ 8] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(mca_coll_ml_allocate_block+0xf6e940)[0x21db8540] >> [altix:20419] [ 9] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(+0x10130)[0x21da0130] >> [altix:20419] [10] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(+0x19970)[0x21da9970] >> [altix:20419] [11] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/openmpi/mca_coll_ml.so(mca_coll_ml_comm_query+0xf6d6b0)[0x21db5830] >> [altix:20419] [12] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(+0x22fbd0)[0x2028fbd0] >> [altix:20419] [13] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(+0x22fac0)[0x2028fac0] >> [altix:20419] [14] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(+0x22f7e0)[0x2028f7e0] >> [altix:20419] [15] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(+0x22eac0)[0x2028eac0] >> [altix:20419] [16] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(mca_coll_base_comm_select-0xbcbb90)[0x2027e080] >> [altix:20419] [17] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(ompi_mpi_init-0xd38e70)[0x20110db0] >> [altix:20419] [18] >> /eng/home/PHHargrove/OMPI/openmpi-trunk-linux-ia64/INST/lib/libmpi.so.0(MPI_Init-0xc8bf40)[0x201bdcf0] >> [altix:20419] [19] examples/ring_c[0x4c00] >> [altix:20419] [20] >>
Re: [OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)
This was apparently somewhat recent - here is the OpenBSD ticket regarding it: http://sourceforge.net/p/levent/bugs/320/ If someone feels it important that we continue supporting OpenBSD, one might explore the solution recommended in that ticket. It's also possible that the libevent guys are working on solving it too (or may have already done so in a later version than we include) On Aug 1, 2014, at 4:07 PM, Paul Hargrove wrote: > I am seeing the following on OpenBSD/amd64 with "make V=1": > > Making all in tools/wrappers > /bin/sh ../../../libtool --tag=CC--mode=link gcc -std=gnu99 -g > -finline-functions -fno-strict-aliasing -pthread -export-dynamic -o > opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lutil -lm > libtool: link: gcc -std=gnu99 -g -finline-functions -fno-strict-aliasing > -pthread -o .libs/opal_wrapper opal_wrapper.o -Wl,-E -L../../../opal/.libs > -lopen-pal -lpthread -lutil -lm -pthread > -Wl,-rpath,/home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/INST/lib > ../../../opal/.libs/libopen-pal.so.8.0: warning: vsprintf() is often misused, > please use vsnprintf() > ../../../opal/.libs/libopen-pal.so.8.0: warning: strcpy() is almost always > misused, please use strlcpy() > ../../../opal/.libs/libopen-pal.so.8.0: warning: random() isn't random; > consider using arc4random() > ../../../opal/.libs/libopen-pal.so.8.0: warning: strcat() is almost always > misused, please use strlcat() > ../../../opal/.libs/libopen-pal.so.8.0: warning: sprintf() is often misused, > please use snprintf() > ../../../opal/.libs/libopen-pal.so.8.0: undefined reference to > `arc4random_addrandom' > collect2: ld returned 1 exit status > *** Error 1 in opal/tools/wrappers (Makefile:1623 'opal_wrapper') > *** Error 1 in opal (Makefile:2145 'all-recursive') > *** Error 1 in /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/BLD > (Makefile:1689 'all-recursive') > > Ignoring OpenBSD's typical warnings about functions their developers don't > like there is an undefined reference to arc4random_addrandom. The only > explicit reference appears to be in libevent: > > $ grep -rlw arc4random_addrandom . > ./opal/mca/event/libevent2021/libevent/evutil_rand.c > ./opal/mca/event/libevent2021/libevent/arc4random.c > > It appears that OpenBSD has arc4random, but no arc4random_addrandom(): > /usr/include/stdlib.h:u_int32_t arc4random(void); > /usr/include/stdlib.h:u_int32_t arc4random_uniform(u_int32_t); > /usr/include/stdlib.h:void arc4random_buf(void *, size_t) > > I tried to work-around this by adding "ac_cv_func_arc4random=no" to the > configure command line, but that creates secondary problems because the #if > logic in libevent doesn't allow for the case that arc4random() does not exist > but arc4random_buf() does: > > In file included from > /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/openmpi-1.8.2rc3/opal/mca/event/libev > ent2021/libevent/evutil_rand.c:119: > /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/openmpi-1.8.2rc3/opal/mca/event/libevent2021/libevent/./arc > 4random.c:482: error: static declaration of 'arc4random_buf' follows > non-static declaration > /usr/include/stdlib.h:308: error: previous declaration of 'arc4random_buf' > was here > > Use of --with-libevent=... was no use because the pre-built libevent package > for OpenBSD lacks thread support. > > So, I am left without any recipe to build 1.8.2rc3 on OpenBSD. > HOWEVER, is appears that 1.8, 1.8.1 and trunk all have the same problem. > Of course, I am the only one who tests Open MPI on OpenBSD, and I don't > actually USE it. > So, this is not any sort of a priority as far as I am concerned. > > -Paul > > > > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15466.php
Re: [OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)
Ralph, My position on support for OpenBSD is the same as the numerous other operating systems, cpu architectures and compilers I help test on. I feel that every additional platform for which one can maintain support improves the chance of catching bugs in ones code and reduces the effort to port to new platforms in the future, making portability a goal rather than just a means to ones ends. Therefore, I believe that resolving portability issues is deserving of effort that may seem out of proportion to the number of potential users of a given port. Keep in mind that when I have time I aggressively test to help ensure the wide portability of Open MPI despite the fact that I have never written an MPI application outside of course work (over ten years ago). I am not an MPI developer or user - I am an advocate for portable HPC middleware. Unless somebody beat me to it, I will create a ticket for this issue assigning it to myself. If/when I have the time I will try libevent patches to resolve the problem. Regarding the possibility that this is fixed in a later libevent than is packaged with Open MPI, I had a look at the OpenBSD ports tree. They have libevent-2.0.21-stable and still apply patches to remove the use of arc4random_addrandom(). I believe that is the same version packages with Open MPI and so their patches will be the starting point for trying to fix libevent in Open MPI. Now having said all of that, I find that the OpenBSD ports tree and repository of binary packages still contain Open MPI 1.4.1 (and nothing newer) and no version of mpich at all (and thankfully no LAM/MPI). This suggests that either a) there is no demand at all for MPI on OpenBSD b) there are users working building from sources So, there is absolutely no reason to believe there is any time sensitivity for resolution of this issue. Only I am likely to ever notice the lack of OpenBSD support. -Paul On Sat, Aug 2, 2014 at 11:46 AM, Ralph Castain wrote: > This was apparently somewhat recent - here is the OpenBSD ticket regarding > it: > > http://sourceforge.net/p/levent/bugs/320/ > > If someone feels it important that we continue supporting OpenBSD, one > might explore the solution recommended in that ticket. It's also possible > that the libevent guys are working on solving it too (or may have already > done so in a later version than we include) > > > On Aug 1, 2014, at 4:07 PM, Paul Hargrove wrote: > > I am seeing the following on OpenBSD/amd64 with "make V=1": > > Making all in tools/wrappers > /bin/sh ../../../libtool --tag=CC--mode=link gcc -std=gnu99 -g > -finline-functions -fno-strict-aliasing -pthread -export-dynamic -o > opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lutil -lm > libtool: link: gcc -std=gnu99 -g -finline-functions -fno-strict-aliasing > -pthread -o .libs/opal_wrapper opal_wrapper.o -Wl,-E -L../../../opal/.libs > -lopen-pal -lpthread -lutil -lm -pthread > -Wl,-rpath,/home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/INST/lib > ../../../opal/.libs/libopen-pal.so.8.0: warning: vsprintf() is often > misused, please use vsnprintf() > ../../../opal/.libs/libopen-pal.so.8.0: warning: strcpy() is almost always > misused, please use strlcpy() > ../../../opal/.libs/libopen-pal.so.8.0: warning: random() isn't random; > consider using arc4random() > ../../../opal/.libs/libopen-pal.so.8.0: warning: strcat() is almost always > misused, please use strlcat() > ../../../opal/.libs/libopen-pal.so.8.0: warning: sprintf() is often > misused, please use snprintf() > ../../../opal/.libs/libopen-pal.so.8.0: undefined reference to > `arc4random_addrandom' > collect2: ld returned 1 exit status > *** Error 1 in opal/tools/wrappers (Makefile:1623 'opal_wrapper') > *** Error 1 in opal (Makefile:2145 'all-recursive') > *** Error 1 in /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/BLD > (Makefile:1689 'all-recursive') > > Ignoring OpenBSD's typical warnings about functions their developers don't > like there is an undefined reference to arc4random_addrandom. The only > explicit reference appears to be in libevent: > > $ grep -rlw arc4random_addrandom . > ./opal/mca/event/libevent2021/libevent/evutil_rand.c > ./opal/mca/event/libevent2021/libevent/arc4random.c > > It appears that OpenBSD has arc4random, but no arc4random_addrandom(): > /usr/include/stdlib.h:u_int32_t arc4random(void); > /usr/include/stdlib.h:u_int32_t arc4random_uniform(u_int32_t); > /usr/include/stdlib.h:void arc4random_buf(void *, size_t) > > I tried to work-around this by adding "ac_cv_func_arc4random=no" to the > configure command line, but that creates secondary problems because the #if > logic in libevent doesn't allow for the case that arc4random() does not > exist but arc4random_buf() does: > > In file included from > /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/openmpi-1.8.2rc3/opal/mca/event/libev > ent2021/libevent/evutil_rand.c:119: > > /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/openmpi-1.8.2rc3/opal
[OMPI devel] Trak missing Versions for 1.8.x
I was just in Trak to open a new ticket and noticed that the Version pull-down lacks entries for 1.8 and 1.8.1. -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Re: [OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)
To be clear, I fully support what you say. Ordinarily, I would just do the port, but sadly (a) I am totally buried at work right now, and (b) I have no way to verify that the patches actually work. If/when you have time, do let me know the results and I'll be happy to proceed. Thanks Ralph On Aug 2, 2014, at 12:49 PM, Paul Hargrove wrote: > Ralph, > > My position on support for OpenBSD is the same as the numerous other > operating systems, cpu architectures and compilers I help test on. I feel > that every additional platform for which one can maintain support improves > the chance of catching bugs in ones code and reduces the effort to port to > new platforms in the future, making portability a goal rather than just a > means to ones ends. > > Therefore, I believe that resolving portability issues is deserving of effort > that may seem out of proportion to the number of potential users of a given > port. Keep in mind that when I have time I aggressively test to help ensure > the wide portability of Open MPI despite the fact that I have never written > an MPI application outside of course work (over ten years ago). I am not an > MPI developer or user - I am an advocate for portable HPC middleware. > > Unless somebody beat me to it, I will create a ticket for this issue > assigning it to myself. > If/when I have the time I will try libevent patches to resolve the problem. > > Regarding the possibility that this is fixed in a later libevent than is > packaged with Open MPI, I had a look at the OpenBSD ports tree. They have > libevent-2.0.21-stable and still apply patches to remove the use of > arc4random_addrandom(). I believe that is the same version packages with > Open MPI and so their patches will be the starting point for trying to fix > libevent in Open MPI. > > Now having said all of that, I find that the OpenBSD ports tree and > repository of binary packages still contain Open MPI 1.4.1 (and nothing > newer) and no version of mpich at all (and thankfully no LAM/MPI). This > suggests that either > a) there is no demand at all for MPI on OpenBSD > b) there are users working building from sources > > So, there is absolutely no reason to believe there is any time sensitivity > for resolution of this issue. Only I am likely to ever notice the lack of > OpenBSD support. > > -Paul > > > On Sat, Aug 2, 2014 at 11:46 AM, Ralph Castain wrote: > This was apparently somewhat recent - here is the OpenBSD ticket regarding it: > > http://sourceforge.net/p/levent/bugs/320/ > > If someone feels it important that we continue supporting OpenBSD, one might > explore the solution recommended in that ticket. It's also possible that the > libevent guys are working on solving it too (or may have already done so in a > later version than we include) > > > On Aug 1, 2014, at 4:07 PM, Paul Hargrove wrote: > >> I am seeing the following on OpenBSD/amd64 with "make V=1": >> >> Making all in tools/wrappers >> /bin/sh ../../../libtool --tag=CC--mode=link gcc -std=gnu99 -g >> -finline-functions -fno-strict-aliasing -pthread -export-dynamic -o >> opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lutil -lm >> libtool: link: gcc -std=gnu99 -g -finline-functions -fno-strict-aliasing >> -pthread -o .libs/opal_wrapper opal_wrapper.o -Wl,-E -L../../../opal/.libs >> -lopen-pal -lpthread -lutil -lm -pthread >> -Wl,-rpath,/home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/INST/lib >> ../../../opal/.libs/libopen-pal.so.8.0: warning: vsprintf() is often >> misused, please use vsnprintf() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: strcpy() is almost always >> misused, please use strlcpy() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: random() isn't random; >> consider using arc4random() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: strcat() is almost always >> misused, please use strlcat() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: sprintf() is often misused, >> please use snprintf() >> ../../../opal/.libs/libopen-pal.so.8.0: undefined reference to >> `arc4random_addrandom' >> collect2: ld returned 1 exit status >> *** Error 1 in opal/tools/wrappers (Makefile:1623 'opal_wrapper') >> *** Error 1 in opal (Makefile:2145 'all-recursive') >> *** Error 1 in /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/BLD >> (Makefile:1689 'all-recursive') >> >> Ignoring OpenBSD's typical warnings about functions their developers don't >> like there is an undefined reference to arc4random_addrandom. The only >> explicit reference appears to be in libevent: >> >> $ grep -rlw arc4random_addrandom . >> ./opal/mca/event/libevent2021/libevent/evutil_rand.c >> ./opal/mca/event/libevent2021/libevent/arc4random.c >> >> It appears that OpenBSD has arc4random, but no arc4random_addrandom(): >> /usr/include/stdlib.h:u_int32_t arc4random(void); >> /usr/include/stdlib.h:u_int32_t arc4random_uniform(u_int32_t); >> /usr/include/stdlib.h:void arc4random
Re: [OMPI devel] Trak missing Versions for 1.8.x
Yeah, we remove back entries as we aren't going to backport patches to old releases. On Aug 2, 2014, at 12:59 PM, Paul Hargrove wrote: > I was just in Trak to open a new ticket and noticed that the Version > pull-down lacks entries for 1.8 and 1.8.1. > > -Paul > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15474.php
Re: [OMPI devel] [1.8.2rc3] build failure on OpenBSD (libevent)
Ralph, I understand that I am likely the only one in a position to test. I have already completed initial testing of the approach in the bug report you fount at sourceforge: excise the sole *unused* routine that calls arc4random_addrandom(). Assuming the remainder of my testing is successful, I will soon attach a patch to the trac issue (#4829). It is up to you and the other core developers to decide whether to CMR for inclusion 1.8.2, 1.8.3 or leave for 1.9. I will not push to delay 1.8.2 for OpenBSD support. -Paul On Sat, Aug 2, 2014 at 2:10 PM, Ralph Castain wrote: > To be clear, I fully support what you say. Ordinarily, I would just do the > port, but sadly (a) I am totally buried at work right now, and (b) I have > no way to verify that the patches actually work. > > If/when you have time, do let me know the results and I'll be happy to > proceed. > > Thanks > Ralph > > > On Aug 2, 2014, at 12:49 PM, Paul Hargrove wrote: > > Ralph, > > My position on support for OpenBSD is the same as the numerous other > operating systems, cpu architectures and compilers I help test on. I feel > that every additional platform for which one can maintain support improves > the chance of catching bugs in ones code and reduces the effort to port to > new platforms in the future, making portability a goal rather than just a > means to ones ends. > > Therefore, I believe that resolving portability issues is deserving of > effort that may seem out of proportion to the number of potential users of > a given port. Keep in mind that when I have time I aggressively test to > help ensure the wide portability of Open MPI despite the fact that I have > never written an MPI application outside of course work (over ten years > ago). I am not an MPI developer or user - I am an advocate for portable > HPC middleware. > > Unless somebody beat me to it, I will create a ticket for this issue > assigning it to myself. > If/when I have the time I will try libevent patches to resolve the problem. > > Regarding the possibility that this is fixed in a later libevent than is > packaged with Open MPI, I had a look at the OpenBSD ports tree. They have > libevent-2.0.21-stable and still apply patches to remove the use of > arc4random_addrandom(). I believe that is the same version packages with > Open MPI and so their patches will be the starting point for trying to fix > libevent in Open MPI. > > Now having said all of that, I find that the OpenBSD ports tree and > repository of binary packages still contain Open MPI 1.4.1 (and nothing > newer) and no version of mpich at all (and thankfully no LAM/MPI). This > suggests that either > a) there is no demand at all for MPI on OpenBSD > b) there are users working building from sources > > So, there is absolutely no reason to believe there is any time sensitivity > for resolution of this issue. Only I am likely to ever notice the lack of > OpenBSD support. > > -Paul > > > On Sat, Aug 2, 2014 at 11:46 AM, Ralph Castain wrote: > >> This was apparently somewhat recent - here is the OpenBSD ticket >> regarding it: >> >> http://sourceforge.net/p/levent/bugs/320/ >> >> If someone feels it important that we continue supporting OpenBSD, one >> might explore the solution recommended in that ticket. It's also possible >> that the libevent guys are working on solving it too (or may have already >> done so in a later version than we include) >> >> >> On Aug 1, 2014, at 4:07 PM, Paul Hargrove wrote: >> >> I am seeing the following on OpenBSD/amd64 with "make V=1": >> >> Making all in tools/wrappers >> /bin/sh ../../../libtool --tag=CC--mode=link gcc -std=gnu99 -g >> -finline-functions -fno-strict-aliasing -pthread -export-dynamic -o >> opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lutil -lm >> libtool: link: gcc -std=gnu99 -g -finline-functions -fno-strict-aliasing >> -pthread -o .libs/opal_wrapper opal_wrapper.o -Wl,-E -L../../../opal/.libs >> -lopen-pal -lpthread -lutil -lm -pthread >> -Wl,-rpath,/home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/INST/lib >> ../../../opal/.libs/libopen-pal.so.8.0: warning: vsprintf() is often >> misused, please use vsnprintf() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: strcpy() is almost >> always misused, please use strlcpy() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: random() isn't random; >> consider using arc4random() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: strcat() is almost >> always misused, please use strlcat() >> ../../../opal/.libs/libopen-pal.so.8.0: warning: sprintf() is often >> misused, please use snprintf() >> ../../../opal/.libs/libopen-pal.so.8.0: undefined reference to >> `arc4random_addrandom' >> collect2: ld returned 1 exit status >> *** Error 1 in opal/tools/wrappers (Makefile:1623 'opal_wrapper') >> *** Error 1 in opal (Makefile:2145 'all-recursive') >> *** Error 1 in /home/phargrov/OMPI/openmpi-1.8.2rc3-openbsd5-amd64/BLD >> (Makefile:1689 'all-recursive') >> >> Ignoring OpenBSD's ty
Re: [OMPI devel] Trak missing Versions for 1.8.x
Not sure I understood that reply. I see Version going back to 1.0, but none for the *current* release series. Is that really the intent? -Paul On Sat, Aug 2, 2014 at 2:11 PM, Ralph Castain wrote: > Yeah, we remove back entries as we aren't going to backport patches to old > releases. > > On Aug 2, 2014, at 12:59 PM, Paul Hargrove wrote: > > I was just in Trak to open a new ticket and noticed that the Version > pull-down lacks entries for 1.8 and 1.8.1. > > -Paul > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15474.php > > > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15476.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Re: [OMPI devel] Trak missing Versions for 1.8.x
Hmmm...I'll check with Jeff next week. I'm not sure why we would support creation of tickets for releases that we know we'll never fix On Aug 2, 2014, at 2:26 PM, Paul Hargrove wrote: > Not sure I understood that reply. > > I see Version going back to 1.0, but none for the *current* release series. > Is that really the intent? > > -Paul > > > On Sat, Aug 2, 2014 at 2:11 PM, Ralph Castain wrote: > Yeah, we remove back entries as we aren't going to backport patches to old > releases. > > On Aug 2, 2014, at 12:59 PM, Paul Hargrove wrote: > >> I was just in Trak to open a new ticket and noticed that the Version >> pull-down lacks entries for 1.8 and 1.8.1. >> >> -Paul >> >> -- >> Paul H. Hargrove phhargr...@lbl.gov >> Future Technologies Group >> Computer and Data Sciences Department Tel: +1-510-495-2352 >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/08/15474.php > > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15476.php > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15478.php
Re: [OMPI devel] Trak missing Versions for 1.8.x
I'm more concerned with the INABILITY to file bug reports against the current release. One can pick "1.8 branch" but not 1.8 or 1.8.1. -Paul On Sat, Aug 2, 2014 at 2:33 PM, Ralph Castain wrote: > Hmmm...I'll check with Jeff next week. I'm not sure why we would support > creation of tickets for releases that we know we'll never fix > > > On Aug 2, 2014, at 2:26 PM, Paul Hargrove wrote: > > Not sure I understood that reply. > > I see Version going back to 1.0, but none for the *current* release series. > Is that really the intent? > > -Paul > > > On Sat, Aug 2, 2014 at 2:11 PM, Ralph Castain wrote: > >> Yeah, we remove back entries as we aren't going to backport patches to >> old releases. >> >> On Aug 2, 2014, at 12:59 PM, Paul Hargrove wrote: >> >> I was just in Trak to open a new ticket and noticed that the Version >> pull-down lacks entries for 1.8 and 1.8.1. >> >> -Paul >> >> -- >> Paul H. Hargrove phhargr...@lbl.gov >> Future Technologies Group >> Computer and Data Sciences Department Tel: +1-510-495-2352 >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/08/15474.php >> >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/08/15476.php >> > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15478.php > > > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/08/15479.php > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
[OMPI devel] trunk warnings on x86
Looks like on a 32-bit platform a (uintptr_t) cast is desired in the OMPI_CAST_RTE_NAME() macro. Warnings from current trunk tarball attributable to the missing case include: /home/pcp1/phargrov/OMPI/openmpi-trunk-linux-x86-gcc/openmpi-1.9a1r32406/ompi/runtime/ompi_mpi_abort.c:89: warning: cast to pointer from integer of different size /home/pcp1/phargrov/OMPI/openmpi-trunk-linux-x86-gcc/openmpi-1.9a1r32406/ompi/runtime/ompi_mpi_abort.c:97: warning: cast to pointer from integer of different size /home/pcp1/phargrov/OMPI/openmpi-trunk-linux-x86-gcc/openmpi-1.9a1r32406/ompi/mca/pml/bfo/pml_bfo_failover.c:1417: warning: cast to pointer from integer of different size -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
