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 <phhargr...@lbl.gov> 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 <r...@open-mpi.org> 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 <phhargr...@lbl.gov> 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 > > > _______________________________________________ > 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/15472.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/15473.php
