[OMPI devel] Prep for 1.2.4 release
All organizations should review the README file (particularly the list of supported systems, etc.) to ensure that it is good-to-go and accurate for the 1.2.4. release. Tim posted 1.2.4rc1 yesterday: http://www.open-mpi.org/software/ompi/v1.2/ -- Jeff Squyres Cisco Systems
Re: [OMPI devel] Prep for 1.2.4 release
Jeff Squyres wrote: All organizations should review the README file (particularly the list of supported systems, etc.) to ensure that it is good-to-go and accurate for the 1.2.4. release. Tim posted 1.2.4rc1 yesterday: http://www.open-mpi.org/software/ompi/v1.2/ I would like to request a hold on the 1.2.4 release until 5pm ET today or until sooner notice. Reason being that we might have found our descrepancy of overhead latency with the message queue fix. If we can confirm are suspicions before 5pm tonight I will then request that we do an rc2 with the message queue fixes included. If anyone has an issue with this trajectory please speak now. --td
Re: [OMPI devel] Prep for 1.2.4 release
No issues from Cisco. If an optimized build was not used, that could well account for the discrepancy. On Sep 19, 2007, at 9:18 AM, Terry Dontje wrote: Jeff Squyres wrote: All organizations should review the README file (particularly the list of supported systems, etc.) to ensure that it is good-to-go and accurate for the 1.2.4. release. Tim posted 1.2.4rc1 yesterday: http://www.open-mpi.org/software/ompi/v1.2/ I would like to request a hold on the 1.2.4 release until 5pm ET today or until sooner notice. Reason being that we might have found our descrepancy of overhead latency with the message queue fix. If we can confirm are suspicions before 5pm tonight I will then request that we do an rc2 with the message queue fixes included. If anyone has an issue with this trajectory please speak now. --td ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
[OMPI devel] osu_bibw failing for message sizes 2097152 and larger
In doing some runs with the osu_bibw test on a single node, we have found that it hands when using the trunk for message sizes 2097152 or larger unless the mpool_sm_min_size is set to a number larger than the message size. We are not seeing this issue in the 1.2 branch. Just checking to see if I am missed something or if I should be filing a defect to trac this issue. Thanks, Dan
Re: [OMPI devel] osu_bibw failing for message sizes 2097152 and larger
On Wed, Sep 19, 2007 at 10:26:15AM -0400, Dan Lacher wrote: > In doing some runs with the osu_bibw test on a single node, we have > found that it hands when using the trunk for message sizes 2097152 or > larger unless the mpool_sm_min_size is set to a number larger than the > message size. We are not seeing this issue in the 1.2 branch. Just > checking to see if I am missed something or if I should be filing a > defect to trac this issue. > I can't reproduce this. "mpirun -np 2 ./osu_bibw" works for me. -- Gleb.
[OMPI devel] Message Queue debugging support for1.2.4
Hi, Just to verify, before I'll start testing this, there will be no message queue debugging support in this version, correct? This all goes to 1.3 release. Best Regards, P.S. It looks like it is time for us to be more formally involved in this work. Nikolay Piskun Director of Continuing Engineering, TotalView Technologies 24 Prime Parkway, Natick, MA 01760 http://www.totalviewtech.com
[OMPI devel] FreeBSD Support?
Hi. I have been trying to build the latest ompi-trunk (as of yesterday) svn snapshot (r16158) of OpenMPI on a FreeBSD 6.2 machine and have run into 3 build problems. I was curious if anyone else has encountered these errors and if they are being addressed. Problem 1 - When running the autogen.sh script as non-root, I see the following error: * *** Running GNU tools [Running] autom4te --language=m4sh ompi_get_version.m4sh -o ompi_get_version.sh [Running] aclocal /usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB /usr/local/share/aclocal/glib.m4:8: run info '(automake)Extending aclocal' /usr/local/share/aclocal/glib.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal [Running] autoheader ** Adjusting libtool for OMPI :-( ++ patching for pathscale multi-line output (LT 1.5.x) [Running] autoconf [Running] libtoolize --automake --copy --ltdl -- Moving libltdl to opal/ ** Updating Automake version in libltdl package [Running] aclocal acinclude.m4:6405: the serial number must appear before any macro definition /usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB /usr/local/share/aclocal/glib.m4:8: run info '(automake)Extending aclocal' /usr/local/share/aclocal/glib.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal [Running] automake [Running] autoconf autom4te-2.61: cannot open configure: Permission denied - It seems that the execution of "autoconf" has failed. See above for the specific error message that caused it to abort. - * After some searching, it would appear that this is an autoconf issue that crops up in FreeBSD but, for whatever reason, not in Linux. A quick workaround is to add: `chmod -vr u+w *` just before autogen issues the `run_and_check $ompi_autoconf` command on line 438. Problem 2: -- After correcting the autogen.sh script, running it and then running configure with --prefix=some_directory as a parameter, it was time to `make all install.` Following is console output: gcc -DHAVE_CONFIG_H -I. -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../.. -g -Wall -Wundef -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic -Werror-implicit-function-declaration -finline-functions -fno-strict-aliasing -pthread -MT opal_pty.lo -MD -MP -MF .deps/opal_pty.Tpo -c opal_pty.c -fPIC -DPIC -o .libs/opal_pty.o opal_pty.c: In function `opal_openpty': opal_pty.c:127: error: implicit declaration of function `openpty' *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/opal/util. *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/opal/util. *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/opal. *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk. *** It would seem that openpty needs to have libutil.h included on a freeBSD machine. I added a quick #ifdef/#include of libutil.h in opal/util/opal_pty.c and restarted make. Problem 3: -- Compilation made it a little further this time around, but began complaining about ompi/mpi/f77/strings.h. More console output: *** gcc -DHAVE_CONFIG_H -I. -I../../../opal/include -I../../../orte/include -I../../../ompi/include -I../../../opal/mca/paffinity/linux/plpa/src/libplpa -DOMPI_PROFILE_LAYER=0 -DOMPI_COMPILING_F77_WRAPPERS=1 -I../../.. -g -Wall -Wundef -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic -Werror-implicit-function-declaration -finline-functions -fno-strict-aliasing -pthread -MT attr_fn_f.lo -MD -MP -MF .deps/attr_fn_f.Tpo -c attr_fn_f.c -fPIC -DPIC -o .libs/attr_fn_f.o In file included from /usr/include/string.h:49, from ../../../opal/include/opal_config_bottom.h:365, from ../../../opal/include/opal_config.h:1432, from ../../../ompi/include/ompi_config.h:26, from attr_fn_f.c:20: ./strings.h:43: error: syntax error before "int" ./strings.h:59: error: syntax error before "int" ./strings.h:78: error: syntax error before "int" ./strings.h:94: error: syntax error before "int" *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/ompi/mpi/f77. *** Error code 1 Stop in /usr/home/km
Re: [OMPI devel] Message Queue debugging support for1.2.4
Nikolay and Community, Sorry to be so late in responding to your email but I've been working with Pak to determine whether my hasty decision as RM yesterday was hasty or not. To answer your question, we are still trying to determine if the message queue support can go in or not and the below is my perspective on whether we should. Community, A couple things have transpired in the last 24 hours from when we had our concall. As Jeff surmised earlier this morning Pak did accidentally have debugging enabled which did skew the numbers quite a bit. After making sure debugging was disabled for both builds (v1.2 and the tmp branch with the message queue fixes) we then fretted over the numbers. It looks to me that there is quite a bit of variance in the numbers that the OSU latency, IMB latency and mpi_ping all produce. For example in using the OSU latency tests we say the MX MTL have a .01 us difference between v1.2 and the tmp branch (in favor of v1.2). However the mean, trimmed mean and median have about .02-07us difference (in favor of the tmp branch). To me the data looks pretty much the same and the fact that we are measuring the averages (ie none of the tests pick out the minimum value) makes these numbers even more hard to really nail down IMHO. I've essentially seen this affect for the other tests (IMB and mpi_ping). For the SM timings using the mpi_ping tests we have seen a range of average latencies from 1.47-1.5 us for both the tmp and v1.2 so they seem like moral equivalents to me. Rich Graham has led me to believe that he might get more consistent numbers but we are not able to and so I can only deduce that the numbers are essentially the same. In conclusion I believe both the CM PML (MX MTL) and the SM BTL performance is about the same between the tmp branch and v1.2. Because of this I would like to request that the 1097 cmr be put into 1.2.4. If others disagree with my assessment above I think a discussion will need to ensue and I would welcome further testing by others that may show that the changes have regressed performance (or not). I would like to set a timeout of 12 noon ET for others to comment whether these new findings puts our fears at ease. At that time if not descenting comments have been received I would like to ask Tim to pull in these changes and rebuild 1.2.4. thanks, --td Nikolay Piskun wrote: Hi, Just to verify, before I'll start testing this, there will be no message queue debugging support in this version, correct? This all goes to 1.3 release. Best Regards, P.S. It looks like it is time for us to be more formally involved in this work. Nikolay Piskun Director of Continuing Engineering, TotalView Technologies 24 Prime Parkway, Natick, MA 01760 http://www.totalviewtech.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Message Queue debugging support for1.2.4
This all sounds reasonable to me. I agree -- now that the dramatic performance difference has been explained and we're within a tiny delta (that's likely simply the normal testing variance), let's put the MQ stuff in 1.2.4. (BTW, I didn't surmise that Pak had debugging enabled; I think he said it somewhere :-) [perhaps on a trac ticket? I don't remember offhand...]) On Sep 19, 2007, at 3:59 PM, Terry Dontje wrote: Nikolay and Community, Sorry to be so late in responding to your email but I've been working with Pak to determine whether my hasty decision as RM yesterday was hasty or not. To answer your question, we are still trying to determine if the message queue support can go in or not and the below is my perspective on whether we should. Community, A couple things have transpired in the last 24 hours from when we had our concall. As Jeff surmised earlier this morning Pak did accidentally have debugging enabled which did skew the numbers quite a bit. After making sure debugging was disabled for both builds (v1.2 and the tmp branch with the message queue fixes) we then fretted over the numbers. It looks to me that there is quite a bit of variance in the numbers that the OSU latency, IMB latency and mpi_ping all produce. For example in using the OSU latency tests we say the MX MTL have a .01 us difference between v1.2 and the tmp branch (in favor of v1.2). However the mean, trimmed mean and median have about .02-07us difference (in favor of the tmp branch). To me the data looks pretty much the same and the fact that we are measuring the averages (ie none of the tests pick out the minimum value) makes these numbers even more hard to really nail down IMHO. I've essentially seen this affect for the other tests (IMB and mpi_ping). For the SM timings using the mpi_ping tests we have seen a range of average latencies from 1.47-1.5 us for both the tmp and v1.2 so they seem like moral equivalents to me. Rich Graham has led me to believe that he might get more consistent numbers but we are not able to and so I can only deduce that the numbers are essentially the same. In conclusion I believe both the CM PML (MX MTL) and the SM BTL performance is about the same between the tmp branch and v1.2. Because of this I would like to request that the 1097 cmr be put into 1.2.4. If others disagree with my assessment above I think a discussion will need to ensue and I would welcome further testing by others that may show that the changes have regressed performance (or not). I would like to set a timeout of 12 noon ET for others to comment whether these new findings puts our fears at ease. At that time if not descenting comments have been received I would like to ask Tim to pull in these changes and rebuild 1.2.4. thanks, --td Nikolay Piskun wrote: Hi, Just to verify, before I'll start testing this, there will be no message queue debugging support in this version, correct? This all goes to 1.3 release. Best Regards, P.S. It looks like it is time for us to be more formally involved in this work. Nikolay Piskun Director of Continuing Engineering, TotalView Technologies 24 Prime Parkway, Natick, MA 01760 http://www.totalviewtech.com - --- ___ 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 Cisco Systems
Re: [OMPI devel] Message Queue debugging support for1.2.4
Terry, Are the performance numbers still with debugging turned on ? The sm latency (trunk and tmp) is about 2.5 x higher than I typically see. BTW, if the tmp branch is running coming in essentially the same, looks like there is no performance problem with the changes. Rich - Original Message - From: devel-boun...@open-mpi.org To: Open MPI Developers Sent: Wed Sep 19 15:59:38 2007 Subject: Re: [OMPI devel] Message Queue debugging support for1.2.4 Nikolay and Community, Sorry to be so late in responding to your email but I've been working with Pak to determine whether my hasty decision as RM yesterday was hasty or not. To answer your question, we are still trying to determine if the message queue support can go in or not and the below is my perspective on whether we should. Community, A couple things have transpired in the last 24 hours from when we had our concall. As Jeff surmised earlier this morning Pak did accidentally have debugging enabled which did skew the numbers quite a bit. After making sure debugging was disabled for both builds (v1.2 and the tmp branch with the message queue fixes) we then fretted over the numbers. It looks to me that there is quite a bit of variance in the numbers that the OSU latency, IMB latency and mpi_ping all produce. For example in using the OSU latency tests we say the MX MTL have a .01 us difference between v1.2 and the tmp branch (in favor of v1.2). However the mean, trimmed mean and median have about .02-07us difference (in favor of the tmp branch). To me the data looks pretty much the same and the fact that we are measuring the averages (ie none of the tests pick out the minimum value) makes these numbers even more hard to really nail down IMHO. I've essentially seen this affect for the other tests (IMB and mpi_ping). For the SM timings using the mpi_ping tests we have seen a range of average latencies from 1.47-1.5 us for both the tmp and v1.2 so they seem like moral equivalents to me. Rich Graham has led me to believe that he might get more consistent numbers but we are not able to and so I can only deduce that the numbers are essentially the same. In conclusion I believe both the CM PML (MX MTL) and the SM BTL performance is about the same between the tmp branch and v1.2. Because of this I would like to request that the 1097 cmr be put into 1.2.4. If others disagree with my assessment above I think a discussion will need to ensue and I would welcome further testing by others that may show that the changes have regressed performance (or not). I would like to set a timeout of 12 noon ET for others to comment whether these new findings puts our fears at ease. At that time if not descenting comments have been received I would like to ask Tim to pull in these changes and rebuild 1.2.4. thanks, --td Nikolay Piskun wrote: > Hi, > > Just to verify, before I'll start testing this, there will be no > message queue debugging support in this version, correct? This all > goes to 1.3 release. > Best Regards, > > P.S. It looks like it is time for us to be more formally involved in > this work. > > Nikolay Piskun > Director of Continuing Engineering, TotalView Technologies > 24 Prime Parkway, Natick, MA 01760 > http://www.totalviewtech.com > > > ___ > 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
Re: [OMPI devel] Message Queue debugging support for1.2.4
Rich, Yes. Both my tmp branch and 1.2 branch are both configured with -g. The --enable-debug flag was taken out for my tmp branch previously, that should explain the latency last time. Graham, Richard L. wrote: Terry, Are the performance numbers still with debugging turned on ? The sm latency (trunk and tmp) is about 2.5 x higher than I typically see. BTW, if the tmp branch is running coming in essentially the same, looks like there is no performance problem with the changes. Rich - Original Message - From: devel-boun...@open-mpi.org To: Open MPI Developers Sent: Wed Sep 19 15:59:38 2007 Subject: Re: [OMPI devel] Message Queue debugging support for1.2.4 Nikolay and Community, Sorry to be so late in responding to your email but I've been working with Pak to determine whether my hasty decision as RM yesterday was hasty or not. To answer your question, we are still trying to determine if the message queue support can go in or not and the below is my perspective on whether we should. Community, A couple things have transpired in the last 24 hours from when we had our concall. As Jeff surmised earlier this morning Pak did accidentally have debugging enabled which did skew the numbers quite a bit. After making sure debugging was disabled for both builds (v1.2 and the tmp branch with the message queue fixes) we then fretted over the numbers. It looks to me that there is quite a bit of variance in the numbers that the OSU latency, IMB latency and mpi_ping all produce. For example in using the OSU latency tests we say the MX MTL have a .01 us difference between v1.2 and the tmp branch (in favor of v1.2). However the mean, trimmed mean and median have about .02-07us difference (in favor of the tmp branch). To me the data looks pretty much the same and the fact that we are measuring the averages (ie none of the tests pick out the minimum value) makes these numbers even more hard to really nail down IMHO. I've essentially seen this affect for the other tests (IMB and mpi_ping). For the SM timings using the mpi_ping tests we have seen a range of average latencies from 1.47-1.5 us for both the tmp and v1.2 so they seem like moral equivalents to me. Rich Graham has led me to believe that he might get more consistent numbers but we are not able to and so I can only deduce that the numbers are essentially the same. In conclusion I believe both the CM PML (MX MTL) and the SM BTL performance is about the same between the tmp branch and v1.2. Because of this I would like to request that the 1097 cmr be put into 1.2.4. If others disagree with my assessment above I think a discussion will need to ensue and I would welcome further testing by others that may show that the changes have regressed performance (or not). I would like to set a timeout of 12 noon ET for others to comment whether these new findings puts our fears at ease. At that time if not descenting comments have been received I would like to ask Tim to pull in these changes and rebuild 1.2.4. thanks, --td Nikolay Piskun wrote: Hi, Just to verify, before I'll start testing this, there will be no message queue debugging support in this version, correct? This all goes to 1.3 release. Best Regards, P.S. It looks like it is time for us to be more formally involved in this work. Nikolay Piskun Director of Continuing Engineering, TotalView Technologies 24 Prime Parkway, Natick, MA 01760 http://www.totalviewtech.com ___ 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 ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- - Pak Lui pak@sun.com
Re: [OMPI devel] FreeBSD Support?
Hi Karol, Thanks for the reports. I cannot help with the first problem. Maybe someone else can. Problem 2: I have committed your suggested fix in r16163. As for the third problem, this is very strange. It looks like what is happening is that we are in the ompi/mpi/f77 directory compiling a .c file. This includes ompi_config.h, which includes ompi_config_bottom.h, which then includes string.h (/usr/include/string.h). So far so good. Here is where it gets nasty. On FreeBSD, /usr/include/string.h includes strings.h in some cases. But there is a strings.h in the ompi/mpi/f77 directory, so that is getting included instead of the proper /usr/include/strings.h. I suppose we could rename our strings.h to f77_strings.h, or something similar. Does anyone have an opinion on this? When you compiled v1.2.3 and the v1.2.4 prerelease, did you compile from a tarball or a subversion checkout? I ask because it looks like the above problem will only happen when the developer debugging code is enabled, which is the default when building from a subversion checkout. Thanks again for your reports, Tim Karol Mroz wrote: Hi. I have been trying to build the latest ompi-trunk (as of yesterday) svn snapshot (r16158) of OpenMPI on a FreeBSD 6.2 machine and have run into 3 build problems. I was curious if anyone else has encountered these errors and if they are being addressed. Problem 1 - When running the autogen.sh script as non-root, I see the following error: * *** Running GNU tools [Running] autom4te --language=m4sh ompi_get_version.m4sh -o ompi_get_version.sh [Running] aclocal /usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB /usr/local/share/aclocal/glib.m4:8: run info '(automake)Extending aclocal' /usr/local/share/aclocal/glib.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal [Running] autoheader ** Adjusting libtool for OMPI :-( ++ patching for pathscale multi-line output (LT 1.5.x) [Running] autoconf [Running] libtoolize --automake --copy --ltdl -- Moving libltdl to opal/ ** Updating Automake version in libltdl package [Running] aclocal acinclude.m4:6405: the serial number must appear before any macro definition /usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB /usr/local/share/aclocal/glib.m4:8: run info '(automake)Extending aclocal' /usr/local/share/aclocal/glib.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal [Running] automake [Running] autoconf autom4te-2.61: cannot open configure: Permission denied - It seems that the execution of "autoconf" has failed. See above for the specific error message that caused it to abort. - * After some searching, it would appear that this is an autoconf issue that crops up in FreeBSD but, for whatever reason, not in Linux. A quick workaround is to add: `chmod -vr u+w *` just before autogen issues the `run_and_check $ompi_autoconf` command on line 438. Problem 2: -- After correcting the autogen.sh script, running it and then running configure with --prefix=some_directory as a parameter, it was time to `make all install.` Following is console output: gcc -DHAVE_CONFIG_H -I. -I../../opal/include -I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../.. -g -Wall -Wundef -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic -Werror-implicit-function-declaration -finline-functions -fno-strict-aliasing -pthread -MT opal_pty.lo -MD -MP -MF .deps/opal_pty.Tpo -c opal_pty.c -fPIC -DPIC -o .libs/opal_pty.o opal_pty.c: In function `opal_openpty': opal_pty.c:127: error: implicit declaration of function `openpty' *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/opal/util. *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/opal/util. *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk/opal. *** Error code 1 Stop in /usr/home/kmroz/work/ompi-trunk. *** It would seem that openpty needs to have libutil.h included on a freeBSD machine. I added a quick #ifdef/#include of libutil.h in opal/util/opal_pty.c and restarted make. Problem 3: -- Compilation made it a little further this time around, but began complaining about ompi/mpi/f77/strings.h. More console output:
Re: [OMPI devel] FreeBSD Support?
Hi, Tim. Thanks for the reply. v1.2.3 and v1.2.4rc1 were both compiled, without problems, from tarballs. Tim Prins wrote: > Hi Karol, > > Thanks for the reports. > > I cannot help with the first problem. Maybe someone else can. > > Problem 2: I have committed your suggested fix in r16163. > > As for the third problem, this is very strange. It looks like what is > happening is that we are in the ompi/mpi/f77 directory compiling a .c > file. This includes ompi_config.h, which includes ompi_config_bottom.h, > which then includes string.h (/usr/include/string.h). So far so good. > > Here is where it gets nasty. On FreeBSD, /usr/include/string.h includes > strings.h in some cases. But there is a strings.h in the ompi/mpi/f77 > directory, so that is getting included instead of the proper > /usr/include/strings.h. > > I suppose we could rename our strings.h to f77_strings.h, or something > similar. Does anyone have an opinion on this? > > When you compiled v1.2.3 and the v1.2.4 prerelease, did you compile from > a tarball or a subversion checkout? I ask because it looks like the > above problem will only happen when the developer debugging code is > enabled, which is the default when building from a subversion checkout. > > Thanks again for your reports, > > Tim > > Karol Mroz wrote: >> Hi. I have been trying to build the latest ompi-trunk (as of yesterday) >> svn snapshot (r16158) of OpenMPI on a FreeBSD 6.2 machine and have run >> into 3 build problems. I was curious if anyone else has encountered >> these errors and if they are being addressed. >> >> Problem 1 >> - >> When running the autogen.sh script as non-root, I see the following error: >> * >> *** Running GNU tools >> [Running] autom4te --language=m4sh ompi_get_version.m4sh -o >> ompi_get_version.sh >> [Running] aclocal >> /usr/local/share/aclocal/glib.m4:8: warning: underquoted >> definition of >> AM_PATH_GLIB >> /usr/local/share/aclocal/glib.m4:8: run info '(automake)Extending >> aclocal' >> /usr/local/share/aclocal/glib.m4:8: or see >> http://sources.redhat.com/automake/automake.html#Extending-aclocal >> [Running] autoheader >> ** Adjusting libtool for OMPI :-( >> ++ patching for pathscale multi-line output (LT 1.5.x) >> [Running] autoconf >> [Running] libtoolize --automake --copy --ltdl >> -- Moving libltdl to opal/ >> ** Updating Automake version in libltdl package >> [Running] aclocal >> acinclude.m4:6405: the serial number must appear before any macro >> definition >> /usr/local/share/aclocal/glib.m4:8: warning: underquoted >> definition of >> AM_PATH_GLIB >> /usr/local/share/aclocal/glib.m4:8: run info '(automake)Extending >> aclocal' >> /usr/local/share/aclocal/glib.m4:8: or see >> http://sources.redhat.com/automake/automake.html#Extending-aclocal >> [Running] automake >> [Running] autoconf >> autom4te-2.61: cannot open configure: Permission denied >> >> - >> It seems that the execution of "autoconf" has failed. See above for >> the specific error message that caused it to abort. >> - >> * >> >> After some searching, it would appear that this is an autoconf issue >> that crops up in FreeBSD but, for whatever reason, not in Linux. A quick >> workaround is to add: `chmod -vr u+w *` just before autogen issues the >> `run_and_check $ompi_autoconf` command on line 438. >> >> >> Problem 2: >> -- >> After correcting the autogen.sh script, running it and then running >> configure with --prefix=some_directory as a parameter, it was time to >> `make all install.` Following is console output: >> >> >> gcc -DHAVE_CONFIG_H -I. -I../../opal/include -I../../orte/include >> -I../../ompi/include -I../../opal/mca/paffinity/linux/plpa/src/libplpa >> -I../.. -g -Wall -Wundef -Wno-long-long -Wsign-compare >> -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic >> -Werror-implicit-function-declaration -finline-functions >> -fno-strict-aliasing -pthread -MT opal_pty.lo -MD -MP -MF >> .deps/opal_pty.Tpo -c opal_pty.c -fPIC -DPIC -o .libs/opal_pty.o >> opal_pty.c: In function `opal_openpty': >> opal_pty.c:127: error: implicit declaration of function `openpty' >> *** Error code 1 >> >> Stop in /usr/home/kmroz/work/ompi-trunk/opal/util. >> *** Error code 1 >> >> Stop in /usr/home/kmroz/work/ompi-trunk/opal/util. >> *** Error code 1 >> >> Stop in /usr/home/kmroz/work/ompi-trunk/opal. >> *** Error code 1 >> >> Stop in /usr/home/kmroz/work/ompi-trunk. >> **
Re: [OMPI devel] FreeBSD Support?
On Sep 19, 2007, at 4:11 PM, Tim Prins wrote: Here is where it gets nasty. On FreeBSD, /usr/include/string.h includes strings.h in some cases. But there is a strings.h in the ompi/mpi/f77 directory, so that is getting included instead of the proper /usr/include/strings.h. I suppose we could rename our strings.h to f77_strings.h, or something similar. Does anyone have an opinion on this? I think this is the best path forward. Ugh. Brian
Re: [OMPI devel] FreeBSD Support?
This is fixed in r16164. Tim Brian Barrett wrote: On Sep 19, 2007, at 4:11 PM, Tim Prins wrote: Here is where it gets nasty. On FreeBSD, /usr/include/string.h includes strings.h in some cases. But there is a strings.h in the ompi/mpi/f77 directory, so that is getting included instead of the proper /usr/include/strings.h. I suppose we could rename our strings.h to f77_strings.h, or something similar. Does anyone have an opinion on this? I think this is the best path forward. Ugh. Brian ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
